260509 - SIGSEGV when doing a "File -> Compact Folders"

Status: RESOLVED DUPLICATE of bug 257079

(MailNews Core :: Networking: IMAP, defect)

Description

[Felix Schmitt]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.2) Gecko/20040915
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.2)

Starting with 1.7 I had always problems with a crashing Mozilla. Now I belive
I've tracked the problem down to the mailnews. I've set my Mailbox folder policy
to "Mark it as deleted" and do finally delete them with the Menu "File ->
Compact Folders". It looks like mailnews is trying to compact more than only the
Inbox.

Most time after "File -> Compact Folders" I get a SIGSEGV on Solaris. I also use
Mozilla on WinXP and there Mozilla does not crash but is very unresponsive. I
have subscribed to a lot of mailboxes on my mailserver.

The cause of the SIGSEGV in my opinion the use of a pointer which is not checked
for "null" in nsImapMailFolder::UpdateImapMailboxInfo at line 2634. I created a
debug binary and had a few crashes there. And I changed the code at this
location to print a message whenever a null pointer would be used and got a lot
of messages.

Comparing the code of 1.6 with 1.7 the lines at 2634 are new code in 1.7 and I
had these crashes not in 1.6.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.



The crash happens at line 2634 (see below) of nsImapMailFolder.cpp

  2630      SyncFlags(flagState);
  2631      PRInt32 numUnreadFromServer;
  2632      aSpec->GetNumUnseenMessages(&numUnreadFromServer);
  2633      if (mNumUnreadMessages + keysToFetch.GetSize() > numUnreadFromServer)
  2634              mDatabase->SyncCounts();
  2635
  2636      if (keysToFetch.GetSize())
  2637      {
  2638        PrepareToAddHeadersToMailDB(aProtocol, keysToFetch, aSpec);
  2639      }

Comment 1

[Patrick McCormick]

Can you provide a full stacktrace?

in gdb, "thread apply all bt" or something similar would be good.

searching for text from the stack frame in bugzilla's comments may turn up a
related issue.

Comment 2

[Felix Schmitt]

Here you go! It took some time to recompile with -g

Felix Schmitt

(gdb) thread apply all bt

Thread 32 (Thread 32        ):
#0  0xfe5e58f8 in __lwp_park () from /usr/lib/lwp/libthread.so.1
#1  0xfe5e2ba8 in cond_wait_queue () from /usr/lib/lwp/libthread.so.1
#2  0xfe5e3120 in cond_wait_common () from /usr/lib/lwp/libthread.so.1
#3  0xfe5e35b0 in _ti_cond_timedwait () from /usr/lib/lwp/libthread.so.1
#4  0xfe5e35e4 in cond_timedwait () from /usr/lib/lwp/libthread.so.1
#5  0xfe5e3624 in pthread_cond_timedwait () from /usr/lib/lwp/libthread.so.1
#6  0xff233b84 in pt_TimedWait (cv=0x1124548, ml=0x1566e80, timeout=100000) at
ptsynch.c:264
#7  0xff233f7c in PR_WaitCondVar (cvar=0x1124540, timeout=100000) at ptsynch.c:391
#8  0xff23446c in PR_Wait (mon=0x1566e78, timeout=100000) at ptsynch.c:568
#9  0xfaff2d18 in nsAutoMonitor::Wait (this=0xfa8cfde8, interval=100000) at
nsAutoLock.h:285
#10 0xfaf74dac in nsImapProtocol::ImapThreadMainLoop (this=0x13ee8d8) at
nsImapProtocol.cpp:1140
#11 0xfaf73e84 in nsImapProtocol::Run (this=0x13ee8d8) at nsImapProtocol.cpp:927
#12 0xfe366c34 in nsThread::Main (arg=0x109f328) at nsThread.cpp:118
#13 0xff23d750 in _pt_root (arg=0x159a740) at ptthread.c:214
#14 0xfe5e57c0 in _lwp_start () from /usr/lib/lwp/libthread.so.1
#15 0xfe5e57c0 in _lwp_start () from /usr/lib/lwp/libthread.so.1
Previous frame identical to this frame (corrupt stack?)
/net/freising/export/software/3rdparty/Mozilla/1.7/mozilla/mailnews/imap/src/nsImapMailFolder.cpp:2634:87518:middle:0xfaf51484
(gdb) where
#0  0xfaf51484 in nsImapMailFolder::UpdateImapMailboxInfo (this=0xdf06f8,
aProtocol=0xbd56b8, aSpec=0x266fc88) at nsImapMailFolder.cpp:2634
#1  0xfe390360 in XPTC_InvokeByIndex () at xptcstubs_sparc_solaris.cpp:126
#2  0xfe36d660 in EventHandler (self=0x2751948) at nsProxyEvent.cpp:542
#3  0xfe362554 in PL_HandleEvent (self=0x2751948) at plevent.c:673
#4  0xfe3623dc in PL_ProcessPendingEvents (self=0xf2880) at plevent.c:608
#5  0xfe364a44 in nsEventQueueImpl::ProcessPendingEvents (this=0xdd1a8) at
nsEventQueue.cpp:391
#6  0xfd6c9234 in event_processor_callback (source=0x39fcf0, condition=G_IO_IN,
data=0xdd1a8) at nsAppShell.cpp:67
#7  0xfea810b8 in g_io_unix_dispatch () from
/usr/dist/share/evolution/lib/libglib-2.0.so.0
#8  0xfea413fc in g_main_dispatch () from
/usr/dist/share/evolution/lib/libglib-2.0.so.0
#9  0xfea42f64 in g_main_context_dispatch () from
/usr/dist/share/evolution/lib/libglib-2.0.so.0
#10 0xfea435f4 in g_main_context_iterate () from
/usr/dist/share/evolution/lib/libglib-2.0.so.0
#11 0xfea4442c in g_main_loop_run () from
/usr/dist/share/evolution/lib/libglib-2.0.so.0
#12 0xfed78880 in gtk_main () from /usr/dist/share/evolution/lib/libgtk-x11-2.0.so.0
#13 0xfd6c9a6c in nsAppShell::Run (this=0x1f9c00) at nsAppShell.cpp:142
#14 0xfc7ca280 in nsAppShellService::Run (this=0x1fa2a0) at
nsAppShellService.cpp:523
#15 0x000275b8 in main1 (argc=1, argv=0xffbfe2bc, nativeApp=0x1ef138) at
nsAppRunner.cpp:1303
#16 0x00028938 in main (argc=1, argv=0xffbfe2bc) at nsAppRunner.cpp:1780
(gdb) Quit
(gdb) 

Comment 3

[David :Bienvenu]

file | compact folders compacts all folders in the account. context menu |
compact this folder compacts the current folder. The crash is a dup...

*** This bug has been marked as a duplicate of 257079 ***