Opened 11 years ago

Closed 11 years ago

#3182 closed bug (fixed)

locate crashes at the end of every call

Reported by: karmak Owned by: axeld
Priority: normal Milestone: R1
Component: - General Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

after having run updatedb, every call of the locate command gives me the attended result (it works), and the crashes. This is 100% reproductible on my machine (real hardware, IBM R52 ; Haiku hrev28734, bug happening since i found locate, approx hrev28600).

the backtrace :

#0  0x002027e5 in getstr ()
#1  0x0020167c in locate ()
#2  0x00201998 in main ()

The problem happens if there are positive results, and if there are no results (same backtrace).

Attachments (1)

strace of "locate Bootscript.cd" (30.3 KB ) - added by karmak 11 years ago.
strace showing the segmentation violation

Download all attachments as: .zip

Change History (7)

by karmak, 11 years ago

strace showing the segmentation violation

comment:1 by Adek336, 11 years ago

src/bin/findutils/locate/locate.c, line 281: before the crash, count is being filled with a large value, much larger than pathsize. In line 288, count is the "offset" and &pathsize is the "n" argument to getstr, where *n is the size of a buffer and offset is the offset into that buffer. Obviously, *n < offset is incorrect.

The incorrect value for "count" is being read from /boot/var/locatedb. Either the file is corrupt or there is bug in the db reading logic.

comment:2 by Adek336, 11 years ago

It is both correct in the file and correctly read, it is just incorrectly added because of the wrong return type of get_short.

fix:

Index: locate/locate.c
===================================================================
--- locate/locate.c     (revision 28736)
+++ locate/locate.c     (working copy)
@@ -107,7 +107,7 @@
 
 /* Read in a 16-bit int, high byte first (network byte order).  */
 
-static int
+static short
 get_short (fp)
      FILE *fp;
 {

comment:3 by Adek336, 11 years ago

As it turns out, this has already been fixed in upstream - updating versions would be a good idea, I think.

comment:4 by korli, 11 years ago

Could you check with hrev28751 please ?

comment:5 by karmak, 11 years ago

You got it ! On hrev28752 it doesn't crash !

This ticket can be closed.

THANKS !!

comment:6 by korli, 11 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.