Crash [@ libc-2.11.so + 0x326b5 ] during browser_auth.js on Linux64 mochitest-other debug

RESOLVED FIXED

Status

()

defect
--
critical
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: mstange, Assigned: cjones)

Tracking

({crash, regression})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [hardblocker], crash signature)

Attachments

(3 attachments, 1 obsolete attachment)

Reporter

Description

9 years ago
This is a completely unhelpful bug report, but I guess filing a placeholder bug is better than not filing anything.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1292926059.1292928491.7893.gz&fulltext=1#err4
Rev3 Fedora 12x64 mozilla-central debug test mochitest-other on 2010/12/21 02:07:39 
s: talos-r3-fed64-031

Crash reason:  SIGABRT
Crash address: 0x1f40000089c

Thread 0 (crashed)
 0  libc-2.11.so + 0x326b5
    rbx = 0x00000400   r12 = 0x0000004d   r13 = 0x374f0c10   r14 = 0x0000008a
    r15 = 0x00000007   rip = 0xd2e326b5   rsp = 0x374f08e8   rbp = 0x374f1330
    Found by: given as instruction pointer in context
 1  libc-2.11.so + 0x33e94
    rip = 0xd2e33e95   rsp = 0x374f08f0
    Found by: stack scanning
 2  libc-2.11.so + 0x13c7b2
    rip = 0xd2f3c7b3   rsp = 0x374f0918
    Found by: stack scanning
 3  libc-2.11.so + 0x13c7b6
    rip = 0xd2f3c7b7   rsp = 0x374f0938
    Found by: stack scanning
 4  libc-2.11.so + 0x13ade3
    rip = 0xd2f3ade4   rsp = 0x374f0958
    Found by: stack scanning
 5  libc-2.11.so + 0x13c7b2
    rip = 0xd2f3c7b3   rsp = 0x374f0968
    Found by: stack scanning
 6  libc-2.11.so + 0x13c7b6
    rip = 0xd2f3c7b7   rsp = 0x374f0988
    Found by: stack scanning
Component: General → Widget: Gtk
QA Contact: general → gtk
Blocks: 590073
No longer blocks: 438871
Severity: normal → critical
Whiteboard: [orange]
Comment hidden (Legacy TBPL/Treeherder Robot)
Reporter

Comment 2

9 years ago
This second occurrence had a much more helpful stack:

Thread 0 (crashed)
 0  linux-gate.so + 0x424
    eip = 0x00455424   esp = 0xbff66e0c   ebp = 0xbff66e24   ebx = 0x0000082b
    esi = 0x00000000   edi = 0x00c58ff4   eax = 0x00000000   ecx = 0x0000082b
    edx = 0x00000006   efl = 0x00000206
    Found by: given as instruction pointer in context
 1  libc-2.11.so + 0x2c349
    eip = 0x00b1434a   esp = 0xbff66e2c   ebp = 0xbff66f4c
    Found by: previous frame's frame pointer
 2  libc-2.11.so + 0x67e5c
    eip = 0x00b4fe5d   esp = 0xbff66f54   ebp = 0xbff67590
    Found by: previous frame's frame pointer
 3  libc-2.11.so + 0x6e260
    eip = 0x00b56261   esp = 0xbff67598   ebp = 0xbff675c8
    Found by: previous frame's frame pointer
 4  libxul.so!free [nsTraceMalloc.c : 1303 + 0xa]
    eip = 0x02735f1b   esp = 0xbff675d0   ebp = 0xbff675f8
    Found by: previous frame's frame pointer
 5  libmozalloc.so!moz_free [mozalloc.cpp : 92 + 0xa]
    eip = 0x00825fd4   esp = 0xbff67600   ebp = 0xbff67608   ebx = 0x008271f0
    Found by: call frame info
 6  libxul.so!nsWindow::ResizeTransparencyBitmap [mozalloc.h : 265 + 0xa]
    eip = 0x0233209f   esp = 0xbff67610   ebp = 0xbff67668   ebx = 0x0340e678
    Found by: call frame info
 7  libxul.so!nsWindow::NativeResize [nsWindow.cpp : 4310 + 0x18]
    eip = 0x023322c0   esp = 0xbff67670   ebp = 0xbff676a8   ebx = 0x0340e678
    Found by: call frame info
 8  libxul.so!nsWindow::Resize [nsWindow.cpp : 1196 + 0x36]
    eip = 0x02323c28   esp = 0xbff676b0   ebp = 0xbff67708   ebx = 0x0340e678
    Found by: call frame info
 9  libxul.so!nsView::DoResetWidgetBounds [nsView.cpp : 467 + 0x44]
    eip = 0x018dbb27   esp = 0xbff67710   ebp = 0xbff67798   ebx = 0x0340e678
    Found by: call frame info
...
13  libxul.so!nsMenuPopupFrame::LayoutPopup [nsMenuPopupFrame.cpp : 495 + 0x20]
    eip = 0x0152c0fe   esp = 0xbff67830   ebp = 0xbff67908   ebx = 0x0340e678
    esi = 0x00000066   edi = 0x00000004
    Found by: call frame info
...
26  libxul.so!PresShell::DoReflow [nsPresShell.cpp : 7772 + 0x3b]
    eip = 0x012c3ef9   esp = 0xbff68120   ebp = 0xbff68318   ebx = 0x0340e678
    esi = 0x013e8ae8   edi = 0x0000e8f8
    Found by: call frame info
...
34  libxul.so!nsWindow::OnExposeEvent [nsWindow.cpp : 2234 + 0x27]
    eip = 0x02330efb   esp = 0xbff68630   ebp = 0xbff688b8   ebx = 0x0340e678
    esi = 0x00000283   edi = 0x096d0520
    Found by: call frame info
35  libxul.so!expose_event_cb [nsWindow.cpp : 5507 + 0x22]
    eip = 0x02331489   esp = 0xbff688c0   ebp = 0xbff688e8   ebx = 0x04934a88
    esi = 0xbff68a54   edi = 0x096d0520
    Found by: call frame info

We're resizing a transparent window during an expose event. This transparent window is most probably the arrow panel which was restyled in bug 590073.

Dão is going to back out the Linux-specific part of bug 590073.
No longer blocks: 590073
Keywords: regression
Reporter

Updated

9 years ago
Duplicate of this bug: 620652
This seems to indicate some serious memory handling bug.

However, I'll also comment that, as implemented on Linux, these panels have binary 0 or 1 opacity, so "-moz-transition: opacity 300ms;" makes little sense and is likely to slow things down.
(In reply to comment #5)
> However, I'll also comment that, as implemented on Linux, these panels have
> binary 0 or 1 opacity, so "-moz-transition: opacity 300ms;" makes little sense
> and is likely to slow things down.

Sure, but the patch triggering the crash didn't introduce this, so it's not related to this bug, is it?
Yes, sorry.  The comment is not really related to this bug.
blocking2.0: --- → ?
This bug is holding back theme work.
blocking2.0: - → ?
In what way is this bug holding back theme work? Theme work required for Firefox 4? Which bugs?
It prevents us from styling arrow panels (bug 554937) to actually look like arrow panels. A basic arrow panel styling was implemented in bug 590073 and disabled in comment 3.
Apparently bug 604257 also tracks the arrow panel styling on Linux.
Blocks: 604257
Do we have a way to reproduce this?
(In reply to comment #12)
> Do we have a way to reproduce this?

Backing out http://hg.mozilla.org/mozilla-central/diff/97d9cf2225d6/toolkit/themes/gnomestripe/global/popup.css and clicking the location bar's identity button in a debug build should do it, I think.
I haven't managed to reproduce in a local debug build based on 2a25c4d1ed99 with 97d9cf2225d6 backed out, with any of the following steps:

1) Click on the location bar's identity button.
2) Same as 1 but with valgrind memcheck (and jemalloc disabled).
3) runtests.py --browser-chrome --test-path=toolkit/mozapps/extensions/test/xpinstall (with and without jemalloc)
linux-gate.so is, IIRC, usually abort().

I wonder if we're having memory stomped on by something on Dão's (and the tinderbox's) computer, but not on Karl's. What distributions are you using, Karl & Dão?

I think we need to find some form of workaround or fix for this in order to finish the theme work.
Assignee: nobody → karlt
blocking2.0: ? → betaN+
OK I am unable to duplicate this issue using my own debug or optimized builds.  The difference between my builds and the Official builds, is that the official builds are created using gcc 4.3.3 and I am running gcc version 4.5.1.

So, I think the reason we are running into this crash in libc is that this is a bug in libc that has really long since been fixed.
(In reply to comment #16)
> OK I am unable to duplicate this issue using my own debug or optimized builds. 
> The difference between my builds and the Official builds, is that the official
> builds are created using gcc 4.3.3 and I am running gcc version 4.5.1.
> 
> So, I think the reason we are running into this crash in libc is that this is a
> bug in libc that has really long since been fixed.

Further testing seems to confirm this is most likely either a compiler or libc issue and not an issue with Mozilla code.  However, that really brings us no closer to a solution for Firefox 4.

It is way too late in the release process to even consider changing gcc versions :-(

Comment 18

9 years ago
http://hg.mozilla.org/mozilla-central/rev/e080aa16fae3 might have triggered this again.  I've backed it out, and closed the tree to wait to see if we go green again.

Comment 19

9 years ago
BTW, I don't know why a memory corruption bug which is triggered by some CSS changes is not a hard blocker.  Seems *_really_* scary.
I, too, fail to understand why "some CSS rules cause arbitrary crashes on Linux" wouldn't be a hardblocker. And thus!
Whiteboard: [softblocker] → [hardblocker]
Web content can't create transparent widgets, so it can't trigger this bug directly.
Karl, can you try grabbing a tryserver debug build and running it on the Tinderbox VM image?
Assignee: karlt → jones.chris.g
So the way to tickle this bug is to uncomment the stuff from comment 3?  It looks like the problems noted from comment 20 on were caused by a bad infra change.
(In reply to comment #24)
> So the way to tickle this bug is to uncomment the stuff from comment 3?

yes
(gdb) bt
#0  0x00002b9bfea21ba5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00002b9bfea256b0 in abort () at abort.c:92
#2  0x00002b9bfea5b43b in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00002b9bfea654b6 in malloc_printerr (action=3, str=0x2b9bfeb39098 "double free or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6283
#4  0x00002b9bfea6bc83 in __libc_free (mem=<value optimized out>) at malloc.c:3738
#5  0x00002b9bf876d5eb in free (ptr=0x2b9c0e4a4b60) at /home/cjones/mozilla/mozilla-central/tools/trace-malloc/lib/nsTraceMalloc.c:1303
#6  0x00002b9bfa93fee4 in moz_free (ptr=0x2b9c0e4a4b60) at /home/cjones/mozilla/mozilla-central/memory/mozalloc/mozalloc.cpp:92
#7  0x00002b9bf83163da in operator delete [] (this=0x2b9c0d1d6c00, aNewWidth=453, aNewHeight=82) at ../../../dist/include/mozilla/mozalloc.h:265
#8  nsWindow::ResizeTransparencyBitmap (this=0x2b9c0d1d6c00, aNewWidth=453, aNewHeight=82) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:4702
#9  0x00002b9bf83152e5 in nsWindow::NativeResize (this=0x2b9c0d1d6c00, aX=118, aY=102, aWidth=453, aHeight=82, aRepaint=1) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:4349
#10 0x00002b9bf830c6e6 in nsWindow::Resize (this=0x2b9c0d1d6c00, aX=118, aY=102, aWidth=453, aHeight=82, aRepaint=1) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:1203
#11 0x00002b9bf785dd79 in nsView::DoResetWidgetBounds (this=0x2b9c0d21b250, aMoveOnly=0, aInvalidateChangedSize=1) at /home/cjones/mozilla/mozilla-central/view/src/nsView.cpp:475
#12 0x00002b9bf785d7cf in nsView::ResetWidgetBounds (this=0x2b9c0d21b250, aRecurse=0, aMoveOnly=0, aInvalidateChangedSize=1) at /home/cjones/mozilla/mozilla-central/view/src/nsView.cpp:374
#13 0x00002b9bf7862147 in nsViewManager::ProcessPendingUpdates (this=0x2b9c0c7b39f0, aView=0x2b9c0d21b250, aDoInvalidate=1) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:464
#14 0x00002b9bf7862172 in nsViewManager::ProcessPendingUpdates (this=0x2b9c0c7b39f0, aView=0x2b9c0c698d00, aDoInvalidate=1) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:470
#15 0x00002b9bf7865562 in nsViewManager::FlushPendingInvalidates (this=0x2b9c0c7b39f0) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:1637
#16 0x00002b9bf78650f9 in nsViewManager::TriggerRefresh (this=0x2b9c0c7b39f0, aUpdateFlags=0) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:1535
#17 0x00002b9bf7865246 in nsViewManager::EndUpdateViewBatch (this=0x2b9c0c7b39f0, aUpdateFlags=0) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:1570
#18 0x00002b9bf7180712 in nsIViewManager::UpdateViewBatch::EndUpdateViewBatch (this=0x7fff0e5d9b50, aUpdateFlags=0) at ../../dist/include/nsIViewManager.h:335
#19 0x00002b9bf78634c3 in nsViewManager::DispatchEvent (this=0x2b9c0c7b39f0, aEvent=0x7fff0e5d9e90, aView=0x2b9c0c698d00, aStatus=0x7fff0e5d9cfc) at /home/cjones/mozilla/mozilla-central/view/src/nsViewManager.cpp:900
#20 0x00002b9bf785c880 in HandleEvent (aEvent=0x7fff0e5d9e90) at /home/cjones/mozilla/mozilla-central/view/src/nsView.cpp:161
#21 0x00002b9bf830ab1e in nsWindow::DispatchEvent (this=0x2b9c0c698d90, aEvent=0x7fff0e5d9e90, aStatus=@0x7fff0e5da078) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:571
#22 0x00002b9bf830eccb in nsWindow::OnExposeEvent (this=0x2b9c0c698d90, aWidget=0x1c17e30, aEvent=0x7fff0e5da600) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:2241
#23 0x00002b9bf83181a6 in expose_event_cb (widget=0x1c17e30, event=0x7fff0e5da600) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsWindow.cpp:5546
#24 0x00002b9bfb4dd9d8 in _gtk_marshal_BOOLEAN__BOXED (closure=0x2b9c0c630350, return_value=0x7fff0e5da2d0, n_param_values=<value optimized out>, param_values=0x2409ad0, invocation_hint=<value optimized out>, marshal_data=0x2b9bf8318137) at /build/buildd/gtk+2.0-2.22.0/gtk/gtkmarshalers.c:86
#25 0x00002b9bfd1bda6e in g_closure_invoke (closure=0x2b9c0c630350, return_value=0x7fff0e5da2d0, n_param_values=2, param_values=0x2409ad0, invocation_hint=0x7fff0e5da290) at /build/buildd/glib2.0-2.26.0/gobject/gclosure.c:766
#26 0x00002b9bfd1d34d7 in signal_emit_unlocked_R (node=0x1b18a80, detail=<value optimized out>, instance=<value optimized out>, emission_return=<value optimized out>, instance_and_params=<value optimized out>) at /build/buildd/glib2.0-2.26.0/gobject/gsignal.c:3252
#27 0x00002b9bfd1d47db in g_signal_emit_valist (instance=0x1c17e30, signal_id=<value optimized out>, detail=0, var_args=0x7fff0e5da480) at /build/buildd/glib2.0-2.26.0/gobject/gsignal.c:2993
#28 0x00002b9bfd1d4f53 in g_signal_emit (instance=0x6455, signal_id=25685, detail=6) at /build/buildd/glib2.0-2.26.0/gobject/gsignal.c:3040
#29 0x00002b9bfb5f66df in gtk_widget_event_internal (widget=0x1c17e30, event=0x7fff0e5da600) at /build/buildd/gtk+2.0-2.22.0/gtk/gtkwidget.c:4985
#30 0x00002b9bfb4d70d1 in IA__gtk_main_do_event (event=0x7fff0e5da600) at /build/buildd/gtk+2.0-2.22.0/gtk/gtkmain.c:1601
#31 0x00002b9bfc6169da in _gdk_window_process_updates_recurse (window=0x1b05360, expose_region=0x22b1580) at /build/buildd/gtk+2.0-2.22.0/gdk/gdkwindow.c:5424
#32 0x00002b9bfc61346b in gdk_window_process_updates_internal (window=0x1b05360) at /build/buildd/gtk+2.0-2.22.0/gdk/gdkwindow.c:5583
#33 0x00002b9bfc6152e1 in IA__gdk_window_process_all_updates () at /build/buildd/gtk+2.0-2.22.0/gdk/gdkwindow.c:5691
#34 0x00002b9bfc615349 in gdk_window_update_idle (data=0x6455) at /build/buildd/gtk+2.0-2.22.0/gdk/gdkwindow.c:5317
#35 0x00002b9bfc5f0626 in gdk_threads_dispatch (data=0x2b9c0c49b2c0) at /build/buildd/gtk+2.0-2.22.0/gdk/gdk.c:512
#36 0x00002b9bfdc75342 in g_main_dispatch (context=0x1b08c10) at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2149
#37 g_main_context_dispatch (context=0x1b08c10) at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2702
#38 0x00002b9bfdc792a8 in g_main_context_iterate (context=0x1b08c10, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2780
#39 0x00002b9bfdc7945c in g_main_context_iteration (context=0x1b08c10, may_block=0) at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2843
#40 0x00002b9bf831d6ba in nsAppShell::ProcessNextNativeEvent (this=0x2b9c0c013f00, mayWait=0) at /home/cjones/mozilla/mozilla-central/widget/src/gtk2/nsAppShell.cpp:144
#41 0x00002b9bf8346b53 in nsBaseAppShell::DoProcessNextNativeEvent (this=0x2b9c0c013f00, mayWait=0) at /home/cjones/mozilla/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:176
#42 0x00002b9bf8346eed in nsBaseAppShell::OnProcessNextEvent (this=0x2b9c0c013f00, thr=0x2b9c0c000e30, mayWait=0, recursionDepth=0) at /home/cjones/mozilla/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:318
#43 0x00002b9bf8733958 in nsThread::ProcessNextEvent (this=0x2b9c0c000e30, mayWait=0, result=0x7fff0e5daa2c) at /home/cjones/mozilla/mozilla-central/xpcom/threads/nsThread.cpp:597
#44 0x00002b9bf86c0ad8 in NS_ProcessNextEvent_P (thread=0x2b9c0c000e30, mayWait=0) at nsThreadUtils.cpp:250
#45 0x00002b9bf84d159c in mozilla::ipc::MessagePump::Run (this=0x1b95f10, aDelegate=0x1b95fa0) at /home/cjones/mozilla/mozilla-central/ipc/glue/MessagePump.cpp:110
#46 0x00002b9bf87a629d in MessageLoop::RunInternal (this=0x1b95fa0) at /home/cjones/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:219
#47 0x00002b9bf87a6222 in MessageLoop::RunHandler (this=0x1b95fa0) at /home/cjones/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:202
#48 0x00002b9bf87a61b3 in MessageLoop::Run (this=0x1b95fa0) at /home/cjones/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:176
#49 0x00002b9bf8346bdf in nsBaseAppShell::Run (this=0x2b9c0c013f00) at /home/cjones/mozilla/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:195
#50 0x00002b9bf805f84b in nsAppStartup::Run (this=0x1c396c0) at /home/cjones/mozilla/mozilla-central/toolkit/components/startup/src/nsAppStartup.cpp:218
#51 0x00002b9bf6e8f4a1 in XRE_main (argc=4, argv=0x7fff0e5db4f8, aAppData=0x1ac7a30) at /home/cjones/mozilla/mozilla-central/toolkit/xre/nsAppRunner.cpp:3787
#52 0x0000000000401272 in main (argc=5, argv=0x7fff0e5db4f8) at /home/cjones/mozilla/mozilla-central/browser/app/nsBrowserApp.cpp:158
The problem is that during the dispatch of NS_PAINT, the gtk2 nsWindow bounds change (shrink), and we try to update the alpha mask for an incorrectly-sized rect.  It looks like we have two options for fixing the bug

 - dispatch NS_WILL_PAINT immediately on entering OnExposeEvent, then clip the expose area to mBounds after that dispatch.
 - in UpdateTranslucentWindowAlphaInternal(), clip aRect to mBounds.

I'm not sure which is preferable; not sure which would be less glitchy gfx-wise.
Depends on part in bug 627273, but that's ready to land at any time.
Attachment #506943 - Flags: superreview?(roc)
Attachment #506943 - Flags: review?(karlt)
Attachment #506941 - Flags: superreview?(roc) → superreview+
+        // XXX this lies when we're using GL compositing

I think you need to fix this now, because it'll start to matter now that we're firing WILL_PAINT.

Also, please don't change these assertions to ABORT_IF_FALSE. That's just unnecessary crashy-crashy.
(In reply to comment #32)
> +        // XXX this lies when we're using GL compositing
> 
> I think you need to fix this now, because it'll start to matter now that we're
> firing WILL_PAINT.
> 

OK.

> Also, please don't change these assertions to ABORT_IF_FALSE. That's just
> unnecessary crashy-crashy.

Shrug, OK.  We know that we get crashy-crashy when the old one fails.  The new one is uninteresting right now so I dropped it.
Attachment #506943 - Attachment is obsolete: true
Attachment #506993 - Flags: superreview?(roc)
Attachment #506993 - Flags: review?(karlt)
Attachment #506943 - Flags: superreview?(roc)
Attachment #506943 - Flags: review?(karlt)
Attachment #506993 - Flags: superreview?(roc) → superreview+
Comment on attachment 506993 [details] [diff] [review]
Dispatch WILL_PAINT before PAINT to allow scripts etc. to run, which may change the window bounds. v2

>     nsPaintEvent event(PR_TRUE, NS_PAINT, this);
>     event.refPoint.x = aEvent->area.x;
>     event.refPoint.y = aEvent->area.y;
>-    event.willSendDidPaint = PR_TRUE;

Leave this in.  r+ on the rest.
Attachment #506993 - Flags: review?(karlt) → review+
http://hg.mozilla.org/mozilla-central/rev/23cfa8965c9e
http://hg.mozilla.org/mozilla-central/rev/0f592a972482

Dão, I assume you'll re-land the CSS changes in another bug.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Crash Signature: [@ libc-2.11.so + 0x326b5 ]
You need to log in before you can comment on or make changes to this bug.