Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#105 Double free glibc error

CVS
closed-fixed
Kevin DeKorte
Plugin (92)
5
2006-08-07
2006-07-04
Rodrigo Barbosa
No

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 ...>

Discussion

  • Kevin DeKorte
    Kevin DeKorte
    2006-07-05

    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.

     
  • Kevin DeKorte
    Kevin DeKorte
    2006-07-06

    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

     
    Attachments
  • 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...

     
  • Kevin DeKorte
    Kevin DeKorte
    2006-07-06

    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.

     
  • Kevin DeKorte
    Kevin DeKorte
    2006-07-06

    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

     
    Attachments
  • Kevin DeKorte
    Kevin DeKorte
    2006-07-06

    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.

     
  • Kevin DeKorte
    Kevin DeKorte
    2006-07-17

    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.

     
  • Kevin DeKorte
    Kevin DeKorte
    2006-07-29

    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.

     
  • Kevin DeKorte
    Kevin DeKorte
    2006-08-07

    Logged In: YES
    user_id=685413

    I believe this is fixed in the 3.30 release

     
  • Kevin DeKorte
    Kevin DeKorte
    2006-08-07

    • status: open --> closed-fixed
     
  • 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.