When inserting a link into a page in Composer, Mozilla dies. To repeat: - start Mozilla - File->New->Blank Page - Click the link icon - Text: "foo", link to: "bar" -foom! Program received signal SIGSEGV, Segmentation fault. 0xc9b4cc1 in _XimLocalFilter () (gdb) bt #0 0xc9b4cc1 in _XimLocalFilter () #1 0xc98e53d in XFilterEvent () #2 0xc8f496e in _XtDefaultDispatcher () #3 0xc8f4bd3 in XtDispatchEvent () #4 0xc889d14 in RemoveAllPMgr () #5 0xc8ea3e3 in XtCallCallbackList () #6 0xc8f0cb3 in Phase2Callbacks () #7 0xc8f0bd1 in Recursive () #8 0xc8f0f72 in XtPhase2Destroy () #9 0xc8f115e in _XtDoPhase2Destroy () #10 0xc8f4bf4 in XtDispatchEvent () #11 0xc8fdc63 in XtAppProcessEvent () #12 0x808cfdc in fe_EventLoop () #13 0x808ef29 in main () #14 0x805ebc4 in __start () BSD/OS 4.0, X11R6, Motif 1.2.2, autoconf build, CVS as of 1998/10/07 Clean build with -O2 ../configure --with-nspr=/usr/local/nspr --enable-editor --enable-mail-compose --enable-ldap

This is a composer bug. Akkana owns the XFE composer. thanks. Reassign to akkana@netscape.com.

I can't reproduce this on my IRIX (non-autoconf) build. I'll try an autoconf build with those flags on some other platforms and see if I can reproduce it. We've seen similar stack traces in the past on Solaris, where a destroy callback wasn't being called from phase2destroy, or where the object owning a widget had been deleted too early in the process before the widget's destroy callback was called. Knowing which widget was being deleted would be a big help; if you see this stack trace again (or if you still have the core file handy), could you try to find out the widget's XtName in any of the stages 5 through 9 in the stack trace? That's in case I'm not able to reproduce it here, though I'll try. What flavor of BSD are you on?

Setting all current Open Critical and Major to M3

this is an old codebase bug, marking resolved won't fix in MozillaClassic

marking as verified since this is against old code, if applicable in apprunner, please open a new bug