Here's the thread about technical information.
The problem seems to be
- running dir__enumerator
- on a directory with a stat() size of 414 bytes,
- but having ~21k of filenames (414 is # of entries including . & ..),
the initial size allocation is too low, so that in the loop all the arrays
have to be resized several times - and then realloc() tells about the
corrupted heap (on the 3rd or 4th reallocation of names).
Strangely, a watchpoint in GDB gave realloc() as worst offender (changing
the few bytes before *names); using MALLOC_CHECK_=2 and inserting mcheck()
calls identified line 556, which is (in the modified sources) the line
size=(size*19)/16+1 (or similar) as offender, which is clearly bogus ...
unless the C compiler (gcc 4.2.2, IIRC) is bad.
I've had a look at alloc_count and count, too; but once, while
alloc_count==200 and count==174, the heap was reported corrupted after the
names[count]=... line - while there should enough space be there, so I
can't explain that.
valgrind doesn't yet run on libc6=2.7.
Changing the initial allocation to some big value makes FSVS run.
2.6.22 had some reported NFS issues ... but they'd have to scribble over
user-space memory.
Any other ideas?
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
