Closed
Bug 469439
Opened 16 years ago
Closed 15 years ago
Crash when enabling fullscreen flash video [@ @0x110430 ][@ libc-2.9.so@0x2d097 ]
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 493541
People
(Reporter: bugzilla2, Assigned: karlt)
References
()
Details
(Keywords: crash, topcrash, Whiteboard: [patch in bug 493541])
Crash Data
Attachments
(5 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20081202 SeaMonkey/2.0a2 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20081202 SeaMonkey/2.0a2 I submitted a crash report for this earlier, its number is: bp-c8cd2b46-bf34-4622-b239-71e532081212 Whenever trying to enable the fullscreen video playback of a flash video such as the one in the URL above, Seamonkey crashes. Reproducible: Always Steps to Reproduce: 1. Launch flash video 2. Click fullscreen button in bottom-right corner of video 3. Actual Results: Seamonkey crashes. Expected Results: Seamonkey doesn't crash. Let me know if there is additional info I should provide.
Reporter | ||
Comment 1•16 years ago
|
||
This may be the same or similar to bug 466138 but that is 1.9.0 on Windows and I am using 1.9.1 on Linux.
Reporter | ||
Comment 2•16 years ago
|
||
Crash occurs with Flash 10.0.12.36 but not with 9.0.48.0...
Comment 3•16 years ago
|
||
bp-c8cd2b46-bf34-4622-b239-71e532081212 0 @0x110430 1 libc-2.9.so libc-2.9.so@0x2ce17 2 libc-2.9.so libc-2.9.so@0x68fdc 3 libc-2.9.so libc-2.9.so@0x6f393 Not exactly verbose. Not 100% sure if this is a dupe of bug 466138 or not.
Severity: normal → critical
Summary: Crash when enabling fullscreen flash video → Crash when enabling fullscreen flash video [@ @0x110430 ]
Updated•16 years ago
|
Component: General → Plug-ins
Product: SeaMonkey → Core
QA Contact: general → plugins
Version: unspecified → Trunk
Comment 4•16 years ago
|
||
(In reply to comment #3) > bp-c8cd2b46-bf34-4622-b239-71e532081212 > 0 @0x110430 > 1 libc-2.9.so libc-2.9.so@0x2ce17 > 2 libc-2.9.so libc-2.9.so@0x68fdc > 3 libc-2.9.so libc-2.9.so@0x6f393 > > Not exactly verbose. Not 100% sure if this is a dupe of bug 466138 or not. I notice the following: 1) Crash was by SIGABRT rather than the more usual SIGSEGV or SIGILL. I'll save details at bottom, before Socorro "forgets" them off its database. 2) Frame zero is identical in all threads. (Maybe this is expected?) 3) The listing above is supposed to be the crashing thread; however among the other threads there are two which catch my eye: Thread 10 Frame Module Signature Source 0 @0x110430 1 libflashplayer.so libflashplayer.so@0x17c29e 2 libflashplayer.so libflashplayer.so@0x4ab8c 3 libpthread-2.9.so libpthread-2.9.so@0x651e Thread 11 Frame Module Signature Source 0 @0x110430 1 libflashplayer.so libflashplayer.so@0x17c29e 2 libflashplayer.so libflashplayer.so@0x4ab8c 3 libpthread-2.9.so libpthread-2.9.so@0x651e 4) None of the threads goes back to something that can be identified as stack-bottom (main() or similar). ---- Crash summary: Signature @0x110430 UUID c8cd2b46-bf34-4622-b239-71e532081212 Time 2008-12-12 14:16:21-08 Uptime 15 Last Crash 80 seconds before submission Product SeaMonkey Version 2.0a3pre Build ID 20081212000452 Branch 1.9.1 OS Linux OS Version 0.0.0 Linux 2.6.27.7-20081129jk.fc10.x86_64 #1 SMP Sat Nov 29 20:38:52 CST 2008 x86_64 GNU/Linux CPU x86 CPU Info GenuineIntel family 10 model 15 stepping 11 Crash Reason SIGABRT Crash Address 0x110430 Comments When viewing Youtube videos with Flash Player 10, clicking on the maximize video button at the bottom-right corner of the player causes Seamonkey to crash.
Comment 5•16 years ago
|
||
I can confirm this and it happens with both 3.0.5 and the nightly from 2008-12-19 under Ubuntu 8.10. It happens with both Adobe Flash 10.0 r12 nad 10.0.r15. The browser crashes with a segmentation fault error. This happens with the youtube.com flash player and the vimeo.com flash player every time without exception when I try to switch to fullscreen. It also happens when no addons are installed. The same Flash plugin works fine and never crashes when switching to fullscreen when used with Konqueror. This is the start of what appears in the terminal: *** glibc detected *** ./firefox-bin: free(): invalid pointer: 0xae042510 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb69dc3f4] /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb69de456] /usr/lib/libGL.so.1[0xaa5adfc5] ======= Memory map: ======== 08048000-0804a000 r-xp 00000000 08:01 2443615 /software/firefox/firefox-bin 0804a000-0804b000 rw-p 00001000 08:01 2443615 /software/firefox/firefox-bin a837e000-a8f41000 r-xp 00000000 08:01 3756124 /usr/lib/libGLcore.so.177.80 a8f41000-a90e5000 rwxp 00bc3000 08:01 3756124 /usr/lib/libGLcore.so.177.80 a90e5000-a90f0000 rwxp a90e5000 00:00 0 a90f0000-a90f1000 ---p a90f0000 00:00 0 a90f1000-a98f1000 rwxp a90f1000 00:00 0 a98f1000-a98f2000 ---p a98f1000 00:00 0 a98f2000-aa0f2000 rwxp a98f2000 00:00 0 aa0f2000-aa2f3000 rw-s 00000000 00:15 535754 /dev/shm/pulse-shm-2641660529 aa2f3000-aa341000 r-xp 00000000 08:01 3239040 /usr/lib/libpulse.so.0.4.1 aa341000-aa342000 r--p 0004d000 08:01 3239040 /usr/lib/libpulse.so.0.4.1 aa342000-aa343000 rw-p 0004e000 08:01 3239040 /usr/lib/libpulse.so.0.4.1 aa343000-aa3d8000 r--p 00000000 08:01 3894003 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf ... ... more lines ... b4203000-b420a000 r-xp 00000000 08:01 3756056 /usr/lib/libkrb5support.so.0.1 b420a000-b420b000 r--p 00006000 08:01 3756056 /usr/lib/libkrb5support.so.0.1 b420b000-b420c000 rw-p 00007000 08:01 3756056 /usr/lib/libkrb5support.so.0.1 b420c000-b4210000 r-xp 00000000 08:01 1115212 /lib/tls/i686/cmov/libnss_dns-2.8.90.so b4210000-b4211000 r--p 00003000 08:01 1115212 /lib/tls/i686/cmov/libnss_dns-2.8.90.so b4211000-b4212000 rw-p 00004000 08:01 1115212 /lib/tls/i686/cmov/libnss_dns-2.8.90.so b4212000-b4258000 r-xp 00000000 08:01 2443618 /software/firefox/libfreebl3.so b4258000-b4259000 rw-p 00046000 08:01 2443618 /software/firefox/libfreebl3.so b4259000-b4276000 r-xp 00000000 08:01 2443630 /software/firefox/libnssdbm3.so b4276000-b427Segmentation fault
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 6•16 years ago
|
||
FWIW, a x86_64 Seamonkey 2.0a3pre (latest sources from Mercurial) and the Flash x86_64 preview 10.0.21 no longer crash when entering fullscreen video. Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20081221 SeaMonkey/2.0a3pre
Updated•16 years ago
|
Assignee: msintov → mmelanso
I wonder is this is the same: http://crash-stats.mozilla.com/report/index/65c673a5-5344-4700-b56a-8f9762081228 Crashes on viewing the flash full screen option at http://fitekker.blogspot.com/2008/12/ubuntu-usability.html. In my case (linux) I am using libc-2.7.so. - Does not crash in linux 1.1.14 (same machine), nor does it crash in 2.03apre on Windows XP.
This affects me also, causes FF 3.1B2 to go "ZOMBIE". Here's the link to the Mozillazine thread: http://forums.mozillazine.org/viewtopic.php?f=38&t=1004005 MRK
Comment 9•15 years ago
|
||
http://support.mozilla.com/en-US/kb/Cannot+view+full+screen+Flash+videos suggests to disable Hardware acceleration in Flash prefs (context menu in Flash movie), and that worked for me, the crash is gone. But it's slow, rather small and with 100% CPU (in one core). Newest nvidia binary drivers for Linux.
Comment 10•15 years ago
|
||
Thanks. That does work for me (Comment #7) for the site that I tested. My nvidia drivers are also fully up-to-date. Given that this does not crash on WinXP (only on linux in my case w/acceleration on), I wonder is this is a SM bug, or OS/Flash bug. Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090223 SeaMonkey/2.0a3 File name: /usr/lib/adobe-flashplugin/libflashplayer.so Shockwave Flash 10.0 r15
Comment 11•15 years ago
|
||
(In reply to comment #8) > This affects me also, causes FF 3.1B2 to go "ZOMBIE". Here's the link to the > Mozillazine thread: http://forums.mozillazine.org/viewtopic.php?f=38&t=1004005 FF3.1b3 UPDATE: Youtube no longer causes "Zombie process" but still crashes browser (and triggers "Send report to Firefox...") Fullscreen on item #7 (Above) hangs browser, but it can be "forced quit" - again no Zombie Process. I have the latest Flash from Adobe (then the Ubuntu repo "Interpid" update to it was immediately installed). I am using the latest (Version 177) NVIDIA driver from the repos.
Comment 12•15 years ago
|
||
(In reply to comment #9) > http://support.mozilla.com/en-US/kb/Cannot+view+full+screen+Flash+videos > suggests to disable Hardware acceleration in Flash prefs (context menu in Flash > movie), and that worked for me, the crash is gone. But it's slow, rather small > and with 100% CPU (in one core). Newest nvidia binary drivers for Linux. It works for me too with Debian Lenny and Nvidia 180.29 using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7.
Comment 13•15 years ago
|
||
Correct, but disabling hardware acceleration is not an acceptable solution, and IMHO is not even an acceptable workaround. Therefore, what is the current status on this - what further testing needs to be done to get this corrected in Beta 4?
Comment 14•15 years ago
|
||
well, the problem is w/ nvidia drivers, if you're using an old version, upgrade. if you're using the latest, complain to nvidia. nothing in this involves us.
Reporter | ||
Comment 15•15 years ago
|
||
I also have the nvidia driver, latest version, with hardware acceleration ON, and it DOESN'T crash with x86_64 Seamonkey/Flash. I only get the fullscreen crash on i386 Seamonkey/Flash. Never on x86_64. Can others check if the crash also goes away for them if they use x86_64 Seamonkey/Flash? (You can get x86_64 Flash http://labs.adobe.com/downloads/flashplayer10.html ) If that's the case then the problem is something else.
Comment 16•15 years ago
|
||
(In reply to comment #14) > well, the problem is w/ nvidia drivers, if you're using an old version, > upgrade. if you're using the latest, complain to nvidia. > > nothing in this involves us. Who are you and what's with the attitide? Sorry but I think you have exceeded you allowance of arrogance here - I have the latest NVIDIA drivers and have been monitoring this for months, and FWIW, I should tell you to STFU, but that would exceed MY arrogance quotient here!
Comment 17•15 years ago
|
||
Possible dupe of bug 484960
Comment 18•15 years ago
|
||
I've tried poking nVidia about this at http://www.nvnews.net/vbulletin/showthread.php?p=1997651 There is a workaround which is to create a script that does the following. #!/bin/sh export LD_PRELOAD=/usr/lib/libGL.so.1 /path/to/firefox
Comment 20•15 years ago
|
||
(In reply to comment #18) > I've tried poking nVidia about this at > http://www.nvnews.net/vbulletin/showthread.php?p=1997651 > > There is a workaround which is to create a script that does the following. > #!/bin/sh > export LD_PRELOAD=/usr/lib/libGL.so.1 > /path/to/firefox Report was opened for SeaMonkey not Firefox. I'll try the suggested workaround script for SeaMonkey (thanks for providing). @timeless: Again, these crashes do *not* occur in SeaMonkey 1.1.x (just tested on 1.1.16) but only in SeaMonkey 2.0.x (crashes in Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090512 SeaMonkey/2.0b1pre), and according to others, in Fx 3.x as well. Repeatable, see: <http://crash-stats.mozilla.com/report/index/039cd646-0fb8-439a-9781-04aae2090518> Therefore, IMO the bug should remain open until the issue is resolved in SM 2.x and Fx 3.x.
Comment 21•15 years ago
|
||
We also work around Windows bugs, so this is a valid Mozilla bug. As shown above, there is something we can do. It's extremely disturbing when watching (fullscreen) videos on youtube, which is a common activity for average users. We may also get this fixed by contacting nvidia. Again, there is action needed on our part (contacting them), so even then this should stay open until the issue is resolved.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 22•15 years ago
|
||
Comment 23•15 years ago
|
||
Comment 24•15 years ago
|
||
Comment 25•15 years ago
|
||
Comment 26•15 years ago
|
||
Comment 27•15 years ago
|
||
in Debian lenny 64 bits (amd64), nvidia drive 64 bits, flash 64 bits, iceweasel (firefox 3) 64 bits or firefox 3.5 64 bits, work fine. firefox 3.5 64 bits mozilla ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-1.9.1/ in Debian Lenny 32 bits (i386), nvidia drive 32 bits, flash 32 bits, firefox 32 bits package mozilla, freeze http://en-us.www.mozilla.com/en-US/ Processor AMD Turion 64, I think it is because Processor 64 bits/32 bits, had a 32 bits celeron and it was not. youtube http://www.youtube.com/watch?v=oIoLNddhQDo&feature=dir nvidia drive 180.51 flash 10.0.22.87 firefox 3.0.10 or firefox 3.5 b4 too freeze in opera 9.64 32 bits and in SeaMonkey 1.1.16, 32 bits, package mozilla http://www.seamonkey-project.org/ with nvidia drive, flash, work fine. my report bug https://bugzilla.mozilla.org/show_bug.cgi?id=478182 Logs, gdb, console erro, nvidia bug report. Comment #22, #23, #24, #25, #26.
Updated•15 years ago
|
Attachment #378770 -
Attachment mime type: text/x-log → text/plain
Updated•15 years ago
|
Attachment #378772 -
Attachment mime type: text/x-log → text/plain
Updated•15 years ago
|
Attachment #378773 -
Attachment mime type: text/x-log → text/plain
Comment 28•15 years ago
|
||
Your backtraces are missing symbols. (comment 23 / attachment 378770 [details]) (comment 25 / attachment 378772 [details])
Comment 29•15 years ago
|
||
Sent the following to <linux-bugs@nvidia.com>: Dear nvidia, Firefox crashes when Flash is enabled, user goes to YouTube, plays video, and clicks on the Fullscreen button in Flash. Please see <https://bugzilla.mozilla.org/show_bug.cgi?id=469439> for details. We think this may be a bug in the nvidia driver, because it affects only nvidia binary driver users, and the crash goes away when disabling "Hardware Acceleration" for Flash in the Flash preferences, see <http://support.mozilla.com/en-US/kb/Cannot+view+full+screen+Flash+videos>. One user attached a nvidia log file <https://bugzilla.mozilla.org/attachment.cgi?id=378773>, but it also appears on different configurations, in my case SuSE, Athlon X2 4800+, GeForce 7600 GS with 2vDVI, so I think it affects all nvidia binary driver users. Could you please investigate this? Thanks a lot. Ben
Comment 30•15 years ago
|
||
Comment #28 From Dave Garrett sorry use iceweasel (firefox of Debian) 32 bits, work fine. firefox package mozilla, needs that build for debug, seems http://kb.mozillazine.org/Getting_a_stacktrace_with_gdb https://developer.mozilla.org/en/Building_Firefox_with_Debug_Symbols Flash, Disable hardware acceleration, work fine, in 3.0.10 and 3.5 B4, it does not use more processor, is not visible in link http://www.youtube.com/watch?v=oIoLNddhQDo&feature=dir http://support.mozilla.com/en-US/kb/Cannot+view+full+screen+Flash+videos thanks
Comment 31•15 years ago
|
||
http://www.youtube.com/watch?v=oIoLNddhQDo&feature=dir Full screen, hardware acceleration enabled, 32 bit Ubuntu linux 9.04 - 2.6.28-12-generic, nVidia Corporation NV25GL [Quadro4 900 XGL] (rev a3), Flash 10.0.22.87: Works for me: - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090402 SeaMonkey/1.1.16 - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10 - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 Does *not* work (see previous crash reports) work for me with hardware acceleration turned on: Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090520 SeaMonkey/2.0b1pre Does work with 2.01pre w/ATI Rage 128 Pro Ultra TF and ATI Rage Mobility P/M AGP 2x (rev 64). So yes, nVidia is part of the issue. However, something in SeaMonkey 2.x is definitely the other part of the issue as I cannot replicate in the 'Works for me' builds.
Comment 34•15 years ago
|
||
I have the same problem when trying to vew a video in full screen with any Flash video player (youtube, dailymotion, flowplayer, ...). I'm running Ubuntu 9.04 with an NVIDIA 8400MGS drivers 180.44, 2.6.28-11-generic, Flash 10.0 r22 The problem appeared when I began to test Firefox 3.5 and is still present in the first RC. It is a very annoying one, what other useful information can I provide?
Assignee | ||
Comment 36•15 years ago
|
||
(In reply to comment #5) > This is the start of what appears in the terminal: > *** glibc detected *** ./firefox-bin: free(): invalid pointer: 0xae042510 *** > ======= Backtrace: ========= > /lib/tls/i686/cmov/libc.so.6[0xb69dc3f4] > /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb69de456] > /usr/lib/libGL.so.1[0xaa5adfc5] Johann, is this what you saw with the nightly or a Ubuntu build or both? If it was a Ubuntu build only, can you find the firefox or firefox-bin ELF executable, and run "readelf -sDw /usr/lib/mozilla-firefox-DIR/firefox-ELF |grep free" please? Jason/Stuart: Do you know whether glibc's cfree uses the external free (from jemalloc)? Should we be defining that symbol? What about calloc?
Comment 37•15 years ago
|
||
This happens on any recent distro using the Nvidia binary drivers and Firefox as downloaded from mozilla.com or built from http://hg.mozilla.org/mozilla-central/ Ubuntu builds of Firefox don't exhibit this bug. I am unsure about other distros's builds of Firefox. mozilla.com build firefox 3.5/rc2_build2$ readelf -sDw ./firefox-bin | grep free 60 16: 00000000 35 FUNC GLOBAL DEFAULT UND PR_smprintf_free 5 61: 0804ee50 628 FUNC GLOBAL DEFAULT 12 free Ubuntu's build readelf -sDw /usr/lib/firefox-3.0.11/firefox-3.0 | grep free 16 31: 00000000 0 FUNC GLOBAL DEFAULT UND free
Comment 38•15 years ago
|
||
I am not using the same hardware anymore so I cannot check anything. However I believe that upgrading the flash player already a while ago corrected this problem in my case.
Assignee | ||
Comment 39•15 years ago
|
||
(In reply to comment #37) > This happens on any recent distro using the Nvidia binary drivers and Firefox > as downloaded from mozilla.com or built from > http://hg.mozilla.org/mozilla-central/ Kevin, do you get messages from glibc such as this?: *** glibc detected *** ./firefox-bin: free(): invalid pointer: 0xae042510 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb69dc3f4] /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb69de456] /usr/lib/libGL.so.1[0xaa5adfc5] > Ubuntu builds of Firefox don't exhibit this bug. I am unsure about other > distros's builds of Firefox. > > mozilla.com build > firefox 3.5/rc2_build2$ readelf -sDw ./firefox-bin | grep free > 60 16: 00000000 35 FUNC GLOBAL DEFAULT UND PR_smprintf_free > 5 61: 0804ee50 628 FUNC GLOBAL DEFAULT 12 free > > Ubuntu's build > readelf -sDw /usr/lib/firefox-3.0.11/firefox-3.0 | grep free > 16 31: 00000000 0 FUNC GLOBAL DEFAULT UND free The mozilla.com build is defining its own malloc and free (for the process). If libGL is somehow using glibc's free for something allocated with mozilla's malloc then these kind of problems result. This Ubuntu build is using glibc's malloc and free so there is no mismatch. Do you see this bug if you run the mozilla build using the following? LD_PRELOAD=/lib/libc.so.6 ./firefox -no-remote
Comment 40•15 years ago
|
||
LD_PRELOAD=/lib/libc.so.6 lib/firefox\ 3.5/rc2_build2/firefox -no-remote Still crashes
Assignee | ||
Comment 41•15 years ago
|
||
Thanks for testing, Kevin. Interesting that LD_PRELOAD=/usr/lib/libGL.so.1 would fix this but LD_PRELOAD=/lib/libc.so.6 doesn't. Bug 484960 comment 7 seems to indicate that glibc's free() is being called from a Mozilla build, which shouldn't be happening.
Comment 42•15 years ago
|
||
From a debug build of http://hg.mozilla.org/mozilla-central/rev/2c3e19e8ac84 (gdb) backtrace #0 0xb7fdd430 in __kernel_vsyscall () #1 0xb70c87a6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6 #2 0xb70c85be in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:138 #3 0xb7f83fe2 in ?? () #4 0xb7f852a4 in ?? () #5 <signal handler called> #6 0xb7fdd430 in __kernel_vsyscall () #7 0xb70546d0 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #8 0xb7056098 in *__GI_abort () at abort.c:88 #9 0xb709224d in __libc_message (do_abort=2, fmt=0xb716d5a8 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:170 #10 0xb7098604 in malloc_printerr (action=2, str=0xb716a4a1 "free(): invalid pointer", ptr=0xacc41f70) at malloc.c:5994 #11 0xb709a5b6 in *__GI___libc_free (mem=0xacc41f70) at malloc.c:3625 #12 0xaaed0205 in ?? () from /usr/lib/libGL.so.1 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Assignee | ||
Comment 43•15 years ago
|
||
(In reply to comment #42) > #11 0xb709a5b6 in *__GI___libc_free (mem=0xacc41f70) at malloc.c:3625 > #12 0xaaed0205 in ?? () from /usr/lib/libGL.so.1 That's helpful, thanks. That's what I wouldn't expect from a build using jemalloc (unless libGL is using libc-specific symbol names). Does this build define free in the firefox-bin executable? If free is not undefined (UND) in firefox-bin, building with ac_add_options --disable-jemalloc would build firefox to use glibc's malloc and free. I'd be interested to know whether the bug still occurs with such a build.
Updated•15 years ago
|
Status: REOPENED → NEW
Comment 44•15 years ago
|
||
readelf -sDw ./firefox-bin | grep free 46 16: 00000000 0 FUNC GLOBAL DEFAULT UND PR_smprintf_free 62 61: 0805e7f4 268 FUNC GLOBAL DEFAULT 13 free 62 3: 0805e7f4 268 FUNC GLOBAL DEFAULT 13 free 26105 free <532e> DW_AT_name : (indirect string, offset: 0x4672): nfree <a9ad> DW_AT_name : (indirect string, offset: 0x4673): free 0x00004670 79006e66 72656500 6368756e 6b5f7365 y.nfree.chunk_se Rolling a jemalloc-less build.
Comment 45•15 years ago
|
||
As suspected an ac_add_options --disable-jemalloc build does not crash.
Comment 46•15 years ago
|
||
As an fyi: Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090622 Lightning/1.0pre SeaMonkey/2.0b1pre is still experiencing the crashes of comment #7 https://bugzilla.mozilla.org/show_bug.cgi?id=469439#c7 with hardware acceleration turned on.
Assignee | ||
Comment 48•15 years ago
|
||
Transferring beltzner's flags from bug 498098. This is less important for 1.9.0, though. Builds against 1.9.0 xulrunner won't show this bug as 1.9.0 xulrunner didn't use jemalloc.
Flags: wanted1.9.0.x?
Flags: blocking1.9.2?
Assignee | ||
Comment 49•15 years ago
|
||
It would be nice if we can fix this (in a reasonable way) for 1.9.1, though. I don't want to load NVIDIA's libGL unnecessarily, part of the reason being that it uses text relocations.
Flags: wanted1.9.1.x?
Assignee | ||
Comment 50•15 years ago
|
||
The code making the call from NVIDIA's libGL is not PIC code. The function called depends on an R_386_PC32 text relocation for the symbol "free". I don't know why this is getting resolved to "free" in libc instead of "free" in the executable. (gdb) bt #0 0xb669d396 in malloc_printerr () from /lib/tls/i686/cmov/libc.so.6 #1 0xb669f4b6 in free () from /lib/tls/i686/cmov/libc.so.6 #2 0x6d286205 in ?? () from ./libGL.so.1 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) f 2 #2 0x6d286205 in ?? () from ./libGL.so.1 (gdb) x/i $pc - 5 0x6d286200: call 0xb669f420 <free> (gdb) info addr free Symbol "free" is at 0x804ee50 in a file compiled without debugging. (gdb) info sym 0xb669f420 free in section .text (gdb) info files .. 0x08049360 - 0x080550b8 is .text .. 0xb6644460 - 0xb6755178 is .text in /lib/tls/i686/cmov/libc.so.6 .. 0x6d25e000 - 0x6d2a4ebd is .text in ./libGL.so.1 .. % readelf -S libGL.so.185.18.14 [Nr] Name Type Addr Off Size ES Flg Lk Inf Al .. [ 7] .text PROGBITS 00026000 026000 046ebd 00 AX 0 0 4096 .. (gdb) p/x $offset = 0x6d25e000 - 0x00026000 $10 = 0x6d238000 (gdb) p $pc - 4 - $offset $11 = (void (*)()) 0x4e201 % readelf --reloc libGL.so.185.18.14 Relocation section '.rel.dyn' at offset 0x121e0 contains 10009 entries: Offset Info Type Sym.Value Sym. Name .. 0004e201 00058e02 R_386_PC32 00000000 free ..
Assignee | ||
Comment 52•15 years ago
|
||
Dissambling further up the call stack gives more info: #0 0xb669d396 in malloc_printerr () from /lib/tls/i686/cmov/libc.so.6 #1 0xb669f4b6 in free () from /lib/tls/i686/cmov/libc.so.6 #2 0x6d286205 in ?? () from ./libGL.so.1 0x6d2927ca <_init+122> from ./libGL.so.1 0xb7f4cae4 <call_init+132> from /lib/ld-linux.so.2 0xb7f4cc14 <_dl_init_internal+148> from /lib/ld-linux.so.2 0xb7f50b3b <dl_open_worker+923> from /lib/ld-linux.so.2 0xb7f4c716 <_dl_catch_error+118> from /lib/ld-linux.so.2 0xb7f502ee <_dl_open+158> from /lib/ld-linux.so.2 0xb7084bec <dlopen_doit+156> from /lib/tls/i686/cmov/libdl.so.2 0xb7f4c716 <_dl_catch_error+118> from /lib/ld-linux.so.2 0xb708501c <_dlerror_run+124> from /lib/tls/i686/cmov/libdl.so.2 0xb7084b21 <dlopen@@GLIBC_2.1+65> from /lib/tls/i686/cmov/libdl.so.2 0x82f99d44 ?? from /home/karl/.mozilla/plugins/libflashplayer.so The flash plugin is calling dlopen("libGL.so.1", RTLD_NOW | RTLD_DEEPBIND). If libGL.so.1 is already loaded then the plugin does not make this call. RTLD_DEEPBIND causes the change in symbol resolution behavior and jemalloc interacts badly with this (bug 493541).
Comment 53•15 years ago
|
||
FF RC3 : !!! [Hook] hook(): title not found at some point, still freezes, ^C kills. LD_PRELOAD=/lib/tls/i686/cmov/libc.so.6 /home/dan/Desktop/firefox/firefox no error, needs kill -9 to kill LD_PRELOAD=/usr/lib/libGL.so.1 /home/dan/Desktop/firefox/firefox -no-remote Succeeds!
Comment 54•15 years ago
|
||
Thanks for the work around, Dan. minus the -no-remote is exactly what I'm using now. No more crashes.
Comment 55•15 years ago
|
||
Yeah, plus if you disable acceleration in Flash, it works without any switches.
Assignee | ||
Updated•15 years ago
|
Assignee: mmelanso → mozbugz
Status: NEW → ASSIGNED
Whiteboard: [patch in bug 493541]
Comment 59•15 years ago
|
||
What is the actual status on this as of now? The "workaround" of disabling Hardware Acceleration is not a viable solution, as this is needed for just the purpose it is being disabled for: full screen fast frame-rate display of images! IMHO, the Dupes and the votes show this one needs some specific answers and an ETA on a permanent fix.
Comment 60•15 years ago
|
||
Re: comment #59 Why not use the preload workaround? Is an easy workaround, and doesn't slow anything down. Is main reason I've stopped caring about this bug, since it has stopped impacting my life. :) Mostly just following out of idle curiosity.
Assignee | ||
Updated•15 years ago
|
Summary: Crash when enabling fullscreen flash video [@ @0x110430 ] → Crash when enabling fullscreen flash video [@ @0x110430 ][@ libc-2.9.so@0x2d097 ]
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago → 15 years ago
Flags: blocking1.9.2? → blocking1.9.2+
Resolution: --- → DUPLICATE
Assignee | ||
Updated•15 years ago
|
Flags: wanted1.9.1.x?
Updated•15 years ago
|
Status: RESOLVED → VERIFIED
Flags: wanted1.9.0.x?
Comment 64•15 years ago
|
||
(In reply to comment #60) > Re: comment #59 > Why not use the preload workaround? Is an easy workaround, and doesn't slow > anything down. > Is main reason I've stopped caring about this bug, since it has stopped > impacting my life. :) This solution solves temporarily the full screen mode of Flash videos but it causes another error: I can't use the print option from the context menu in Flash videos. The preload of that library causes "segmentation fault" when I try to use that option.
Updated•15 years ago
|
Flags: blocking1.9.2+
Updated•13 years ago
|
Crash Signature: [@ @0x110430 ]
[@ libc-2.9.so@0x2d097 ]
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•