114910 - Bus error in main loop

Status: RESOLVED INCOMPLETE

(Core :: XUL, defect)

Description

[Danek Duvall]

This happens periodically with a few builds over the past week.  I'm getting it
more frequently with 20011212 than with earlier ones.  Basically, Mozilla dumps
core with a bus error in what looks like the gdk loop handling.  Most of the
time this manifests itself by simply failing to start up -- a window doesn't
even bother appearing before it dumps core.  But I've also had the browser
spontaneously die on me, leaving a core file with a slightly different backtrace.

The first backtrace is as follows:

dbx -q mozilla-bin core
dbx: warning: writable memory segment 0xfe450000[65536] of size 0 in core
core file header read successfully
where
detected a multithreaded program
t@1 (l@1) terminated by signal BUS (invalid address alignment)
Current function is g_io_unix_dispatch
  137                              user_data);
(dbx) where                                                                  
current thread: t@1
  [1] nsXULElement::GetAttr(0x246b80, 0x0, 0x128180, 0xffbed448, 0xffbed5bc,
0x0), at 0xfcc69e10
  [2] nsXULElement::GetAttr(0x246b80, 0x0, 0x128180, 0xffbed5bc, 0x68,
0x24c6e4), at 0xfcc69bac
  [3] nsXULDocument::OverlayForwardReference::Resolve(0x30da88, 0xf, 0x1, 0x0,
0x246b80, 0x3b), at 0xfccc7820
  [4] nsXULDocument::ResolveForwardReferences(0x15eda0, 0xffbedbc4, 0x7c,
0x30da88, 0xfd0e1c9c, 0xf), at 0xfccafa48
  [5] nsXULDocument::ResumeWalk(0x15eda0, 0x1cfd40, 0x406520, 0x15f020, 0x0,
0x0), at 0xfccc44a0
  [6] nsXULDocument::EndLoad(0x15eda0, 0xffbedf0c, 0x4549c0, 0x1, 0xffbeddd4,
0x0), at 0xfccab724
  [7] XULContentSinkImpl::DidBuildModel(0x454798, 0x1, 0x1, 0x0, 0x15eda0, 0x0),
at 0xfcc96c38
  [8] CWellFormedDTD::DidBuildModel(0x276690, 0x0, 0x1, 0x4548a8, 0x454798,
0x1), at 0xfdb7670c
  [9] nsParser::DidBuildModel(0x4548a8, 0x0, 0xfef983a0, 0x3cdf68, 0x0, 0x0), at
0xfdb6464c
  [10] nsParser::ResumeParse(0x4548a8, 0x1, 0x1, 0xfe83800c, 0x804e03e8, 0x0),
at 0xfdb65ea0
  [11] nsParser::OnStopRequest(0x4548a8, 0x420298, 0x0, 0x0, 0x0, 0x0), at
0xfdb688f4
  [12] nsJARChannel::OnStopRequest(0x420298, 0x2765cc, 0x0, 0x0, 0x0, 0x0), at
0xfd7e1640
  [13] nsOnStopRequestEvent::HandleEvent(0x419258, 0x1, 0x0, 0x2765cc, 0x42029c,
0x435b08), at 0xfd706690
  [14] nsARequestObserverEvent::HandlePLEvent(0x41925c, 0x1, 0x1, 0xff2e0554,
0xff3e2628, 0xfda0a55c), at 0xfd704b20
  [15] PL_HandleEvent(0x41925c, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff123500
  [16] PL_ProcessPendingEvents(0xf95e8, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff1232e4
  [17] nsEventQueueImpl::ProcessPendingEvents(0x7fe38, 0xfe83e814, 0x1, 0x0,
0x0, 0x0), at 0xff125b2c
  [18] event_processor_callback(0x7fe38, 0x9, 0x1, 0xfe83800c, 0x0, 0x0), at
0xfda1ed30
  [19] our_gdk_io_invoke(0x1c1940, 0x1, 0x1c7108, 0x0, 0x0, 0x0), at 0xfda1e5b0
=>[20] g_io_unix_dispatch(source_data = 0x1bee20, current_time = 0xffbee808,
user_data = 0x1c7108), line 137 in "giounix.c"
  [21] g_main_dispatch(dispatch_time = 0xffbee808), line 658 in "gmain.c"
  [22] g_main_iterate(block = 1, dispatch = 1), line 877 in "gmain.c"
  [23] g_main_run(loop = 0x1c7118), line 935 in "gmain.c"
  [24] gtk_main(), line 476 in "gtkmain.c"
  [25] nsAppShell::Run(0x50918, 0x3a28c, 0x0, 0x1c70f8, 0x1c29e0, 0xffbee8ac),
at 0xfda1f99c
  [26] nsAppShellService::Run(0x4ca60, 0xffbeed00, 0x3a28c, 0x0, 0x0, 0x0), at
0xfe50cd5c
  [27] main1(0x3, 0xffbef17c, 0x0, 0x5, 0x0, 0x3), at 0x1f430
  [28] main(0x3, 0xffbef17c, 0xffbef18c, 0x0, 0x0, 0x0), at 0x20ac8

Here's the only stack variable in that function:

(dbx) p *data     
*data = {
    pollfd    = {
        fd      = 9
        events  = 1U
        revents = 1U
    }
    channel   = 0x1c1940
    condition = G_IO_IN
    callback  = 0xfda1e550 = &`libwidget_gtk.so`nsAppShell.cpp`our_gdk_io_invoke
       [non -g, use #__1cRour_gdk_io_invoke6FpnL_GIOChannel_nMGIOCondition_pv_i_]()
}


I don't have a core file for the other bit; when that happens, I'll add another
backtrace.

This is running on Solaris 8 4/01, and compiled with the Sun Workshop Compilers
6.1.  The glib/gtk version is 1.2.8.  I can make the core file available, if
it's useful to anyone.

Comment 1

[Boris Zbarsky [:bzbarsky]]

XUL

Comment 2

[Jesse Ruderman]

Amazingly, this code still exists 8 years later.

Comment 3

[Boris Zbarsky [:bzbarsky]]

That stack is showing a trace in GetAttr, no?  I don't know that there's much we can do with it at this point (or even back then; we would have needed more data about where in GetAttr the browser crashed).