268402 - Create subfolder + create mail filter = crash [@ g_main_context_remove_poll_unlocked]

Status: RESOLVED DUPLICATE of bug 269585

(MailNews Core :: Filters, defect)

Description

[David Favor]

User-Agent:       Mozilla/5.0 (X11; U; AIX 000F2B4C4C00; en-US; rv:1.8a5) Gecko/20041103
Build Identifier: Mozilla/5.0 (X11; U; AIX 000F2B4C4C00; en-US; rv:1.8a5) Gecko/20041103

It appears creating a subfolder somehow corrupts the list of mailboxes
mozilla knows about. Oddly, subfolders use to be created as subdirectories
under their parent. Now they are created with '.' seperators at the same
level as their parent.

Restarting mozilla allows mail filters to be created as expected, presumably
because mozilla recreate it's internal list of mailboxes at start time.

Reproducible: Always
Steps to Reproduce:
1. create a mail subfolder
2. bring up mail filters
3. click new


Actual Results:  
crash every time

Comment 1

[David Favor]

This problem occurs with both Classic and Modern themes.

Comment 2

[OstGote!]

Could you provide Talkback crash report IDs?

Comment 3

[David Favor]

No talkback is available, as this only appears to crash on AIX.
Last night I tested this on Windows and it worked. Although...
Now that I think, maybe the Windows box I tested this on had an
earilier version of Mozilla. I'll test this again tonight with
the lastest nightly build.

Comment 4

[timeless]

do you build your own aix builds?

Comment 5

[Philip K. Warren]

I cannot reproduce this behavior with a Mozilla GTK2 build from today. What type
of mail account are you using? I can't reproduce the behavior you are describing
with respect to creating mail folders or mail filters crashing. Can you please
provide more details?

Comment 6

[WADA:World Anti-bad-Duping Agency]

David Favor, did you execute "Run Filters on" before crash?
If yes, see bug 242600.

Comment 7

[David Favor]

Yes, I do my own nightly builds.

Comment 8

[David Favor]

Same behavior exists for the source I pulled at 8:15 CST last night.

I'm using IMAP accounts.

Comment 9

[David Favor]

"Run Filters" does create a crash, as do many other operations related
to IMAP subfolders and Mail Filters. What I'm doing to create this crash is:

1) start mozilla

2) create subfolder

3) click on Tools -> Mail Filters

Usually the crash occurs here. Sometimes when I click New to create
a new filter.

Comment 10

[timeless]

can you build without
--enable-optimize
and with one of:
--enable-debug
--enable-debugger-info-modules

and if possible catch this in dbx

Comment 11

[David Favor]

I can build with either --enable-debug or --enable-debugger-info-modules.
Let me know which you prefer.

Comment 12

[Calum Mackay]

confirmed, Linux/x86 20041104.

I can reliably reproduce by creating a sub-folder, and then clicking on it. I do
nightly checkouts/builds have have narrowed it down to:

   20041103  OK
   20041104  BAD

[and every build since then has the problem]

My checkouts run at 0500 GMT.

I haven't yet tried a debug build.

In my case, at least, I think it's not filter related (I don't use filters). The
crash will happen even if the subfolder isn't subsequently selected, but it may
take a little longer.

I've changed to All, but in fact it might just be related to all UNIX platforms?

The problem also occurs in Thunderbird.

Comment 13

[David Favor]

Verified. The last working build I have was a code pull at 11/02 22:15 CST.

What I see in dbx with --enable-debug turned on is this:

aasc24>dbx -d 100 /usr/local/mozilla-1.8a5-2004-11-11-0834/mozilla-bin core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Illegal instruction (illegal opcode) in pth_signal.pthread_kill [/usr/lib/libpth
reads.a] at 0xd005ab54 ($t1)
0xd005ab54 (pthread_kill+0xa8) 80410014        lwz   r2,0x14(r1)
(dbx) where
pth_signal.pthread_kill(??, ??) at 0xd005ab54
pth_signal._p_raise(??) at 0xd005a160
unnamed block $b54656, line 204 in "nsProfileLock.cpp"
FatalSignalHandler(int)(??), line 204 in "nsProfileLock.cpp"
warning: Unable to access address 0x0 from core
warning: could not locate trace table from starting address 0x0
g_main_context_remove_poll_unlocked(0x219eafd8, 0x0) at 0xd346d99c
g_io_unix_dispatch(0x219eb028, 0x205e4ea0, 0x219eae58) at 0xd34899dc
g_main_dispatch(0x2024c2d8) at 0xd346c9c0
g_main_context_dispatch(0x2024c2d8) at 0xd3471374
g_main_context_iterate(0x2024c2d8, 0x1, 0x1, 0x20bc82e8) at 0xd346c650
g_main_loop_run(0x20a7f128) at 0xd3470b28
gtk_main() at 0xd2fdfd14
Run()(??), line 142 in "nsAppShell.cpp"
Run()(??), line 220 in "nsAppStartup.cpp"
main1(int,char**,nsISupports*)(argc = 539275656, argv = 0x2ff214bc, nativeApp =
0x2021c1a8), line 1321 in "nsAppRunner.cpp"
main(argc = 1, argv = 0x2ff214f0), line 1799 in "nsAppRunner.cpp"
(dbx) up
pth_signal._p_raise(??) at 0xd005a160
(dbx) up
unnamed block $b54656, line 204 in "nsProfileLock.cpp"
(dbx) list
  204               raise(signo);
  205           }
  206           else if (oldact->sa_handler && oldact->sa_handler != SIG_IGN)
  207           {
  208               oldact->sa_handler(signo);
  209           }
  210       }
  211   
  212       // Backstop exit call, just in case.
  213       _exit(signo);
(dbx) p signo
804391760

If anyone desires, I can issue other dbx commands and place them
in this report.

Comment 14

[timeless]

g_main_context_remove_poll_unlocked(0x219eafd8, 0x0) at 0xd346d99c
looks *bad*. a quick google search indicates that you're supposed to pass a non
null filedescriptor...

Comment 15

[Calum Mackay]

I see a different trace:

(gdb) (gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e5ec95 in raise () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb62fe36c in __JCR_LIST__ () from
/usr/local/src/mozilla/mozilla/mozilla-2004111115/components/libprofile.so
#3  0x0000000b in ?? ()
#4  0xb62fc091 in nsProfileLock::FatalSignalHandler (signo=-1209656488) at
nsProfileLock.cpp:204
#5  <signal handler called>
#6  0x000000c2 in ?? ()
#7  0xb632ce79 in event_processor_callback (source=0xb0543f78,
condition=G_IO_IN, data=0xb07e7080) at nsAppShell.cpp:67
#8  0xb7a1e1df in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#9  0xb79f8b92 in g_main_depth () from /usr/lib/libglib-2.0.so.0
#10 0xb79f9c88 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#11 0xb79f9fc0 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#12 0xb79fa603 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#13 0xb7c934e3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#14 0xb632d270 in nsAppShell::Run (this=0x0) at nsAppShell.cpp:142
#15 0xb64349be in nsAppStartup::Run (this=0xb05991d0) at nsCOMPtr.h:711
#16 0x0804cbff in main1 (argc=2, argv=0xbffff474, nativeApp=0x80d0668) at
nsCOMPtr.h:711
#17 0x0804d5b1 in main (argc=2, argv=0xbffff474) at nsAppRunner.cpp:1799
(gdb) 

Comment 16

[timeless]

that looks like the stack from bug 269074

Comment 17

[Calum Mackay]

it does? I don't see much in common, but what do I know :(

that bug seems related to Themes, which I haven't adjusted at all.

Comment 18

[Calum Mackay]

interestingly, I've just had the same stack trace from firefox, also crashing in
event_processor_callback():


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218838400 (LWP 8278)]
0xb69b5e76 in event_processor_callback (source=0x88ee6b0, condition=G_IO_IN,
data=0x88ee260) at nsAppShell.cpp:67
/usr/local/src/mozilla/cvs/mozilla/widget/src/gtk2/nsAppShell.cpp:67:2625:beg:0xb69b5e76
(gdb) bt
#0  0xb69b5e76 in event_processor_callback (source=0x88ee6b0, condition=G_IO_IN,
data=0x88ee260) at nsAppShell.cpp:67
#1  0xb7a1d1df in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#2  0xb79f7b92 in g_main_depth () from /usr/lib/libglib-2.0.so.0
#3  0xb79f8c88 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#4  0xb79f8fc0 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#5  0xb79f922d in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#6  0xb69b66dc in nsAppShell::DispatchNativeEvent (this=0x5, aRealEvent=0,
aEvent=0x0) at nsAppShell.cpp:277
#7  0xb634d4a5 in nsXULWindow::CreateNewContentWindow (this=0x8bb0b78,
aChromeFlags=1094, aAppShell=0x5, _retval=0x5) at nsCOMPtr.h:711
#8  0xb634cda9 in nsXULWindow::CreateNewWindow (this=0x8bb0b78,
aChromeFlags=143582896, aAppShell=0x81bb4a0, _retval=0x88ee260) at
nsXULWindow.cpp:1689
#9  0xb60c69f0 in nsAppStartup::CreateChromeWindow2 (this=0x80b21b8,
aParent=0xb635776c, aChromeFlags=1094, aContextFlags=5, aURI=0x0,
aCancel=0x88ee260, _retval=0xbfffd5cc) at nsCOMPtr.h:711
#10 0xb643308f in nsWindowWatcher::OpenWindowJS (this=0x8223a30,
aParent=0x8f2341c, aUrl=0x0, aName=0xbfffd7f4 "myWindow", aFeatures=0x8fda640
"scrollbars=no,status=no,width=220,height=200,top=450,left=250,resizable=no",
aDialog=0, argc=0, argv=0x5, _retval=0xbfffd8bc) at nsCOMPtr.h:711
#11 0xb64329a3 in nsWindowWatcher::OpenWindow (this=0x8223a30,
aParent=0x8f2341c, aUrl=0x5 <Address 0x5 out of bounds>, aName=0x5 <Address 0x5
out of bounds>, aFeatures=0x5 <Address 0x5 out of bounds>, aArguments=0x5,
_retval=0x5) at nsWindowWatcher.cpp:457
#12 0xb684bc49 in GlobalWindowImpl::OpenInternal (this=0x8f23418,
aUrl=@0xb6452428, aName=@0xbfffda3c, aOptions=@0xbfffd99c, aDialog=0, argv=0x0,
argc=0, aExtraArgument=0x5, aReturn=0xbfffdda0) at nsCOMPtr.h:711
#13 0xb68489e0 in GlobalWindowImpl::Open (this=0x8f23418, _retval=0xbfffdda0) at
nsGlobalWindow.cpp:3276
#14 0xb7f47f33 in XPTC_InvokeByIndex () at xptcinvoke_gcc_x86_unix.cpp:69
#15 0xb73beaea in XPCWrappedNative::CallMethod (ccx=@0xbfffde80,
mode=CALL_METHOD) at xpcwrappednative.cpp:2033
#16 0xb73c5036 in XPC_WN_CallMethod (cx=0x8f23540, obj=0x5, argc=5,
argv=0x88ee260, vp=0x5) at xpcwrappednativejsops.cpp:1287
#17 0xb7fa113f in js_Invoke (cx=0x8f23540, argc=3, flags=0) at jsinterp.c:1286
#18 0xb7fa9a9c in js_Interpret (cx=0x8f23540, result=0xbfffe240) at jsinterp.c:3507
#19 0xb7fa17a2 in js_Execute (cx=0x8f23540, chain=0x8f240d8, script=0x92dd5a8,
down=0x0, flags=5, result=0x5) at jsinterp.c:1562
#20 0xb7f7de02 in JS_EvaluateUCScriptForPrincipals (cx=0x8f23540, obj=0x8f240d8,
principals=0x5, chars=0x5, length=5, filename=0x5 <Address 0x5 out of bounds>,
lineno=5, rval=0x5) at jsapi.c:3698
#21 0xb683dc71 in nsJSContext::EvaluateString (this=0x8f23500,
aScript=@0xbfffe3d0, aScopeObject=0x8f240d8, aPrincipal=0x8b24a00, aURL=0x5
<Address 0x5 out of bounds>, aLineNo=5, aVersion=0x0, aRetValue=0xbfffe470,
aIsUndefined=0xbfffe3b4) at nsTString.h:141
#22 0xb686f3d7 in nsJSThunk::EvaluateScript (this=0x8b16838, aChannel=0x8fda550)
at nsCOMPtr.h:711
#23 0xb686fc2b in nsJSChannel::InternalOpen (this=0x89557e0, aIsAsync=1,
aListener=0x88ee260, aContext=0x0, aResult=0x88ee260) at nsAutoPtr.h:1040
#24 0xb686fbb3 in nsJSChannel::AsyncOpen (this=0x5, aListener=0x5, aContext=0x5)
at nsJSProtocolHandler.cpp:509
#25 0xb6476934 in nsDocumentOpenInfo::Open (this=0x96ee0b8, aChannel=0x89557e0)
at nsURILoader.cpp:222
#26 0xb64782ec in nsURILoader::OpenURI (this=0x81ec730, channel=0x89557e0,
aIsContentPreferred=5, aWindowContext=0x8f232e8) at nsCOMPtr.h:711
#27 0xb6469797 in nsDocShell::DoChannelLoad (this=0x8f232c0, aChannel=0x89557e0,
aURILoader=0x81ec730) at nsDocShell.cpp:5715
#28 0xb646913f in nsDocShell::DoURILoad (this=0x8f232c0, aURI=0x8fda4c0,
aReferrerURI=0x8a73ec0, aOwner=0x88ee260, aTypeHint=0x8e40410 "", aPostData=0x0,
aHeadersData=0x0, firstParty=1, aDocShell=0x0, aRequest=0x0) at nsCOMPtr.h:705
#29 0xb64689c7 in nsDocShell::InternalLoad (this=0x8f232c0, aURI=0x8fda4c0,
aReferrer=0x8a73ec0, aOwner=0x0, aInheritOwner=1, aWindowTarget=0xbfffec08,
aTypeHint=0x8e40410 "", aPostData=0x0, aHeadersData=0x0, aLoadType=2097153,
aSHEntry=0x0, firstParty=1, aDocShell=0x0, aRequest=0x0) at nsCOMPtr.h:948
#30 0xb646f693 in nsWebShell::OnLinkClickSync (this=0x8f232c0,
aContent=0x9765288, aVerb=eLinkVerb_Replace, aURI=0x8fda4c0,
aTargetSpec=0x936f078, aPostDataStream=0x5, aHeadersDataStream=0x5,
aDocShell=0x0, aRequest=0x0) at nsTString.h:113
#31 0xb646ec36 in HandlePLEvent (aEvent=0x8fda4f8) at nsCOMPtr.h:705
#32 0xb7f2ecb1 in PL_HandleEvent (self=0x8fda4f8) at plevent.c:692
#33 0xb7f2ebe8 in PL_ProcessPendingEvents (self=0x810f1f0) at plevent.c:627
#34 0xb7f305c9 in nsEventQueueImpl::ProcessPendingEvents (this=0x810f1a8) at
nsEventQueue.cpp:394
#35 0xb69b5e79 in event_processor_callback (source=0x835e5f8, condition=G_IO_IN,
data=0x88ee260) at nsAppShell.cpp:67
#36 0xb7a1d1df in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#37 0xb79f7b92 in g_main_depth () from /usr/lib/libglib-2.0.so.0
#38 0xb79f8c88 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#39 0xb79f8fc0 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#40 0xb79f9603 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#41 0xb7c934e3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#42 0xb69b6270 in nsAppShell::Run (this=0x0) at nsAppShell.cpp:142
#43 0xb60c55c2 in nsAppStartup::Run (this=0x5) at nsCOMPtr.h:711
#44 0x0804f64a in xre_main (argc=-1073745872, argv=0x805700c,
aAppData=0x805700c) at nsCOMPtr.h:711
#45 0x0804af67 in main (argc=5, argv=0x5) at nsBrowserApp.cpp:59
(gdb) graph display eventQueue
No symbol "eventQueue" in current context.
(gdb) print eventQueue
No symbol "eventQueue" in current context.
(gdb) graph display (nsIEventQueue *)data
(gdb) graph display *((nsIEventQueue *) data) dependent on 1
(gdb) ptype eventQueue
No symbol "eventQueue" in current context.
(gdb) 

Comment 19

[Darin Fisher]

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