38385 - crash on NY Times

Status: VERIFIED DUPLICATE of bug 36558

(Core :: Layout, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

DESCRIPTION:  For most of this week, Mozilla has been crashing on
http://www.nytimes.com/ about 3/4 of the times that I try to load the page.

STEPS TO REPRODUCE:
 * load http://www.nytimes.com/

ACTUAL RESULTS:
 * crash

EXPECTED RESULTS:
 * no crash

DOES NOT WORK CORRECTLY ON:
 * Linux, mozilla, 2000-05-05-08-M16

ADDITIONAL INFORMATION:
Stack trace from opt build (my debug is old enough that it doesn't crash):
#0  0x0 in ?? ()
#1  0x40c295ec in NSGetModule ()
#2  0x40c09033 in NSGetModule ()
#3  0x40c06d7e in NSGetModule ()
#4  0x40cdc417 in NSGetModule ()
#5  0x40c295f8 in NSGetModule ()
#6  0x40c09033 in NSGetModule ()
#7  0x40dd12b8 in NSGetModule ()
#8  0x40c1208f in NSGetModule ()
#9  0x40dd12b8 in NSGetModule ()
#10 0x40c1208f in NSGetModule ()
...
#51 0x408c07a4 in NSGetModule ()
#52 0x408c00a0 in NSGetModule ()
#53 0x400ac3eb in PL_HandleEvent ()
#54 0x400ac326 in PL_ProcessPendingEvents ()
#55 0x400acfed in nsEventQueueImpl::ProcessPendingEvents ()
#56 0x404d182f in nsAppShell::SetDispatchListener ()
#57 0x404d15fd in keysym2ucs ()
#58 0x4066852a in g_io_unix_dispatch ()
#59 0x40669be6 in g_main_dispatch ()
#60 0x4066a1a1 in g_main_iterate ()
#61 0x4066a341 in g_main_run ()
#62 0x4058f859 in gtk_main ()
#63 0x404d1d0a in nsAppShell::Run ()
#64 0x4044331a in objects ()
#65 0x804b19c in JS_PushArguments ()
#66 0x804b4b3 in JS_PushArguments ()
#67 0x4030ecb3 in __libc_start_main (main=0x804b330 <JS_PushArguments+7360>, 
    argc=1, argv=0xbffff894, init=0x8049330 <_init>, fini=0x804bfd4 <_fini>, 
    rtld_fini=0x4000a350, stack_end=0xbffff88c)
    at ../sysdeps/generic/libc-start.c:78

The top 38 of the NS_GetModule calls are in libraptorhtml.so

Comment 1

[Andreas Franke (gone)]

The crash starts like this:
#0  0x0 in ?? ()
#1  nsLineBox::DeleteLineList ()
#2  nsBlockFrame::Destroy ()
#3  nsAreaFrame::Destroy ()
#4  0x40b84005 in nsComboboxControlFrame::Destroy ()

This is a dup of bug 37493 "<SELECT> crashes in nsLineBox::DeleteLineList (e.g.
composer or www.starwars.com)", which is a dup of bug 36558.


*** This bug has been marked as a duplicate of 36558 ***

Comment 2

[Andreas Franke (gone)]

Attachment: stack trace, PC/Linux, build from 2000042809 source

Comment 3

[R.K.Aa.]

verif

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Hmmm... that stack trace is totally different from the one I reported.  When did
you see the crash?  On loading the page, or leaving it?  I think the crash I'm
seeing may have started since 04-28.

Comment 5

[Andreas Franke (gone)]

David: What do you mean by completely different?
The stack trace you reported starts with NSGetModule () 52 times
(which just indicates that the respective function symbols have
been stripped from the libraries), followed by #53 PL_HandleEvent ().
I have verified that #53 in my stack trace is PL_HandleEvent, too,
and #0 - #52 are from libraries that are usually stripped.
I consistently crashed while loading the side, and the behaviour is
the same for me as on other sites (www.starwars.com, www.winfiles.com,...).
This is different from your experience ("crash 3/4 of the times"), and 
that's the reason why I checked #53 and also tried the 050513 build (without
function symbols).

If you think this is different, feel free to reopen this.
Especially if you have applied rods' patch (switched kGoodToGo)
and this still appears, or if this still appears with rods fix
to bug 36558 being active, you should really reopen this one.
But without further information I'm still convinced that this 
is a dup.

Comment 6

[R.K.Aa.]

I don't have the debugging symbols in the build, my backtrace looked like
yours. I get the same trace at another crash-site: http://www.winfiles.com.
(which has been dup'ed a couple of times in 36558 already)

The crash both places occur while URL is loading.
Tested in build 2000-050609

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The last time I took stack traces on opt builds (it might not have been since
last summer), I got correct symbols out of it.  I guess stripping the libraries
is new...  Oh well.