Closed Bug 58728 Opened 24 years ago Closed 24 years ago

N601 Linux #1 crash on' open web location' dialog [@ nsJARChannel::OnStartRequest]

Categories

(SeaMonkey :: UI Design, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.8

People

(Reporter: davidhj, Assigned: gagan)

Details

(Keywords: crash, smoketest, topcrash)

Crash Data

Attachments

(1 file)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-15mdk i686; en-US; m18) Gecko/20001029 BuildID: 2000102906 when trying to open a web location using ctrl+L or the File menu item "open web location", Mozilla crashes when enter is pressed or the "Open" button is pressed. Reproducible: Always Steps to Reproduce: 1. File-->open web location ; or Ctrl+L 2. type or paste in a URL 3. hit enter or click "open" Actual Results: browser crashes Expected Results: open location normally
using a NS6 build from 1031 (1400) on Linux, I can't reproduce this bug.
Doesn't crash on Linux 2000-11-01-06 MTrunk.
Keywords: crash, smoketest
actually, i've seen this --but it's annoying to repro-- it seems that it occurs when i paste from another app [eg, in my case, say, gaim, aim or xchat] into the Open Web Location. David, are you running this with a talkback build? if so, when talkback appears, enter your email address and i'll search for it [the info lands into an internal server] and enter the stack info in this report. let me know if/when you've done this --thanks!
Status: UNCONFIRMED → NEW
Ever confirmed: true
hokay, finally got a talkback report (incident #20199074), caused when i pasted a url that i had typed in an xterm. Trigger Time 2000-11-01 11:45:20 Email Address sairuh@netscape.com User Comments pasting url into Web Loc [from xterm] Build ID 2000103009 Product ID Netscape6.00 Platform ID LinuxIntel Stack Trace nsJARChannel::OnStartRequest() nsOnStartRequestEvent::HandleEvent() nsStreamListenerEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xeaca (0x40665aca) libglib-1.2.so.0 + 0x10186 (0x40667186) libglib-1.2.so.0 + 0x10751 (0x40667751) libglib-1.2.so.0 + 0x108f1 (0x406678f1) libgtk-1.2.so.0 + 0x8c5b9 (0x4058c5b9) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x189cb (0x4025e9cb)
It does seem to happen when I cut and paste an address into the dialog, usually by middle clicking in unix fashion. But I have also reproduced it just by typing an address in and hitting return. Just tried again and it crashed all right. This is with a recent nightly, so NS6 may be OK.
Summary: crash on 'open web location' dialog → crash on' open web location' dialog
i can get this using netscape6 [commercial branch 2000.11.06.09-n6]. again, the annoying aspect is that it doesn't occur every time i paste [middle+click] into the Open Web Location dialog. cc'ing akkana, jag and bill --have either of you seen this, or have ideas as to why it might be occurring?
Summary: crash on' open web location' dialog → crash on' open web location' dialog [nsJARChannel::OnStartRequest()]
Nope, I haven't seen this. From the look of the call stack, it appears to be a Unix event handling kind of thing.
kin/saari/heikki, have any of you encountered this, or might know what would cause this crash?
No idea, but CCing pav and damn since it may be event queue releated.
The stack trace is completely normal data stream processing stuff. I was able to reproduce this crash on the 17th attempt. Same stack trace but for the top two entries: nsHTTPServerListener::OnDataAvailable (nsHTTPResponseListener.cpp#451 rev 1.132) nsOnDataAvailableEvent::HandleEvent in my case, it was crashing because the nsHTTPServerListener object's member variable mResponseDataListener was null (and it was trying to call mResponseDataListener->OnDataAvailable). The rest of the mResponseDataListener object looked reasonable, and its mRefCnt = 1. Sound familiar, networking guys?
Assignee: ben → gagan
I have experienced this bug as well. For me, there's been no relation to cutting and pasting: it happens unpredictably when I use the "Open Web Location" dialog, but I always type into it. It's been present in daily builds for the last few weeks at least. It's a rather annoying bug, since I use Ctl-L a lot to open web pages. It means the damn thing crashes on my quite a bit.
added keyword qawanted.
Keywords: qawanted
looks like this one at the top of the list for low memory crashes on linux. lots of hits on low memory linux boxes. here is data from some recent talkback analysis Crash Analysis from Netscape6 RTM candidate build nsJARChannel::OnStartRequest # recent crashes 0 MB > and <= 32 MB 4 32 MB > and <= 64 MB 44 64 MB > and <= 128 MB 28 128 MB > and <= 256 MB 7 256 MB > and <= 512 MB 1 512 MB > and <= 1024 MB 1 maybe the key to reproducability is to try on low memory systems, or run for a while to soak up some memory.
Keywords: topcrash
Summary: crash on' open web location' dialog [nsJARChannel::OnStartRequest()] → crash on' open web location' dialog @[nsJARChannel::OnStartRequest()]
Keywords: nsbeta1
cc to self; see bug 64769, which may be the same thing. Could somebody point me to a primer on producing a stack trace from my crash? Do I have to configure the build, or run some tool...?
Try running mozilla from GDB, then you can get a backtrace when moz crashes. or... if GDB gives you trouble... Try enabling the ah_crap_handler in mozilla/xpfe/bootstrap/nsSigHandlers.cpp It will SIGSTOP moz on a crash so you can attach GDB and get a backtrace that way. Also, check out http://www.mozilla.org/unix/debugging-faq.html
This is happening cuz occasionally the abort kicks in while there is still a onDataAvail event in the queue. Even though this should not be happening, I have put in a null-check fix to at least avoid the crash. Attaching that...
Attached patch null check crash fix. (deleted) — Splinter Review
r=darin on gagan's patch
.8, get a sr and get this puppy in please!
Target Milestone: --- → mozilla0.8
sr=alecf
checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Summary: crash on' open web location' dialog @[nsJARChannel::OnStartRequest()] → Linux N601 crash #1 crash on' open web location' dialog @[nsJARChannel::OnStartRequest()]
Summary: Linux N601 crash #1 crash on' open web location' dialog @[nsJARChannel::OnStartRequest()] → N601 Linux #1 crash on' open web location' dialog @[nsJARChannel::OnStartRequest()]
sairuh - do you still see this bug? If not sure, we should get jpatel or namachi to do some talkback queries to ensure the bug is no longer showing up in talkback reports on more recent trunk builds. thanks.
jay/shiva, could you do some talkback queries to see how frequently this crash is occurring these days? i haven't encountered this for some time, so am gonna verify this. jay/shiva, pls do reopen if your reports show this is still an issue. thx a lot!
Status: RESOLVED → VERIFIED
This only happens in N601 releases. I don't see them in current Trunk or M08 builds. Shiva
This has been much better in trunk builds, but I have noticed what might be an edge-case that hasn't been fixed: if the very first thing that I do when I start mozilla is ctrl+L to open a location, it will sometimes crash on submitting the dialog. I am not requesting that the bug be reopened, though.
Summary: N601 Linux #1 crash on' open web location' dialog @[nsJARChannel::OnStartRequest()] → N601 Linux #1 crash on' open web location' dialog [@ nsJARChannel::OnStartRequest]
pohl: are you seeing the same stack trace when it crashes?
I never did manage to generate a stace trace. My first attempts were stopped short by the debian gdb hurdle, and I became sidetracked by other things. Maybe things aren't so difficult now. I'll post one if I succeed. http://www.mozilla.org/unix/debugging-faq.html#debian
If it's a different stack trace, then please open a new bug. But, if it's the same stack trace, then please let us know. Thanks!
Keywords: qawanted
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
Crash Signature: [@ nsJARChannel::OnStartRequest]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: