[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#264884: globfree() double-frees



On Sat, 2004-09-11 at 11:33, GOTO Masanori wrote:
> I'm checking this bug; but it's difficult to run LSB test suite.
> Which test suite did you try?  If you know how to run it, please let
> me know.

The test suite I used was the 2.0 beta, available at
ftp://ftp.freestandards.org/pub/lsb/test_suites/released-2.0.0/binary/runtime/lsb-runtime-test-2.0.6-2.i386.rpm.  (i386; other archs can be found at http://www.linuxbase.org/download/#test_suites.)  I expect the problem would also be exhibited in the 1.3 suite.

My test procedure is as follows:

 - Install lsb, alien, and libc6-dbg.

 - Install the runtime test with "alien -ic <runtime-test-rpm>".

 - For the 2.0 runtime test, create a symlink from /lib/ld-linux.so.2 to
/lib/ld-lsb.so.2.

 - Set a password for the user "vsx0", created by the RPM.

 - Log in as vsx0 and set the following environment variables:

TET_CONFIG=$TET_EXECUTE/tetexec.cfg 
TET_CODE=$HOME/tet_code 

 - Go to the test directory ($TET_EXECUTE/tset/LSB.os/genuts/glob).

 - Run gdb on T.glob, preloading the debug libc.

 - Break on test29() in the test, and run the test.

 - When the test29() breakpoint hits, add another on globfree().

At this point, you should be able to watch the values passed to
globfree().  You should see the same glob_t passed twice to globfree(),
and also the same value passed to free() by globfree() that was passed
before.  If you watch malloc's fastbins, you should be able to see the
fastbin become a circular linked list after the second free().

> Hmm, weird.  I extracted test29 from cvs.  After GLOB_ABORTED from
> glob(), I checked the result of glob_t value and got as follows:
> 
> 	err: 2 (ABORTED:2) errno: 13
> 	glob: Permission denied
> 	gl_pathc:0, gl_pathv:0x0, gl_offs:0
> 
> So, if globfree() is called, it does not occur any problems.  Could
> you send me the complete test case or confirm these gl_pathv value?

Is this with my patch or without?

If with, then this is the expected result.  If without, then you have
not duplicated the bug, since the expected result in that case would
have a non-null value in gl_pathv.

>   I
> would like to test your patch and check its correctness.
> 
> My test program is (-> is my modification):

I can't see anything wrong with your test program, but there may be
other things going on.  If you can duplicate the result with the test
suite binaries, that might help.

> Yes, it makes sense.  But I still have question about this bug.  I
> would like to investigate this problem more.
> 
> Currently, there's no problem, so I would like to downgrade this bug
> to investigate more if there's no comments...

I suppose this is between you and the release manager.  I can tell you
without hesitation that sarge will not certify against LSB 2.0 without
this patch, and it may not certify against LSB 1.3 either.  This
situation violates policy, and causes a number of headaches for a lot of
other people as well.

OTOH, I am well aware of the constraints placed upon release managers,
so I will not object if releasing sarge with this bug is considered to
be the best thing for Debian.  I would insist on its correction for the
first point release, though.




Reply to: