Closed Bug 112746 Opened 24 years ago Closed 24 years ago

crash opening mailbox

Categories

(Core :: XPCOM, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: blizzard, Assigned: scc)

Details

Build is from midday on Nov 29, 2001. Got this crash, might be strings: (gdb) where #0 0x40567d51 in __libc_nanosleep () from /lib/i686/libc.so.6 #1 0x40567bd1 in __sleep (seconds=300) at ../sysdeps/unix/sysv/linux/sleep.c:85 #2 0x0805254f in ah_crap_handler (signum=11) at nsSigHandlers.cpp:143 #3 0x401f9a85 in pthread_sighandler (signo=11, ctx= {gs = 7, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 892651409, esi = 1079908880, ebp = 3221220996, esp = 3221220972, ebx = 1075857368, edx = 1075805360, ecx = 134578384, eax = 892651409, trapno = 14, err = 4, eip = 1075805383, cs = 35, __csh = 0, eflags = 66070, esp_at_signal = 3221220972, ss = 43, __ssh = 0, fpstate = 0xbfffebf0, oldmask = 2147483648, cr2 = 892651421}) at signals.c:97 #4 <signal handler called> #5 __pthread_mutex_lock (mutex=0x3534c791) at mutex.c:99 #6 0x4052dcc8 in __libc_free (mem=0x405e1a18) at malloc.c:3152 #7 0x401c9b58 in PR_Free (ptr=0x405e1a18) at prmem.c:82 #8 0x4014dbda in nsMemoryImpl::Free (this=0x8057ac8, ptr=0x405e1a18) at nsMemoryImpl.cpp:342 #9 0x4014e1bb in nsMemory::Free (ptr=0x405e1a18) at nsMemoryImpl.cpp:574 #10 0x40183cbe in XPCOM_StringAllocator<char>::Deallocate (this=0x401950c4, aBuffer=0x405e1a18 "h]\220\bИK╦\b\030\032^@\030\032^@ез\224\b \207:\bл") at nsReadableUtils.cpp:50 #11 0x08052a33 in nsSharedBufferHandle<char>::~nsSharedBufferHandle ( this=0x80580d0, __in_chrg=3) at ../../dist/include/string/nsBufferHandle.h:336 #12 0x40173efb in nsXPIDLCString::PrepareForUseAsOutParam (this=0xbffff05c) at ../../dist/include/string/nsBufferHandle.h:228 #13 0x40805155 in nsStringBundleService::FormatWithBundle (this=0x80eea48, bundle=0x833c7a8, aStatus=2152398854, argCount=1, argArray=0xbffff16c, result=0x41ba76b0) at ../../../dist/include/string/nsXPIDLString.h:356 #14 0x408056ec in nsStringBundleService::FormatStatusMessage (this=0x80eea48, aStatus=2152398854, aStatusArg=0x842d5b8, result=0x41ba76b0) at ../../../dist/include/xpcom/nsCOMPtr.h:643 #15 0x40e24e6e in nsDocLoaderImpl::OnStatus (this=0x865e3d8, aRequest=0x8c92b18, ctxt=0x0, aStatus=2152398854, aStatusArg=0x842d5b8) at ../../dist/include/xpcom/nsCOMPtr.h:650 #16 0x4015c9f6 in XPTC_InvokeByIndex (that=0x865e3e8, methodIndex=4, paramCount=4, params=0x8d06918) at xptcinvoke_unixish_x86.cpp:153 #17 0x4014b293 in EventHandler (self=0x8c50f08) at ../../../dist/include/xpcom/nsProxyEvent.h:147 #18 0x401464ab in PL_HandleEvent (self=0x8c50f08) at plevent.c:590 #19 0x401463b9 in PL_ProcessPendingEvents (self=0x8082540) at plevent.c:520 #20 0x4014747b in nsEventQueueImpl::ProcessPendingEvents (this=0x8082518) at nsEventQueue.cpp:388 #21 0x40797176 in event_processor_callback (data=0x8082518, source=4, condition=GDK_INPUT_READ) at nsAppShell.cpp:184 #22 0x40796ec5 in our_gdk_io_invoke (source=0x82ca0d8, condition=G_IO_IN, data=0x80e7400) at nsAppShell.cpp:77 #23 0x40380f9e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0 #24 0x40382773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #25 0x40382d39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #26 0x40382eec in g_main_run () from /usr/lib/libglib-1.2.so.0 #27 0x4029d333 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #28 0x40797666 in nsAppShell::Run (this=0x80642d8) at nsAppShell.cpp:349 #29 0x4076fbf6 in nsAppShellService::Run (this=0x80884c0) at ../../../dist/include/xpcom/nsCOMPtr.h:650 #30 0x080516c8 in main1 (argc=1, argv=0xbffff7a4, nativeApp=0x0) at ../../dist/include/xpcom/nsCOMPtr.h:650 #31 0x08052043 in main (argc=1, argv=0xbffff7a4) at nsAppRunner.cpp:1632 #32 0x404c9627 in __libc_start_main (main=0x8051ef8 <main>, argc=1, ubp_av=0xbffff7a4, init=0x804c11c <_init>, fini=0x8052ff0 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff79c) at ../sysdeps/generic/libc-start.c:129
I think if this were strings we'd be crashing all over the place. I could be wrong, though. My guess is that there's some corruption of the heap or stack going on.
Well, I haven't seen it since. This isn't easily reproducable. Should we put some of the stack in the summary? If so, what bit?
I just got another very similar crash when deleting a mail message: #6 0x4052dcc8 in __libc_free (mem=0x405e1a18) at malloc.c:3152 #7 0x401c9b58 in PR_Free (ptr=0x405e1a18) at prmem.c:82 #8 0x4014dc5e in nsMemoryImpl::Free (this=0x8057748, ptr=0x405e1a18) at nsMemoryImpl.cpp:342 #9 0x4014e23f in nsMemory::Free (ptr=0x405e1a18) at nsMemoryImpl.cpp:574 #10 0x40183d4e in XPCOM_StringAllocator<char>::Deallocate (this=0x40195164, aBuffer=0x405e1a18 "\020\032^@\020\032^@H}\005\bH}\005\bÀ1[\bøÜO\b@¨T\b0") at nsReadableUtils.cpp:50 #11 0x08052803 in nsSharedBufferHandle<char>::~nsSharedBufferHandle ( this=0x8057d50, __in_chrg=3) at ../../dist/include/string/nsBufferHandle.h:336 #12 0x40173f7f in nsXPIDLCString::PrepareForUseAsOutParam (this=0xbfffee90) at ../../dist/include/string/nsBufferHandle.h:228 #13 0x40e95498 in nsDSURIContentListener::CanHandleContent (this=0x41d146f8, aContentType=0x80f65c0 "text/html", aIsContentPreferred=0, aDesiredContentType=0x8057d50, aCanHandleContent=0xbfffeeec) at ../../dist/include/string/nsXPIDLString.h:356 #14 0x40e226dd in nsURILoader::ShouldHandleContent (this=0x8130400, aCntListener=0x41d146f8, aContentType=0x80f65c0 "text/html", aIsContentPreferred=0, aContentTypeToUse=0x8057d50) at nsURILoader.cpp:676 #15 0x40e22763 in nsURILoader::DispatchContent (this=0x8130400, aContentType=0x80f65c0 "text/html", aIsContentPreferred=0, request=0x867e738, aCtxt=0x0, aContentListener=0x41d146f8, aSrcWindowContext=0x41d14570, aContentTypeToUse=0x8057d50, aContentListenerToUse=0xbffff150, aAbortProcess=0xbffff0a8) at ../../dist/include/xpcom/nsCOMPtr.h:643 #16 0x40e211e6 in nsDocumentOpenInfo::DispatchContent (this=0x835cd90, request=0x867e738, aCtxt=0x0) at ../../dist/include/xpcom/nsCOMPtr.h:650 #17 0x40e20cff in nsDocumentOpenInfo::OnStartRequest (this=0x835cd90, request=0x867e738, aCtxt=0x0) at nsURILoader.cpp:226 #18 0x4202e7cf in nsStreamConverter::OnStartRequest (this=0x85b29a8, request=0x867e738, ctxt=0x0) at ../../../dist/include/xpcom/nsCOMPtr.h:649 #19 0x40e20d1c in nsDocumentOpenInfo::OnStartRequest (this=0x864b380, request=0x867e738, aCtxt=0x0) at nsURILoader.cpp:228 #20 0x4097b58a in nsStreamListenerTee::OnStartRequest (this=0x8778bf0, request=0x867e738, context=0x0) at ../../../dist/include/xpcom/nsCOMPtr.h:650 #21 0x4095e5d2 in nsOnStartRequestEvent0::HandleEvent (this=0x44fc7fe0) at nsAsyncStreamListener.cpp:225 #22 0x4095e194 in nsStreamListenerEvent0::HandlePLEvent (aEvent=0x44fc7fec) at nsAsyncStreamListener.cpp:113 #23 0x401464db in PL_HandleEvent (self=0x44fc7fec) at plevent.c:590 #24 0x401463e9 in PL_ProcessPendingEvents (self=0x80823b0) at plevent.c:520 #25 0x401474ab in nsEventQueueImpl::ProcessPendingEvents (this=0x8082388) at nsEventQueue.cpp:388 #26 0x40797176 in event_processor_callback (data=0x8082388, source=4, condition=GDK_INPUT_READ) at nsAppShell.cpp:184 #27 0x40796ec5 in our_gdk_io_invoke (source=0x8115218, condition=G_IO_IN, data=0x80e66b8) at nsAppShell.cpp:77 #28 0x40380f9e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0 #29 0x40382773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #30 0x40382d39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #31 0x40382eec in g_main_run () from /usr/lib/libglib-1.2.so.0 #32 0x4029d333 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #33 0x40797666 in nsAppShell::Run (this=0x8063de8) at nsAppShell.cpp:349 #34 0x4076fbf6 in nsAppShellService::Run (this=0x8089020) at ../../../dist/include/xpcom/nsCOMPtr.h:650 #35 0x08051490 in main1 (argc=1, argv=0xbffff7a4, nativeApp=0x0) at ../../dist/include/xpcom/nsCOMPtr.h:650 #36 0x08051e0b in main (argc=1, argv=0xbffff7a4) at nsAppRunner.cpp:1599 #37 0x404c9627 in __libc_start_main (main=0x8051cc0 <main>, argc=1, ubp_av=0xbffff7a4, init=0x804c088 <_init>, fini=0x8052da4 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff79c) at ../sysdeps/generic/libc-start.c:129
I seem to be getting these all the time in mail - probably a mail bug of some kind.
It might be useful if you could debug what the relevant nsXPIDLString object (and perhaps its buffer handle as well) looks like when this happens.
I haven't seen this crash in a long time and it used to happen frequently. Marking worksforme.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.