Bug#264884: globfree() double-frees
Thanks for your reply, and thanks handy teaching of LSB installation.
It's complex - apt-get makes me lazy :)
At Mon, 13 Sep 2004 11:55:38 -0500,
Jeff Licquia wrote:
> - 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().
My gdb log is:
sh-3.00$ LD_LIBRARY_PATH=/usr/lib/debug gdb ./T.glob
GNU gdb 6.1-debian
...
This GDB was configured as "i386-linux"...(no debugging symbols found)...Using host libthread_db library "/usr/lib/debug/libthread_db.so.1".
(gdb) b test29
Breakpoint 1 at 0x804f1e5
(gdb) run
Starting program: /home/tet/test_sets/TESTROOT/tset/LSB.os/genuts/glob/T.glob
(no debugging symbols found)...Detaching after fork from child process 7263.
Detaching after fork from child process 7264.
Breakpoint 1, 0x0804f1e5 in test29 ()
(gdb) b globfree
Breakpoint 2 at 0x400c2d36: file ../sysdeps/generic/glob.c, line 1100.
(gdb) c
Continuing.
Breakpoint 2, 0x400c2d36 in *__GI_globfree (pglob=0x0) at ../sysdeps/generic/glob.c:1100
1100 {
(gdb) c
Continuing.
Breakpoint 2, 0x400c2d36 in *__GI_globfree (pglob=0x0) at ../sysdeps/generic/glob.c:1100
1100 {
(gdb)
Continuing.
There's no problem. pglob = NULL. Using MALLOC_CHECK_=3 or valgrind
does not report such problems... (valgrind says there may be some
leaks; it should be reported separately).
If it's uninitialized value issue, it may be glob() problem rathar
than globfree(). Could you confirm it?
> > 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.
Agreed. It's without your patch.
> > 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.
I also think I don't focus the actual problem. If you know more,
I'm welcome your 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.
I think it's no problem to put your patch into sarge. Considering
release schedule, I tend to put your patch and release 2.3.2.ds1-17
soon because your patch is harmless.
OTOH, the reason why I keep checking this bug is: if there's bug in
glob() and globfree(), we should fix it for upstream. Plus, I'm not
comfortable to put this patch even if debian-glibc maintainer don't
confirm the actual problem. So please keep discussing if we put your
patch into -17.
Regards,
-- gotom
Reply to: