Double free glibc error
Brought to you by:
kdekorte
Menu
▾
▴
#105 Double free glibc error
Distro: CentOS 4.3
Plugin Version: daily snapshot (Jul 3rd) and 3.25
Firefox: 1.5.0.2
Whenever I try to view any media online, firefox will
deadlock. Tracing the firefox process with strace (-p),
I can see a "double free or corruption" error right
before the deadlock (which happens to be a futex call).
Here is the relevant section:
mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb540f000
_llseek(61, 0, [0], SEEK_SET) = 0
open("http://www.nasa.gov/55644main_NASATV_Windows.asx",
O_RDONLY) = -1 ENOENT (No such file or directory)
write(61, "<ASX Version=\"3.0\">\n "...,
695) = 695
close(61) = 0
munmap(0xb540f000, 4096) = 0
futex(0x95e5510, FUTEX_WAKE, 1) = 1
lseek(53, 69632, SEEK_SET) = 69632
write(53, "<ASX Version=\"3.0\">\n "...,
768) = 768
open("/dev/tty", O_RDWR|O_NONBLOCK|O_NOCTTY) = -1 ENXIO
(No such device or address)
writev(2, [{"*** glibc detected *** ", 23}, {"double
free or corruption (!prev"..., 33}, {": 0x", 4},
{"09681e98", 8}, {" ***\n", 5}], 5) = 73
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(12791, 12791, SIGABRT) = 0
--- SIGABRT (Aborted) @ 0 (0) ---
unlink("/home/rodrigob/.mozilla/firefox/default.wf2/lock")
= 0
futex(0xc3a820, FUTEX_WAIT, 2, NULL <unfinished ...>
Logged In: YES
user_id=685413
Please give a full test case to the problem. As currenly I
am unable to duplicate the crash.
Logged In: YES
user_id=10857
That is simply it. ANY media handled by mplayerplug-in will
cause this.
Using MALLOC_CHECK_=0 eliminated the problem, by the way.
mplayer itself seems to be fine, since I can use it to
access online media (outside the browser) without any problems.
I'm not sure which distribution you are testing, so the
following information might also be relevant:
gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)
glibc-2.3.4-2.19
If you need any further information, please let me know.
mplayerplug-in 3.05 works fine. The problem only started
after I upgraded to 3.25, and continued when I tried the
snapshot version.
Logged In: YES
user_id=685413
Can you please run firefox under the gdb debugger
firefox -g
and then when it crashes, issue the bt command to gdb so
that I can see the backtrace of where it is crashing.
Thanks.
Logged In: YES
user_id=10857
hey, I didn't know about "firefox -g". Tkx. That is one I'm
saving.
Anyway, trace is attached.
The line in question is:
if (fclose(n->localcache) != 0) {
Trace data
Logged In: YES
user_id=10857
Since the first time I saw it, I'm intrigued about the open
attempt on /dev/tty. It is a good bet it is related to the
problem. I just wonder why it is trying to open /dev/tty...
Logged In: YES
user_id=685413
Can you please retest will current CVS? Those lines are not
matching up for me. And I don't see anything obvious at the
moment.
As for the tty that is how the plugin communicates with
mplayer via stdio. So that should be ok I believe.
Logged In: YES
user_id=685413
Can you also rerun the trace with "debug=1" in the
mplayerplug-in.conf file. That will help me determine the
state the code is in.
Logged In: YES
user_id=10857
I'll do that.
In any case, I'm attacking the plugin.cpp file on my current
version.
Logged In: YES
user_id=10857
I just noticed the mplayerplug-in-daily.tar.gz avaliable for
download is the same version I'm using.
I'll be doing a checkout next.
Logged In: YES
user_id=10857
Trace attached.
More information due to debug=1, but the backtrace points to
the same line number on the same file (plugin.cpp:1335).
Trace for cvs version
Logged In: YES
user_id=685413
Why is CentOS using /lib/tls/libc.so.6
On FC5 it is
$ ls -la libc.so.6
lrwxrwxrwx 1 root root 11 May 15 07:24 libc.so.6 -> libc-2.4.so
$ ls -la libc-2.4.so
-rwxr-xr-x 1 root root 1532536 May 12 07:09 libc-2.4.so
What does
rpm -q --whatprovides /lib/libc.so.6
give you?
on FC5 it gives...
glibc-2.4-8
Logged In: YES
user_id=10857
CentOS 4 is based on RedHat Enterprise 4, which is based on
FC3 (not 5). Actually, something between FC3 and FC4.
glibc is 2.3.4-2.19, as I mentioned earlier.
Logged In: YES
user_id=685413
Any more information on this? I can't seem to duplicate it
on my machine.
I also did some traces on n->localcache and didn't see any
obvious place where it was getting destroyed improperly (I
spent about 10 mins looking which is not very long). It also
looks like a bug in fclose inside of glibc. Would it be
possible to upgrade or downgrade glibc on your machine to
see if the error is the same?
Logged In: YES
user_id=10857
It might be a glibc bug, but that filed open() for /dev/tty
makes me suspect it is somewhere else besides fclose().
I'll try tracking it down to on the source code later this
week. Hopefully, I'll be able to get back with a patch.
Logged In: YES
user_id=685413
Can you please test CVS. I think I found a place where the
file pointer was not properly being set to NULL after a close.
Logged In: YES
user_id=10857
I will, but only later next week. Sorry I can't test it
sooner, but things are a bit chaotic here.
Logged In: YES
user_id=685413
I believe this is fixed in the 3.30 release
Logged In: YES
user_id=10857
Just to put a definitive nail on this coffin.
Been using 3.31 with: Firefox 1.5.0.5, CentOS 4.4 (glibc
2.3.4-2.25) and mplayer 1.0pre7-3.4.4 and it is working
flawlessly now.
Sorry it took so long for me to report back.