Closed Bug 976449 Opened 12 years ago Closed 11 years ago

Seamonkey crashes immediately if there is no mail window open, and you click on a 'New Mail' alert pop-up

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Version:
SeaMonkey 2.27 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 986548

People

(Reporter: se014a0001, Unassigned)

References

Details

(Keywords: crash)

Crash Data

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 SeaMonkey/2.27a1 (Beta/Release) Build ID: 20140214003001 Steps to reproduce: 1. Launch Seamonkey 2. An alert pops up at the bottom on the right displaying newly arrived mail details 3. I click on one of the messages in the alert. Actual results: Seamonky crashed, and I fill out the Crash Report Expected results: Some e-Mail window should have opened
Crash report number (URL, from about:crashes) ?
Thinking it will be a DUP of: Bug 964182 - After landing of Bug 920725 fix SM, Thunderbird and Firefox still crashing with same signature
(In reply to therube from comment #3) > Thinking it will be a DUP of: > > Bug 964182 - After landing of Bug 920725 fix SM, Thunderbird and Firefox > still crashing with same signature I'll set the DUP. We can always unDUP later if we find this still crashing.
Status: UNCONFIRMED → RESOLVED
Crash Signature: [@ nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*) ]
Closed: 12 years ago
Keywords: crash
Resolution: --- → DUPLICATE
Not sure if this is the same... as I never say my issue in 2.24. It only started in 2.25 (just released).
Reopening per bug 964182 comment 17.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Sometimes, when this crash happens, a blank window has appeared for a moment before the crash reporter asks me what I thought I was doing. Since the crash doesn't happen if a mail window is already open, I thought I would be looking for a race condition, but I confess bafflement at what happened when I fired up my debug build under gdb, and initiated the crash. info threads shows me all threads are in pthread_cond_wait or pthread_timedwait, except the Socket thread in poll(), the Gecko_IOThread in epoll(), and the faulting thread ... * 1 Thread 0x7ffff7fc4740 (LWP 511) "seamonkey" 0x00007fffc6223008 in ?? () Its stack trace is #0 0x00007fffc6223008 in ?? () #1 0x00007fffdf9408bc in ?? () #2 0x0000000000000182 in ?? () #3 0x00007fffdbdcdb80 in ?? () #4 0x0000000000000000 in ?? () Looking at /proc/511/maps, I see #0 0x00007fffc6223008 in ?? () falls in 7fffc6213000-7fffc6223000 rwxp 00000000 00:00 0 #1 0x00007fffdf9408bc in ?? () falls in 7fffdf92d000-7fffdf94d000 rwxp 00000000 00:00 0 So these are memory regions used for compiled Javascript? info registers gives me rax 0x7fffc6223008 140736517517320 rbx 0xfffc7fffdbdcdb80 -985163024770176 rcx 0x7fffffff35a0 140737488303520 rdx 0x182 386 rsi 0x7fffffff3520 140737488303392 rdi 0x7fffc3f72c50 140736481143888 rbp 0x7fffffff34f0 0x7fffffff34f0 rsp 0x7fffffff34c8 0x7fffffff34c8 r8 0xfffc7fffc16f4340 -985163468160192 r9 0x0 0 r10 0x0 0 r11 0x981 2433 r12 0x0 0 r13 0x7fffc26b0de0 140736455183840 r14 0x0 0 r15 0x7fffdec00490 140736930514064 rip 0x7fffc6223008 0x7fffc6223008 eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 Looking at the second from top frame, I see: Dump of assembler code from 0x7fffdf9408b0 to 0x7fffdf9408c0: 0x00007fffdf9408b0: 03 0c 24 add (%rsp),%ecx 0x00007fffdf9408b3: 48 83 c4 08 add $0x8,%rsp 0x00007fffdf9408b7: 89 51 10 mov %edx,0x10(%rcx) 0x00007fffdf9408ba: ff d0 callq *%rax 0x00007fffdf9408bc: 41 5b pop %r11 0x00007fffdf9408be: 49 c1 eb 04 shr $0x4,%r11 End of assembler dump. A call to *%rax, which holds the faulting address. Looks valid to me. Then, the actual faulting code. Dump of assembler code from 0x7fffc6223008 to 0x7fffc6223048: => 0x00007fffc6223008: 48 83 ec 68 sub $0x68,%rsp 0x00007fffc622300c: 48 8b 84 24 88 00 00 00 mov 0x88(%rsp),%rax 0x00007fffc6223014: 48 c1 e8 2f shr $0x2f,%rax 0x00007fffc6223018: 81 f8 f8 ff 01 00 cmp $0x1fff8,%eax 0x00007fffc622301e: 0f 85 14 59 00 00 jne 0x7fffc6228938 0x00007fffc6223024: 4c 8b 9c 24 88 00 00 00 mov 0x88(%rsp),%r11 0x00007fffc622302c: 48 b8 ff ff ff ff ff 7f 00 00 movabs $0x7fffffffffff,%rax 0x00007fffc6223036: 4c 21 d8 and %r11,%rax 0x00007fffc6223039: 48 8b 40 08 mov 0x8(%rax),%rax 0x00007fffc622303d: 49 bb 38 69 dd db ff 7f 00 00 movabs $0x7fffdbdd6938,%r11 0x00007fffc6223047: 4c 39 d8 cmp %r11,%rax End of assembler dump. Subtracting 0x68 from the Stack pointer. Seems a reasonable thing to do on entry to a sub-routine. How does this cause a Segmentation Fault? All suggestions gratefully received ...
The JavaScript engine deliberately crashes the process to perform slow script detection. On the Mac this isn't a problem because of something to do with Mach exceptions not being the same as Unix signals. On Windows this isn't a problem because you can tell the debugger to ignore first-chance exceptions. But on Linux it makes debugging a headache, so they added a way to turn it off: you need to set JS_DEBUG_SLOW_SCRIPT_SIGNALS=1 in the environment. You can do this in gdb with the set environment command or you can use the env utility to run gdb with it set or you can set it in the shell. Examples: gdb> set env JS_DEBUG_SLOW_SCRIPT_SIGNALS=1 [~] % setenv JS_DEBUG_SLOW_SCRIPT_SIGNALS=1 [~] $ export JS_DEBUG_SLOW_SCRIPT_SIGNALS=1
Thanks for that. For the benefit of anyone reading this as ignorant as myself, there is a typo in comment 8; the environment variable is actually JS_DISABLE_SLOW_SCRIPT_SIGNALS. I am now able to crash my debug Seamonkey at will. To begin with, the crashes occurred when executing the Javascript function ltnOnLoad. The stack traces aren't always the same, but the faults are similar (tracing object types don't match, zero pointer not referencing an object, etc. etc.). So I disabled Lightning. Seamonkey still crashed, but now I got to see the base mail window before it did so. The crash this time was ____________________________________ 0x00007fffef5571c5 in mozilla::dom::EncodingUtils::DecoderForEncoding ( aEncoding=...) at /home/dme/comm-central/mozilla/dom/encoding/EncodingUtils.cpp:75 75 MOZ_ASSERT(decoder, "Tried to create decoder for unknown encoding."); #0 0x00007fffef5571c5 in mozilla::dom::EncodingUtils::DecoderForEncoding ( aEncoding=...) at /home/dme/comm-central/mozilla/dom/encoding/EncodingUtils.cpp:75 #1 0x00007fffef3cc270 in nsHtml5StreamParser::SetupDecodingAndWriteSniffingBufferAndCurrentSegment (this=0x7fffb8c23880, aFromSegment= 0x7fffc4940800 "<html>\r\n<head>\r\n<title>Re: Test</title>\r\n<link rel=\"important stylesheet\" href=\"chrome://messagebody/skin/messageBody.css\">\r\n</head>\r\n<body>\r\n<div class=\"moz-text-plain\" wrap=true graphical-quote=true"..., aCount=1944, aWriteCount=0x7fffc48feb74) at /home/dme/comm-central/mozilla/parser/html/nsHtml5StreamParser.cpp:299 ___________________________________ The mCharset for this instance of nsHtml5StreamParser was a zero length string rather than UTF-8, or something else sensible. ___________________________________ This is not the case if I launch Seamonkey with --mail, so that the Mail window is already open before I click on the notification.
It would appear that there are two separate problems. When Lightning is disabled, the crash is associated with displaying the message in the Message Pane after the main Mail Window has been launched, and the folders on the left and the list of messages to the upper right have been successfully drawn. When the mail window is launched from the mail button on the status bar, when this is first drawn it has some flannel in it, that gets over-written by message text, but when the window is launched from the alert list, this panel is blank until the 'mCharset is a zero length string' crash occurs. It I decline to display the Message Panel, Seamonkey doesn't crash. This is true for both a debug and a non-debug Seamonkey build. If I enable Lightning, and click on the mail alert without a mail window open, the debug build crashes, executing ltnOnLoad. The non-debug build does not crash. This doesn't necessarily mean there is no problem, though; the crash occurs in the trace code that would be activated in the non-debug build.
... would not be activated ...!
Probably my final word on this for a bit, since I have found a workaround. Seamonkey DOES NOT CRASH if there is no mail window open, and I have the message pane enabled, and I click on an e-Mail alert: IFF the preference mailnews.start_page.enabled = false Since I don't care about the start_page (described above as 'flannel') I don't consider this to be an inconvenience. I deduce that the alert-handling code knows about a problem displaying to a pane for the first time, but incorrectly assumes that the pane has been used already if mailnews.start_page.enabled = true, when the mail window hasn't been opened before the alert is clicked. If no one responds, I will eventually investigate this hypothesis myself.
See Also: → 986548
(In reply to David Edwards from comment #9) > The mCharset for this instance of nsHtml5StreamParser was a zero length > string rather than UTF-8, or something else sensible. How does this parser get instantiated? What value does mCharsetSource have in this case?
If you don't mind, I will leave the provision of a helpful answer to someone better qualified than me. If you follow Philip Chee's 'see also' link above, you will see what looks to me to be an answer to your question, in a comment from neil@parkwaycc.co.uk. If you need more detail, e.g. the stack trace at the point of instantiation, I can give it to you, but not until I go on holiday in August.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.