Closed
Bug 29339
Opened 26 years ago
Closed 26 years ago
Frequent crashes in mail
Categories
(MailNews Core :: Backend, defect, P3)
Tracking
(Not tracked)
People
(Reporter: akkzilla, Assigned: pnunn)
Details
(Keywords: crash)
I'm seeing frequent crashes in mail, which I think is happening on biff or when
clicking on a new message. Often it happens when I send a message, after the
compose window goes away and the message is sent successfully, but I've also
seen crashes with no compose window involved.
Unfortunately, it happens a lot less often when I run under gdb, so I've only
been able to get one stack trace so far: this one happened when I loaded a
message with an html attachment (the one that HR spammed to everyone regarding a
tax seminar, with all the included images and so forth that one expects from an
HR message), then tried to click on another message to view it (the HR message
may not have been fully loaded, though it had been displaying for 40 seconds or
so by the time I clicked elsewhere).
Here's the stack trace I got:
#0 0x4120b988 in nsFrameImageLoader::DamageRepairFrames (this=0x93538e0,
aDamageRect=0xbffff4d4) at nsFrameImageLoader.cpp:541
#1 0x4120b68a in nsFrameImageLoader::Notify (this=0x93538e0,
aImageRequest=0x88514a0, aImage=0x98399c8,
aNotificationType=nsImageNotification_kPixmapUpdate, aParam1=0, aParam2=0,
aParam3=0xbffff518) at nsFrameImageLoader.cpp:419
#2 0x400303fe in ns_observer_proc (aSource=0x9353a20, aMsg=4,
aMsgData=0xbffff59c, aClosure=0x88514a0) at nsImageRequest.cpp:95
#3 0x40041ade in XP_NotifyObservers (inObserverList=0x9353a10, inMessage=4,
ioData=0xbffff59c) at obs.c:259
#4 0x4003793b in il_pixmap_update_notify (ic=0x9353a48) at if.cpp:307
#5 0x4003fac3 in il_flush_image_data (ic=0x9353a48) at scale.cpp:218
#6 0x40037527 in ImgDCallbk::ImgDCBFlushImage (this=0x9353c50) at if.cpp:162
#7 0x4148c127 in il_gif_write (ic=0x9353a48, buf=0x4148dcd3 "", len=0)
at gif.cpp:1500
#8 0x41489ee0 in process_buffered_gif_input_data (gs=0x9754720) at gif.cpp:669
#9 0x4148a090 in gif_delay_time_callback (closure=0x9353a48) at gif.cpp:725
#10 0x400310bc in timer_callback (aTimer=0x85f8b38, aClosure=0x92898e8)
at nsImageSystemServices.cpp:71
#11 0x4080a665 in nsTimerGtk::FireTimeout (this=0x85f8b38) at nsTimerGtk.cpp:58
#12 0x4080abe6 in nsTimerExpired (aCallData=0x85f8b38) at nsTimerGtk.cpp:175
#13 0x4096d8a4 in g_timeout_dispatch ()
This is a dupe of bug#28341 &/or # 28781.
Current theory is the presContext is leaking
which means the image group free is never triggered
by the freed prescontext.
The imglib shows up in the call stack because an
animation hasn't been unloaded by the image group free.
It tries to keep on going though it doesn't have a
view to live in.
Don't think this is mine, but I'm trying to get more info
on the presContext leak to find who should own it.
-pn
*** This bug has been marked as a duplicate of 23841 ***
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
verified as duplicate. Dup bug is verified fixed already.
Akkana - are you still seeing this type of a problem?
Status: RESOLVED → VERIFIED
| Reporter | ||
Comment 4•26 years ago
|
||
Sorry, I'm not sure; haven't been eating much dogfood lately due to other bugs.
If Pam thinks is a dup of the other bug and that one's already fixed, I'm
willing to believe her.
Updated•21 years ago
|
Product: MailNews → Core
Updated•17 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•