Closed Bug 80355 Opened 23 years ago Closed 23 years ago

Crash after successful send of HTML message

Categories

(MailNews Core :: Composition, defect, P1)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 80203
Milestone:
mozilla0.9.1

People

(Reporter: shochat, Assigned: sspitzer)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [nsbeta1+]) 

I first encountered this in a CVS build with c/o date 10 May 2001 14:10:00 PDT.

I am able to reproduce it by composing a message to myself using HTML
composition. When I click on the Send button, Mozilla crashes. In every case,
the mail has in fact been sent successfully. 

I don't really know what component the bug is in. From a user standpoint, it
has to do with composition.

I did this on a debug build
with the same c/o date, running under gdb. At the point where the crash would
occur, gdb reports a segmentation fault. Here is the stack trace at that point:

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x41d3ef21 in nsCaret::GetViewForRendering (this=0x8b07608,
caretFrame=0x8f2cb3c, coordType=eRenderingViewCoordinates, viewOffset=@0xbffff3f8, 
    outClipRect=@0xbffff3e8, outView=@0xbffff3e4) at nsCaret.cpp:764
#2  0x41d3f561 in nsCaret::DrawCaret (this=0x8b07608) at nsCaret.cpp:904
#3  0x41d40310 in nsCaret::CaretBlinkCallback (aTimer=0x8ff25b8,
aClosure=0x8b07608) at nsCaret.cpp:1068
#4  0x41eb89c0 in nsTimerGtk::FireTimeout (this=0x8ff25b8) at nsTimerGtk.cpp:183
#5  0x41eb8c33 in process_timers (array=0x8375a20) at nsTimerGtk.cpp:256
#6  0x41eb8d0a in TimerCallbackFunc (data=0x0) at nsTimerGtk.cpp:277
#7  0x4097404d in g_timeout_dispatch () from /usr/lib/libglib-1.2.so.0
#8  0x40973186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#9  0x40973751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#10 0x409738f1 in g_main_run () from /usr/lib/libglib-1.2.so.0
#11 0x408988e9 in ?? () from /usr/lib/libgtk-1.2.so.0
#12 0x407961ad in nsAppShell::Run (this=0x811c878) at nsAppShell.cpp:360
#13 0x4072a0c5 in nsAppShellService::Run (this=0x810abf8) at
nsAppShellService.cpp:417
#14 0x08055229 in main1 (argc=1, argv=0xbffff89c, nativeApp=0x0) at
nsAppRunner.cpp:1010
#15 0x080560b1 in main (argc=1, argv=0xbffff89c) at nsAppRunner.cpp:1311
#16 0x4031f9cb in __libc_start_main (main=0x8055e9c <main>, argc=1,
argv=0xbffff89c, init=0x804f904 <_init>, fini=0x8063250 <_fini>, 
    rtld_fini=0x4000aea0 <_dl_fini>, stack_end=0xbffff894) at
../sysdeps/generic/libc-start.c:92
Maybe it is significant that after typing my text into the composition window,
I selected it, increased the font size a couple of steps and changed the color.
I find that I can send an HTML-formatted message without the crash when I
don't do that, i.e. when I leave it with all default formatting.
Severity: normal → critical
Keywords: crash
stack trace indicates we might be leaking a timer (for the caret).  cc sfraser.
I can confirm that this bug is happening (using gcc295 nightlies 2001-05-13-09
and 2001-05-13-09). I don't have a stack trace or something - but I can tell
that I'm not using HTML mail, I turned that off months ago :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ditto for non-HTML mail with normal -sea 2001051408 Linux nightly on RedHat 6.2,
kernel 2.2.19.  Didn't occur in 2001050914.
If you crash when drawing the caret, then you are likely leaking not the timer, 
but nsPresShell (which owns the caret). If you are leaking nsPresShell, it's 
likely you leaking the document, and a slew of other stuff.

i'm getting similar results - seems to crash about 70% of the time. sometimes i
get a segfault, sometimes i get a "trace/breakpoint trap." most of the time
it's a segfault though. i get this on 2001051421 and i think all builds after
builds dated may 8th. (actually i just have loads of crashing probs with builds
after may 8th, this is the first that only crashes with mail..

note that this occurs also when composing in html mode even when it's converted
to plain text for all recipients (don't know if this is relevant)

i don't have a stack trace right now; i'll try to get one later if it proves to
be useful.

redhat 7, kernel 2.4.3.
sorry - i forgot - i also get this on today's build - 2001051508 - i had tried
to post before with last night's build, but the bugzilla-related bug prevented
me from posting with yesterday's build, so i had to update, but i forgot to
change the build # i'd reported...  how annoying ;-)
*** Bug 81030 has been marked as a duplicate of this bug. ***
Don't know about getting a stack trace, but I just posted Talkback ID
TB30526731H that shows this crash.
Here's the stack trace peterj is getting:

nsMenuBarFrame::Init()
GetInsertionPoint()
nsTimerGtk::SetPriority()
process_timers()
TimerCallbackFunc()
libglib-1.2.so.0 + 0x10864 (0x40781864)
libglib-1.2.so.0 + 0xf9f6 (0x407809f6)
libglib-1.2.so.0 + 0xffb1 (0x40780fb1)
libglib-1.2.so.0 + 0x10129 (0x40781129)
libgtk-1.2.so.0 + 0x8d48a (0x4069d48a)
nsAppShell::ListenToEventQueue()
libnsappshell.so + 0xdcea (0x40ef9cea) 


*** Bug 81027 has been marked as a duplicate of this bug. ***
nominating nsbeta1
Status: NEW → ASSIGNED
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.1
Per Seth request, reassign to him.
Assignee: ducarroz → sspitzer
Status: ASSIGNED → NEW
poor ducarroz is the mac mailnews debugging slave, no reason to make him suffer gdb.

I'll take a look.
I know it's not the same stack trace, but could this be related to 81264 which
is a crash in PresShell when sending on Linux?
Priority: -- → P1
Whiteboard: [nsbeta1+]
Hint: to debug this, start by looking for leaking nsPresShells.

thanks smfr.  I'll start there.
I can reproduce this.  my points to smfr's theory about a leaked pres shell.

#0  0x8724870 in ?? ()
#1  0x41629619 in HandlePLEvent (aEvent=0x8af5fa8) at nsPresShell.cpp:5616
#2  0x400e6b02 in PL_HandleEvent (self=0x8af5fa8) at plevent.c:588
#3  0x400e7049 in PL_ProcessEventsBeforeID (aSelf=0x80a5330, aID=12872) at
plevent.c:1254
#4  0x406337cf in processQueue (aElement=0x80a5330, aData=0x3248) at
nsAppShell.cpp:475
#5  0x400b1f0b in nsVoidArray::EnumerateForwards (this=0x8116a38,
aFunc=0x406337b4 <processQueue(void *, void *)>, aData=0x3248) at
nsVoidArray.cpp:313
#6  0x40633809 in nsAppShell::ProcessBeforeID (aID=12872) at nsAppShell.cpp:483
#7  0x4063e832 in handle_gdk_event (event=0x81e2b60, data=0x0) at
nsGtkEventHandler.cpp:987
#8  0x407bd0fb in ?? () from /usr/lib/libgdk-1.2.so.0
#9  0x407eaa86 in g_main_dispatch ()
#10 0x407eb041 in g_main_iterate ()
#11 0x407eb1e1 in g_main_run ()
#12 0x407147a9 in gtk_main ()
#13 0x4063358c in nsAppShell::Run (this=0x8116a88) at nsAppShell.cpp:360
#14 0x405ec325 in nsAppShellService::Run (this=0x80fe1f0) at
nsAppShellService.cpp:417
#15 0x80518cb in main1 (argc=4, argv=0xbffff714, nativeApp=0x0) at
nsAppRunner.cpp:1010
#16 0x80524ed in main (argc=4, argv=0xbffff714) at nsAppRunner.cpp:1308
#17 0x4026fcb3 in ?? () from /lib/libc.so.6
Status: NEW → ASSIGNED
David Baron pointed this out in another bug about a Linux send crash so I'll add
that info here.  http://bugzilla.mozilla.org/show_bug.cgi?id=80203 has a patch
for a pres shell leak that seems to be affecting linux.  I don't know if that
code gets hit here.
dbaron's patch fixes this.

*** This bug has been marked as a duplicate of 80203 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
What a good news and a relief. Thanks Seth for taking care of it.
Was I not wrong?  :)

verified as duplicate
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.