mailshell.xul (apprunner -mail) will crash on Linux. The problem appears to be related to using ENTITY. Here's a stack trace: Program received signal SIGSEGV, Segmentation fault. 0x406131ab in StyleSetImpl::ResolveStyleFor (this=0x8150358, aPresContext=0x80e0cb0, aContent=0x0, aParentContext=0x0, aForceUnique=0) at nsStyleSet.cpp:537 (gdb) where #0 0x406131ab in StyleSetImpl::ResolveStyleFor (this=0x8150358, aPresContext=0x80e0cb0, aContent=0x0, aParentContext=0x0, aForceUnique=0) at nsStyleSet.cpp:537 #1 0x40608dd5 in nsPresContext::ResolveStyleContextFor (this=0x80e0cb0, aContent=0x0, aParentContext=0x0, aForceUnique=0, aResult=0xbffff28c) at nsPresContext.cpp:390 #2 0x40e27aea in XULDocumentImpl::StartLayout (this=0x80e4548) at nsXULDocument.cpp:3470 #3 0x40e2248e in XULDocumentImpl::EndLoad (this=0x80e4548) at nsXULDocument.cpp:1637 #4 0x40e3f4ee in XULContentSinkImpl::DidBuildModel (this=0x80e07c0, aQualityLevel=1) at nsXULContentSink.cpp:499 #5 0x406eda87 in CWellFormedDTD::DidBuildModel (this=0x81589f8, anErrorCode=0, aNotifySink=1, aParser=0x80e08b8, aSink=0x80e07c0) at nsWellFormedDTD.cpp:289 #6 0x406e6636 in nsParser::DidBuildModel (this=0x80e08b8, anErrorCode=0) at nsParser.cpp:446 #7 0x406e72ae in nsParser::ResumeParse (this=0x80e08b8, aDefaultDTD=0x0) at nsParser.cpp:824 #8 0x406e6731 in nsParser::EnableParser (this=0x80e08b8, aState=1) at nsParser.cpp:523 #9 0x40e4000e in XULContentSinkImpl::DoneLoadingStyle (aLoader=0x816b3e8, aData=@0x816b470, aRef=0x816b438, aStatus=0) at nsXULContentSink.cpp:775 #10 0x402856e7 in ?? () from /builds/sspitzer/MOZILLA/04.23.1999/04.30/mozilla/dist/bin/libnetlib.so #11 0x402a73aa in nsDocumentBindInfo::OnStopBinding (this=0x816b488, aURL=0x816b390, aStatus=0, aMsg=0xbffff434) at nsDocLoader.cpp:2127 #12 0x40288a6f in ?? () from /builds/sspitzer/MOZILLA/04.23.1999/04.30/mozilla/dist/bin/libnetlib.so #13 0x401a264b in net_ProcessFile (cur_entry=0x816b6e8) at mkfile.c:1360 #14 0x4025946f in NET_ProcessNet (ready_fd=0x0, fd_type=1) at mkgeturl.c:3355 #15 0x40261351 in NET_PollSockets () at mkselect.c:298 #16 0x402822a2 in ?? () from /builds/sspitzer/MOZILLA/04.23.1999/04.30/mozilla/dist/bin/libnetlib.so #17 0x4016ade9 in TimerImpl::FireTimeout (this=0x81547d8) at nsTimer.cpp:73 #18 0x4016b2d2 in nsTimerExpired (aCallData=0x81547d8) at nsTimer.cpp:189 #19 0x40a9bc11 in ?? () from /usr/lib/libglib-1.2.so.0 #20 0x40a9add2 in ?? () from /usr/lib/libglib-1.2.so.0 #21 0x40a9b3bb in ?? () from /usr/lib/libglib-1.2.so.0 #22 0x40a9b571 in ?? () from /usr/lib/libglib-1.2.so.0 #23 0x409c115b in ?? () from /usr/lib/libgtk-1.2.so.0 #24 0x400a1858 in ?? () from /builds/sspitzer/MOZILLA/04.23.1999/04.30/mozilla/dist/bin/libwidgetgtk.so #25 0x40019e51 in ?? () from /builds/sspitzer/MOZILLA/04.23.1999/04.30/mozilla/dist/bin/libnsappshell.so #26 0x804b344 in main (argc=2, argv=0xbffffa24) at nsAppRunner.cpp:438 Before this crash, this comes flying out: XML Error in file 'file:////builds/sspitzer/MOZILLA/04.23.1999/04.30/mozilla/dist/bin/res/mailnews/messenger/mailshell.xul', Line Number: 202, Col Number: 8, Description: udfndett Source Line: lick="MsgOpenAttachment();"/> Defining ENTITYs doesn't cause a crash, but referring them them does. putterman tells me this doesn't crash on windows.

Yes, we saw the same thing yesterday in the editor xul files; we had to rewrite the files to get rid of all the entities in order to avoid the startup crash.

Q: 1. Has this ever worked on UNIX before? 2. What does the XUL file look like? Which file and what revision number?

We were seeing a crash yesterday on EditorAppShell.xul version 1.4; the current version, 1.5, is the one where I had to remove the entity references. I don't know whether it has ever worked on Unix; I don't think we used entities in XUL files before that.

*** Bug 5440 has been marked as a duplicate of this bug. ***

Yes, it has worked on Linux. Seth made these changes last week, I think, and it worked fine. This breakage is within the last couple of days. Our file that's breaking is mailnews/ui/messenger/resources/mailshell.xul

This target date for the external DTD support in XML parser is M5. This is a task block for that.

We're pretty blocked right now on Linux. We really don't want to have to back out all of our changes because we have a lot of xul that uses this.

Yes, I would suggest upgrading the severity to critical and target milestone to M5.

duplicate bug 5440 states that this also occurs on Windows. Don't know if the same cause here; if not, we'll open a separate bug.

I've checked in a fix for this. Deep in the bowels of expat, there was a typedef that was using the C++ wchar_t (wide character) type without checking for #define XML_UNICODE_WCHAR_T. I fixed that and all entities load up fine. Please update mozilla/expat and mozilla/htmlparser/src to get my changes. Marking Resolved Fixed.

Appears to be fixed. Marking verified.