Closed Bug 473428 Opened 17 years ago Closed 16 years ago

Attempts to print or print preview any web site cause Firefox to crash.

Categories

(Core :: Memory Allocator, defect)

Product:
Core
Component:
Memory Allocator
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 493541

People

(Reporter: moby, Assigned: karlt)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [patch in bug 493541])

Attachments

(2 files, 1 obsolete file)

crashreporter dump
130.99 KB, application/octet-stream
Details
Crashreporter dump extra.
689 bytes, application/octet-stream
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5 Any time File -> Print or File -> Print Preview is used, Firefox crashes. This happens regardless of what site is being viewed, happens if all extensions are disabled, and also happens if all plugins are removed. This is seen on Linux with gnome 2.24.1 and gtk2 version 2.14.4-8.1. The crash occurs with a message of *** glibc detected *** /opt/firefox/firefox-bin: free(): invalid pointer: 0xa572ea80 *** Reproducible: Always Steps to Reproduce: 1. Go to any web site 2. Click on File -> Print or File -> Print preview 3. Actual Results: Firefox crashes. Expected Results: Should have printed or previewed.
Attached file crashreporter dump —
We can not use any binary crash dump files, we need either a crash ID from a Mozilla.org build or you have to create a stack trace with gdb. http://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report
Thanks Matthias - understood. I am attaching a stack trace (and some other stuff) from GDB.
Attached file useless (obsolete) —
Comment on attachment 356832 [details] useless you didn't understand. your local debugger will only work if you have debugging symbols, which generally means you'll have to build firefox yourself, with one of --enable-debugger-info-modules / --enable-debug
Attachment #356832 - Attachment description: Debug information gathered via gdb. → useless
Attachment #356832 - Attachment is obsolete: true
Attachment #356832 - Attachment mime type: application/octet-stream → text/plain
Well, I understood to the extent it was presented in your statements and in the link you had provided. At the present time, I do not have the resources to build firefox with debugging information etc. Crashreporter inside of Firefox is failing with the following message: "Crash report submission failed: Peer certificate cannot be authenticated with known CA certificates" so I cannot use that to submit crash information. I am not sure what it would take to get Crashreporter to work - while I understand what it is complaining about, I have no clue where it looks for certificates, what hosts it tries to contact etc. I did find a work-around - I downloaded and ran the "standard" Firefox rpm provided by my distro. and it does not crash on print or print preview.
The crash reporter error for sending should be easy to fix if you install the CA root package from your distro because the crashreporter is using systemlibs.
I verified I have the latest and correct CA root package from my distro (openSUSE 11.1 btw), and still no joy. Crashreporter still fails. It used to work fine since I used to have it submit before but seems to have broken as of about a month ago. I think we can close this bug since I am not sure what else to do - I have a work around in place for Firefox by using the one provided by my distro. If there is anything you would like me to do, I can give it a shot, otherwise thank you for your time and energy and I can go about using the workaround I have in place.
I can confirm it. The error is a bit different on first start, but it changes to the above after restart. Though, I would like to know what is considered crash ID? I sent it 3 times, but there was no other feedback than the report was sent successfully.
(In reply to comment #10) > Though, I would like to know what is considered crash ID? > I sent it 3 times, but there was no other feedback than the report was sent > successfully. Please check about:crashes. You should find the crash ids AFAIK. I'm also interested why curl on openSUSE 11.1 seems to fail the certificate check. Because of some magic redirects I'm failing to check which certificate is used on https://crash-reports.mozilla.com. Could someone give me a pointer?
>Though, I would like to know what is considered crash ID? open the URL from comment #3 which explains everything including nice images but about:crashes is the short version. >Because of some magic redirects I'm failing to check which certificate is used >on https://crash-reports.mozilla.com. Could someone give me a pointer? That's only a 302 if you do a get request instead of post :-) You could try openssl s_client -host crash-reports.mozilla.com -port 443
Reporter, please make sure that openssl-certs is installed and run "c_rehash" in /etc/ssl/certs. Submitting crash reports should hopefully work then.
Thanks Wolfgang - c_rehash got crashreporter working. The crash ID is a334b641-ee96-4dbb-ba4c-2ce7e2090114.
Top of the stack of bp-a334b641-ee96-4dbb-ba4c-2ce7e2090114 0 libc-2.9.so libc-2.9.so@0x2a9d6 1 libc-2.9.so libc-2.9.so@0x2c2d7 2 libc-2.9.so libc-2.9.so@0x66a34 3 libc-2.9.so libc-2.9.so@0x6c9d4 4 libc-2.9.so libc-2.9.so@0x6e2eb 5 libnsl-2.9.so libnsl-2.9.so@0xfe6b 6 libpthread-2.9.so libpthread-2.9.so@0xad8a 7 libnss_nis-2.9.so libnss_nis-2.9.so@0x554d 8 libnss_compat-2.9.so libnss_compat-2.9.so@0x2140 9 libnss_compat-2.9.so libnss_compat-2.9.so@0x22cd 10 libc-2.9.so libc-2.9.so@0xe27fc 11 libc-2.9.so libc-2.9.so@0x991a6 12 libcups.so.2 libcups.so.2@0x2ca74 13 libcups.so.2 libcups.so.2@0xf358 14 libcups.so.2 libcups.so.2@0x10d32 15 libcups.so.2 libcups.so.2@0x110fd 16 libxul.so nsPSPrinterList::GetPrinterList mozilla/gfx/src/psshared/nsPSPrinters.cpp:105 17 libxul.so GlobalPrinters::InitializeGlobalPrinters mozilla/widget/src/gtk2/nsDeviceContextSpecG.cpp:1104 18 libxul.so GlobalPrinters::GetDefaultPrinterName mozilla/widget/src/gtk2/nsDeviceContextSpecG.cpp:1138
Severity: normal → critical
Component: General → Print Preview
Keywords: crash
Product: Firefox → Core
QA Contact: general → printing
Here is mine: 1) right after start bp-a334b641-ee96-4dbb-ba4c-2ce7e2090114 2) last bp-ad3802e8-b695-4da8-a116-008bc2090113 I can't see the difference ;-)
The firefox script has command: moz_libdir=/usr/local/lib/firefox-3.0.5 which doesn't exist when binary is not result of compilation. Problem should be fixed by removing above line and adding moz_libdir after $progbase is defined: progbase=`basename "$progname"` moz_libdir=$progbase
Thanks Rajko, that did not work for me. Here is the appropriate snippet from the firefox script after I edited it per your point: # moz_libdir=/usr/local/lib/firefox-3.0.5 # Use run-mozilla.sh in the current dir if it exists # If not, then start resolving symlinks until we find run-mozilla.sh found=0 progname="$0" curdir=`dirname "$progname"` progbase=`basename "$progname"` moz_libdir=$progbase run_moz="$curdir/run-mozilla.sh" Print or print preview still cause a crash.
I should log out and again login first. What happened: I run by mistake first just 'firefox' from console (in another session and another user), which started regular openSUSE Firefox. When I realized that I quitted that one, changed directory where is copy of downloaded Firefox and run './firefox', and both print options worked fine. Looking in the firefox script moz_libdir appeared as wrong, I changed as suggested in comment #17, opened another console, ran ./firefox and it worked. What I missed is to end session, under wrong assumption that only xterm environment was changed. Now, after your comment I restarted session and error is still here. BTW, I checked now script for firefox 3.0.3 that works fine, and it is the same as for 3.0.5, so moz_libdir is ignored if it is empty.
I've started seeing see a crash like that since a few days on my openSUSE Factory system (worked fine until a recent distro update) with my self-built versions of both SeaMonkey and Minefield. Minefield gives me the following line, so I believe this might be the same error: *** glibc detected *** /opt/firefox-trunk/firefox-bin: free(): invalid pointer: 0xb5c56d80 *** Also, the Firefox 3.0.x provided by openSUSE works fine, as described earlier in this bug. I tried a SeaMonkey debug build, which ended up cycling rapidly through console output like this when crashing: UNKNOWN [/opt/seamonkey-dbg/libxpcom_core.so +0x0009841C] NS_DescribeCodeAddress+0x000000D1 [/opt/seamonkey-dbg/libxpcom_core.so +0x00098514] UNKNOWN [/opt/seamonkey-dbg/libxul.so +0x00029B9B] NS_StackWalk+0x0000002B [/opt/seamonkey-dbg/libxpcom_core.so +0x00098363] UNKNOWN [/opt/seamonkey-dbg/libxul.so +0x00029B20] UNKNOWN [/opt/seamonkey-dbg/libxul.so +0x0002A6C8] UNKNOWN 0xffffe400 abort+0x00000188 [/lib/libc.so.6 +0x0002C2C8] UNKNOWN [/opt/seamonkey-dbg/seamonkey-bin +0x0000C437] UNKNOWN [/opt/seamonkey-dbg/seamonkey-bin +0x0000D223] realloc+0x000000E7 [/opt/seamonkey-dbg/seamonkey-bin +0x0000F717] UNKNOWN [/usr/lib/libstdc++.so.6 +0x000BCE07] UNKNOWN [/usr/lib/libstdc++.so.6 +0x000BE9C4] __cxa_demangle+0x00000069 [/usr/lib/libstdc++.so.6 +0x000BEB99] UNKNOWN [/opt/seamonkey-dbg/libxpcom_core.so +0x0009841C] NS_DescribeCodeAddress+0x000000D1 [/opt/seamonkey-dbg/libxpcom_core.so +0x00098514] UNKNOWN [/opt/seamonkey-dbg/libxul.so +0x00029B9B] NS_StackWalk+0x0000002B [/opt/seamonkey-dbg/libxpcom_core.so +0x00098363] UNKNOWN [/opt/seamonkey-dbg/libxul.so +0x00029B20] UNKNOWN [/opt/seamonkey-dbg/libxul.so +0x0002A6C8] UNKNOWN 0xffffe400 abort+0x00000188 [/lib/libc.so.6 +0x0002C2C8] UNKNOWN [/opt/seamonkey-dbg/seamonkey-bin +0x0000C437] UNKNOWN [/opt/seamonkey-dbg/seamonkey-bin +0x0000D223] realloc+0x000000E7 [/opt/seamonkey-dbg/seamonkey-bin +0x0000F717] UNKNOWN [/usr/lib/libstdc++.so.6 +0x000BCE07] UNKNOWN [/usr/lib/libstdc++.so.6 +0x000BE9C4] __cxa_demangle+0x00000069 [/usr/lib/libstdc++.so.6 +0x000BEB99] UNKNOWN [/opt/seamonkey-dbg/libxpcom_core.so +0x0009841C] NS_DescribeCodeAddress+0x000000D1 [/opt/seamonkey-dbg/libxpcom_core.so +0x00098514] UNKNOWN [/opt/seamonkey-dbg/libxul.so +0x00029B9B] NS_StackWalk+0x0000002B [/opt/seamonkey-dbg/libxpcom_core.so +0x00098363] UNKNOWN [/opt/seamonkey-dbg/libxul.so +0x00029B20] UNKNOWN [/opt/seamonkey-dbg/libxul.so +0x0002A6C8] UNKNOWN 0xffffe400 abort+0x00000188 [/lib/libc.so.6 +0x0002C2C8] UNKNOWN [/opt/seamonkey-dbg/seamonkey-bin +0x0000C437] UNKNOWN [/opt/seamonkey-dbg/seamonkey-bin +0x0000D223] realloc+0x000000E7 [/opt/seamonkey-dbg/seamonkey-bin +0x0000F717] UNKNOWN [/usr/lib/libstdc++.so.6 +0x000BCE07] UNKNOWN [/usr/lib/libstdc++.so.6 +0x000BE9C4] When I start gdb and try to get a backtrace, I get not too helpful output on the current thread: (gdb) bt #0 0xffffe430 in __kernel_vsyscall () #1 0xb7091e63 in ?? () from /lib/libc.so.6 #2 0xb70254d1 in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) The Necko threads all look fine, either polling or waiting without problems, the other left thread is the following one: (gdb) bt #0 0xb70bbb3b in _dl_addr () from /lib/libc.so.6 #1 0xb7c77450 in dladdr () from /lib/libdl.so.2 #2 0xb7d5c499 in NS_DescribeCodeAddress (aPC=0xb7215e07, aDetails=0xb4903920) at /mnt/mozilla/hg/comm-central/mozilla/xpcom/base/nsStackWalk.cpp:1503 #3 0xb7dbdb9b in PrintStackFrame (aPC=0xb7215e07, aClosure=0x0) at /mnt/mozilla/hg/comm-central/mozilla/toolkit/xre/nsSigHandlers.cpp:126 #4 0xb7d5c363 in NS_StackWalk (aCallback=0xb7dbdb6e <PrintStackFrame>, aSkipFrames=2, aClosure=0x0) at /mnt/mozilla/hg/comm-central/mozilla/xpcom/base/nsStackWalk.cpp:1447 #5 0xb7dbdb20 in ah_crap_handler (signum=6) at /mnt/mozilla/hg/comm-central/mozilla/toolkit/xre/nsSigHandlers.cpp:142 #6 0xb7dbe6c8 in nsProfileLock::FatalSignalHandler (signo=6) at nsProfileLock.cpp:216 #7 <signal handler called> #8 0xffffe430 in __kernel_vsyscall () #9 0xb6fde990 in raise () from /lib/libc.so.6 #10 0xb6fe02c8 in abort () from /lib/libc.so.6 #11 0x08054437 in arena_malloc (arena=0x8049fc0, size=15472, zero=134578031) at /mnt/mozilla/hg/comm-central/mozilla/memory/jemalloc/jemalloc.c:3957 #12 0x08058317 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) That jemalloc line sounds somewhat like a smoking gun to me, the "corrupt stack?" things just look scary for my untrained mind ;-) I then tried to attach gdb before crashing already, then continue running of the build and open print preview. This was somewhat helpful, as the console output didn't start cycling that load of things, but remained at one single output line: /mnt/mozilla/hg/comm-central/mozilla/memory/jemalloc/jemalloc.c:3957: Failed assertion: "arena->magic == ARENA_MAGIC" Somehow that doesn't sound to me like jemalloc likes us here...
oh, on that last crash with the assertion failure, gdb says this after the crash: Program received signal SIGABRT, Aborted. [Switching to Thread 0xb4bffb90 (LWP 16438)] 0xffffe430 in __kernel_vsyscall () (gdb) bt #0 0xffffe430 in __kernel_vsyscall () #1 0xb6fa3990 in raise () from /lib/libc.so.6 #2 0xb6fa52c8 in abort () from /lib/libc.so.6 #3 0x08054437 in arena_malloc (arena=0x8049fc0, size=16438, zero=134578031) at /mnt/mozilla/hg/comm-central/mozilla/memory/jemalloc/jemalloc.c:3957 #4 0x08058317 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Jason, Stuart, as our only pointer to what's happening there seems to be this jemalloc assertion, any idea what could be up there? Hmm, actually, looking at the breakpad reports in comment #16, my crash might be different than what was originally reported here. On the other hand, it could be the same and gdb and breakpad might just see different stages or details of the stacks. I'm happy to transfer my analysis of my crash elsewhere if needed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
sounds like someone might be stomping on memory
IIUC, the Firefox process should not be calling glibc's free, and so it seems that bug 493541 might be one the right track.
Depends on: 493541
kairo: this sounds like a job for valgrind.
(In reply to comment #25) > kairo: this sounds like a job for valgrind. Actually, the openSUSE guys already seem to know that the issue I'm seeing is a patch they have in libc that in our cause causes memory allocated with jemalloc being freed with libc's free() and that messes up of course, see https://bugzilla.novell.com/show_bug.cgi?id=503151 That leaves the question open if the original problem reported here is related to this as well (in which case this is an openSUSE bug an INVALID here) or if it's something different, in which case it would be interesting if it's still happening or working now.
Component: Print Preview → jemalloc
QA Contact: printing → jemalloc
Assignee: nobody → mozbugz
Status: NEW → ASSIGNED
Whiteboard: [patch in bug 493541]
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: