Closed Bug 59298 Opened 25 years ago Closed 25 years ago

Browser crashed while executing tests.

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Platform:
Sun
Solaris
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: raghu, Assigned: mcafee)

References

(
URL
)

Details

(Keywords: crash, qawanted, Whiteboard: suntrak-n6)

The tests being executed are at: komod.mozilla.org/buster. I was executing the top 100 site list tests. I'm using solaris PR3 solairs pkged version. The pkg info is: PKGINST: SUNWns6 NAME: Netscape 6 for Solaris CATEGORY: application ARCH: sparc VERSION: 1.0,REV=10.2000.10.31 BASEDIR: /opt VENDOR: Sun Microsystems, Inc. DESC: Netscape 6 for Solaris PSTAMP: grunt20001031105247 INSTDATE: Oct 31 2000 13:17 HOTLINE: Please contact your local service provider STATUS: completely installed FILES: 504 installed pathnames 4 shared pathnames 63 directories 440 executables 109030 blocks used (approx) This is a random bug that cannot be reproduced by going back to the same set of sites that were visited the last time around. The test had been running for close to 10 minutes.. I have a stack trace below: t@1 (l@1) terminated by signal SEGV (no mapping at the fault address) (dbx) where current thread: t@1 =>[1] nsConvertCharCodeToUnicode__FP12_GdkEventKey(0x138d30, 0xfdbb7dd4, 0x0, 0xa5, 0x8f37c, 0x8f304), a t 0xfdbadea4 [2] InitKeyPressEvent__FP12_GdkEventKeyPvR10nsKeyEvent(0x138d30, 0x3b981a8, 0xffbee230, 0x85, 0x0, 0x0 ), at 0xfdbae0c4 [3] handle_key_press_event__FP10_GtkObjectP12_GdkEventKeyPv(0x3b5e908, 0x138d30, 0x3b981a8, 0xfdbae8f4 , 0x0, 0x0), at 0xfdbae730 [4] gtk_marshal_BOOL__POINTER(0x3b5e908, 0xfdbae5ec, 0x3de9418, 0xffbee480, 0xfda4d1c0, 0xfdbae5ec), a t 0xfda4d1d0 [5] 0xfda92bd0(0x36d35a8, 0xffbee3e0, 0x3b5e908, 0xffbee480, 0xfdb03d90, 0xfdb03e88), at 0xfda92bcf [6] 0xfda91c78(0x3b5e908, 0x1a, 0xffbee480, 0x4, 0xffbee7e0, 0x8f304), at 0xfda91c77 [7] gtk_signal_emit(0x3b5e908, 0x1a, 0x8a5c8, 0xffbee480, 0x3b5e908, 0x8f304), at 0xfda8f1ac [8] gtk_widget_event(0x3b5e908, 0x138d30, 0x0, 0x2c00, 0x81010100, 0xff0000), at 0xfdae0328 [9] gtk_propagate_event(0x3b5e908, 0x138d30, 0x0, 0xa5, 0x8f37c, 0x8f304), at 0xfda4c514 [10] gtk_main_do_event(0x138d30, 0xa615, 0x5f2e0, 0xfd91c598, 0x0, 0x0), at 0xfda4bbf0 [11] handle_gdk_event__FP9_GdkEventPv(0x138d30, 0x0, 0xfd97a780, 0xfdbae8f4, 0x0, 0x0), at 0xfdbaebbc [12] 0xfd94aa9c(0x138d30, 0xffbeeaf0, 0x0, 0xfeaeb254, 0x61f44, 0x0), at 0xfd94aa9b [13] 0xfd8f5d08(0x46c, 0x46c, 0x4d0, 0xa7c, 0x4d0, 0xa7c), at 0xfd8f5d07 [14] 0xfd8f65a8(0xfd91c594, 0xfd91c500, 0x4d0, 0xa7c, 0x4d0, 0xa7c), at 0xfd8f65a7 [15] g_main_run(0x149f38, 0xfd97a894, 0x8bbb8, 0x0, 0x0, 0x0), at 0xfd8f6ed0 [16] gtk_main(0x2c00, 0xfdba5d20, 0x5f620, 0xfdb5c360, 0x0, 0x0), at 0xfda4b444 [17] Run__10nsAppShell(0x5a1d0, 0xfdba5f18, 0x5a1d0, 0x1b0480, 0x0, 0xffe), at 0xfdba5f50 [18] Run__17nsAppShellService(0xe3950, 0xfe87ded8, 0xe3950, 0xfe87d234, 0x3f8, 0x1), at 0xfe87deec [19] 0x16e24(0x0, 0xff0cf170, 0x0, 0x5, 0x100d4, 0x0), at 0x16e23 [20] main(0x1, 0xffbeeefc, 0xffbeef04, 0x36c90, 0x0, 0x0), at 0x17310 (dbx)
Whiteboard: suntral-n6-highp
including the tracking string for sun bug..
Whiteboard: suntral-n6-highp → suntrak-n6-highp
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
it looks like you pressed a key :-(
Chris, can you take a look at this ...
Assignee: don → mcafee
To recreate the bug please go to: http://komodo.mozilla.org/buster/test_url_25.html The crash occurs in 1-3 minutes.
raghu: I notice that the stack trace indicates the bug crash is in GDK key press event handling code. Can you say more about how the test is being run? Is the browser automatically re-directing itself from site to site, or is a person sitting there pressing keys to go from one site to another? I ask because we've seen problems with browser crashes when pressing certain key combinations on Unix, due to GTK/GDK code. Please elaborate.
George: The test suite is an automatic one. Once you get here: http://komodo.mozilla.org/buster/test_url_25.html it will run automatically.
This test appears to just go to a list of sites, and tries to display them. I ran this test twice and the browser crashed twice. The first one gave the following stack trace: #0 0xff1e0b84 in ?? () at ../../../../../../dist/include/xptcstubsdef.inc:142 from /spare/ws/mozilla/mozilla-sparc-nightly/mozilla/dist/bin/./libxpcom.so 142 SENTINEL_ENTRY(9) (gdb) where #0 0xff1e0b84 in ?? () at ../../../../../../dist/include/xptcstubsdef.inc:142 from /spare/ws/mozilla/mozilla-sparc-nightly/mozilla/dist/bin/./libxpcom.so #1 0xfcd27790 in nsHTTPPipelinedRequest::GetCurrentRequest (this=0x0, o_Req=0xffbeecc4) at nsHTTPRequest.cpp:1118 #2 0xfcd2aa24 in nsHTTPServerListener::OnStartRequest (this=0xe904f8, channel=0xbd2eb4, i_pContext=0xd439f8) at nsHTTPResponseListener.cpp:651 #3 0xfcc92a90 in nsOnStartRequestEvent::HandleEvent (this=0x6924c8) at nsAsyncStreamListener.cpp:210 #4 0xfcc91fcc in nsStreamListenerEvent::HandlePLEvent (aEvent=0x8edca0) at nsAsyncStreamListener.cpp:97 #5 0xff0f83c4 in PL_HandleEvent (self=0x8edca0) at plevent.c:580 #6 0xff0f80f0 in PL_ProcessPendingEvents (self=0x697c20) at plevent.c:513 #7 0xff0fab9c in nsEventQueueImpl::ProcessPendingEvents (this=0x697a88) at nsEventQueue.cpp:356 #8 0xfd943284 in event_processor_callback (data=0x697a88, source=30, condition=GDK_INPUT_READ) at nsAppShell.cpp:158 #9 0xfd942cd4 in our_gdk_io_invoke (source=0x61a838, condition=G_IO_IN, data=0x873888) at nsAppShell.cpp:58 #10 0xfd6742a4 in g_io_unix_dispatch () from /spare/ws/mozilla/mozilla-sparc-nightly/dist/lib/libglib-1.2.so.0 #11 0xfd675d10 in g_main_dispatch () from /spare/ws/mozilla/mozilla-sparc-nightly/dist/lib/libglib-1.2.so.0 #12 0xfd6765b0 in g_main_iterate () from /spare/ws/mozilla/mozilla-sparc-nightly/dist/lib/libglib-1.2.so.0 #13 0xfd676ed8 in g_main_run () from /spare/ws/mozilla/mozilla-sparc-nightly/dist/lib/libglib-1.2.so.0 #14 0xfd7cb44c in gtk_main () from /spare/ws/mozilla/mozilla-sparc-nightly/dist/lib/libgtk-1.2.so.0 #15 0xfd943c14 in nsAppShell::Run (this=0x9b040) at nsAppShell.cpp:335 #16 0xfdb4740c in nsAppShellService::Run (this=0x9abd8) at nsAppShellService.cpp:407 #17 0x233d0 in main1 (argc=1, argv=0xffbef63c, nativeApp=0x0) at nsAppRunner.cpp:990 #18 0x23dcc in main (argc=1, argv=0xffbef63c) at nsAppRunner.cpp:1171 (gdb) Console messages just before the crash occured were: ... WEBSHELL+ = 8 WEBSHELL+ = 9 Setting Preference Style Rules: CreatePrefStyleSheet completed: error=0 - Creating rules for link and visited colors - Creating rules for enabling link underlines Preference Style Rules set: error=0 Enabling Quirk StyleSheet Error loading URL http://komodo.mozilla.org/buster/test_url_25.html: 804b0002 Setting content window *** Pulling out the charset JavaScript strict warning: chrome://navigator/content/navigator.js line 451: reference to undefined property window.arguments JavaScript strict warning: chrome://navigator/content/navigator.js line 474: reference to undefined property window.arguments in SetSecurityButton WARNING: not calling OnDataAvailable, file nsAsyncStreamListener.cpp, line 403 Segmentation Fault - core dumped The test at this point appeared to be in the process of starting up a new small window, and it appeared on the screen such that the window I was typing into was obscured, and this new window received my keystokes. The second termination did not produce a core dump. The web page in question has a Java applet on it. Here are the last few console messages: ... JavaScript strict warning: http://www.attitude.com/ line 54: assignment to undeclared variable emailOff Setting Preference Style Rules: CreatePrefStyleSheet completed: error=0 - Creating rules for link and visited colors - Creating rules for enabling link underlines Preference Style Rules set: error=0 Enabling Quirk StyleSheet InstantiateEmbededPlugin for application/x-java-vm Inside nsPluginHostImpl::FindStoppedPluginForURL... InstantiateEmbededPlugin.. returning InstantiateEmbededPlugin for application/x-java-vm Inside nsPluginHostImpl::FindStoppedPluginForURL... InstantiateEmbededPlugin.. returning INTERNAL ERROR on Browser End: Pipe closed during read? State may be corrupt System error?:: Error 0
Note that just going to www.attitude.com crashes the browser (at least for me on Solaris SPARC platform. Tested on our PR3 candidate and with a version of Mozilla that was tip-of-the-RTM branch about three days ago. Adding Stanley and Jim to the cc:
A blanket browser buster bug isn't very useful without knowing what URL is crashing the app. We need to decide what this bug is about, and focus on that. If it's the attitude.com crash, Ok. Other crashes should become new bugs.
I agree with mcafee@netscape.com. We need to identify which test within the testsuite is causing crashes. We may deduce tons of bugs from running the testsuite simply by adding keystroke to it or interrupting the loading of certain page or some yet unknown actions from the tester, but it will not help until we find out the exact combination. I ran the test yesterday, leave it running for quite some time, I do not see any crashes. Can someone tell me what sites this particular test suites are covering/accessing? I am leaning toward to manually run them one by one, and see what will happen. Is it simply accessing the top 100 sites? If I can identify the crash by simply accessing them, then we can have better reproducible cases. If I cannot, then I don't think this is a valid bug by simply saying that "Browser crashed while executing tests". At least I can verify that browser crashes or not by simply executing tests manually. raghu@eng.sun.com: Can you tell me how exactly you run the tests? Do you leave it running on a test machine or are you running it and doing work at the same time on the same machine? I am just trying to understand if it is an accessing crash or human interruption crashes always (Other than the access to attitude.com from Rich, it appears that the other cases always involve human interruption). Just trying to narrow it down.
Hi, I believe we should open different bugs for different stack traces. I simply go to the URL http://komodo.mozilla.org/buster/test_url_25.html and let the tests run.I do not do anything else.. If you go to komodo.mozilla.org/buster/ you will see the Current list of pages link there.. I beleive it is at: http://komodo.mozilla.org/buster/pagelist.html -raghu .
I think that's the right thing to do: > open different bugs for different stack traces I am aware of this page: http://komodo.mozilla.org/buster/pagelist.html I am more interested in knowing what http://komodo.mozilla.org/buster/test_url_25.html does exactly. Is it accessing top 100 sites of the list or all sites on the list or something more? sairuh@netscape.com: Can you give me an idea?
Docs for the buster page are one level up: http://komodo.mozilla.org/buster/
A very useful mod to this automatic test, would be for it to print out the URL of the site that it's about to visit. If we get a crash, we can then attempt to just visit that site. If we still get the crash, then we should file a separate bug. Repeat until all sites visited.
Margaret, The top 100 list url chooses one of the url at random from the top 100 list and visits them.. -raghu
Thanks. I am going to access the top 100 sites in sequence manually and see how it goes.
One of the sites this test executes is www.attitude.com (as Rich pointed out). It has a Java Applet which invokes System.exit(0); Please enure that you do not have .java.policy file set up (in your home dir). granting AllPermissions. If u have , then browser will exit (will seem like a crash) on loading this page.
Thank Raju. I think you are correct. www.attitude.com did not crash on me but it crashes for Rich and George. After I saw your comment, I added the file and it just exited as you have said. The console message is displaying exactly what Rich is seeing:
I have run thru all the test pages, altogether 244 on the test page list. For curiosity, I have also run thru the tests under the heading "More Browser Buster Test Pages". I have run them manually in the order they are listed. None of them crashes on me. This is from our Solaris PR3 build, package info as follows: PKGINST: SUNWns6 NAME: Netscape 6 for Solaris CATEGORY: application ARCH: sparc VERSION: 1.0,REV=10.2000.11.07 BASEDIR: /opt VENDOR: Sun Microsystems, Inc. DESC: Netscape 6 for Solaris PSTAMP: grunt20001107162916 INSTDATE: Nov 08 2000 10:13 HOTLINE: Please contact your local service provider STATUS: completely installed FILES: 508 installed pathnames 4 shared pathnames 63 directories 440 executables 111658 blocks used (approx)
Just checked the recent talkback reports, I see a similar stack trace as what Rich has got. The report is filed against an old build (PR2 very likely).
apologies for the delay in my response... i was wondering, has anyone been able to test with a more recent N6 branch of the solaris bits? [rather than using PR3] lisa, i'm not sure which build date the sun folks should use for narrowing this down? i didn't see a solaris build in the 2000.11.08.08-n6 directory, although i did see ones in 2000.11.08-09-n6 and a couple other later build dirs.
I have not run the tests with the latest n6 build. However, since I cannot reproduce it by running the tests manually, I am suspecting that human interruption to the tests may be the trigger of both cases. raghu@eng.sun.com: I am expecting that you will file 2 different bugs for the 2 stack traces here. Wouldn't you? If so, please posts out the new bug numbers; otherwise, I will put my comments here. I am checking on the second stack trace, which Rich has posted here. Looking at the code, it segs fault at the following line: mRequests->Count(&count); I wonder if mRequests would be null at the time it is accessed, and hence causes the seg fault. Also, it is interesting to see that the stack trace has the "this" pointer equals to null, | v #1 0xfcd27790 in nsHTTPPipelinedRequest::GetCurrentRequest (this=0x0, o_Req=0xffbeecc4) at nsHTTPRequest.cpp:1118
This crash does not occur any more. I removed the high priority tag for this bug.
Whiteboard: suntrak-n6-highp → suntrak-n6
Keywords: crash
nav triage team: If test no longer crashes, not fixing for nsbeta1, marking nsbeta1-
Keywords: nsbeta1-
Without getting a specific test case here, the next thing to try might be running in the debugger and posting a stack trace here. I'm tempted to mark this won't fix, this is a big encompassing bug that ? doesn't really help us fix anything. One more chance for this bug... anyone?
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
I reproduce this bug : with 04/06/2001 nightly under WinNT4.0 with 04/08/2001 nightly under RH Linux 6.2 Mozilla crashed after 3-5 minutes.
Should we ask Vladimir to open a different bug for the crashes he is seeing on Win and Linux platforms?
I can't do anything without a specific test case. I've asked a few times in this bug, nothing so far. Marking won't fix. If you have an URL, or a reproduceable way to produce this, then please file a new bug. Maybe you could run the browser buster in the debugger and get a URL/stack trace that way.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
v
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.