Closed Bug 141252 Opened 21 years ago Closed 19 years ago

SVG enabled builds crash on loading image/svg+xml files or files with '.svg' extension


(Core :: SVG, defect)

Not set





(Reporter: bugs, Assigned: alex)




(Keywords: crash)


(2 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20020108
BuildID:    2002042914 cest

Visit url.
Page crashes.
Other tidbits.  Was generated using SodiPodi.  Unfortunately, I can't remember
at what stage in generating the image it started crashing Mozilla.
Interestingly,  it also crashes Nautilus (the one bundled with RH7.2, current
Nautilus version loads without crashing)

Loads fine in SodiPodi.  Loads fine in Adobe moz SVG plugin, only with all the
opacity:100% being treated as more like 50% (3.0 beta plugin build 77, gave
Adobe feedback)

This might be a general bug, but couldn't find a windows/mac/solaris user to test.

Reproducible: Always

Actual Results:  crashes

Expected Results:  render a vector graphic
my first attempt at an SVG, generated using sodipodi
It does render (sort-of) if you give the file an .xml extension. See

On Linux we seem to crash for all files that have .svg extension. On Windows we
don't crash but nothing is displayed. 
bbaetz, do you have an idea what might be going on?
Ever confirmed: true
Summary: SVG enabled builds crash on loading this sodipodi generated file → SVG enabled builds crash on loading '*.svg' files
Are you sure that's the problem?
Because the w3 test suite has all its SVG images named as .svg
You'd think if all *.svg images crashed linux, someone trying the w3 test suite
by now would have noticed.
Heck, I even duplicated the MIME type from
furthermore, mozilla should completely ignore extension, and use only MIME - as
 good non-IE browser should do.

Summary: SVG enabled builds crash on loading '*.svg' files → SVG enabled builds crash on loading this sodipodi generated file
Yes, the svg test suite is broken as well (for me at least).
The problem seems to be with the image/svg+xml handler. If you serve the file 
as straight xml it works.
IIRC, internally we map '.svg' onto the image/svg+xml mime type. Hence local 
files with that extension also crash.
Summary: SVG enabled builds crash on loading this sodipodi generated file → SVG enabled builds crash on loading image/svg+xml files or files with '.svg' extension
Keywords: crash
Oh, joy. Stacktrace?
Hmm, I can't even get a stack trace.
GDB tells me something like this:

[New Thread 4101 (LWP 15059)]
warning: property switchskins already exists
warning: property switchskinstitle already exists
No symbol "endif" in current context.

Cannot find user-level thread for LWP 15072: generic error
(gdb) Cannot find thread 1024: generic error
(gdb) bt
#0  0x4109ad6c in nsDocument::ResetToURI (this=Error accessing memory address
0xbfffe1d4: No such process.
) at nsDocument.cpp:683
Error accessing memory address 0x4109aae0: No such process.

What gdb version? You should be using at least 5.1.x
gdb 2001-12-11-cvs. I'm going to try 5.1.2
same problem with 5.1.2 :-((
Hmm.  I crashed at the URL given above with 2002042909 on Win98SE.


I actually found this bug when searching for SVG crashers.  I noticed the crash
at which was linked at  That seems to
be the same problem.  
OS: Linux → All
Not that anyone probably cares that much, but offtopic problem with the Adobe
misparsing was due to fill-opacity of 0.5 in svg tag.  which was overridden
later but obviously important to Adobe.
*** Bug 141726 has been marked as a duplicate of this bug. ***
Bored, curious if anyone had been working on this bug, so decided to attach
image with Adobe plugin problem, at least, resolved.
(adobe only understands decimal, not percentage)
Please fix this. Not working is OK, but crashing is NOT OK.
Seems to be dup of bug 130497, same stack.
*** Bug 130497 has been marked as a duplicate of this bug. ***
*** Bug 146542 has been marked as a duplicate of this bug. ***
Every time my mozilla crashes, I provides the following message before dying:

###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 
    'mRawPtr != 0', file ../../../../dist/include/xpcom/nsCOMPtr.h, line 650
Break: at file ../../../../dist/include/xpcom/nsCOMPtr.h, line 650
see bug #149259 for a stack trace
*** Bug 149259 has been marked as a duplicate of this bug. ***
nick: that's good, can you
./mozilla ''

for each assertion, mozilla will be suspended (see unix debugging faq )
with a message indicating the assert that failed.
to continue past as many asserts as it takes until you get to the null 
dereference assert.

then, do something like
(ps |grep 82514 | grep -v grep); ./mozilla -g
attach {the number that grep returned}
post the ouptut and try to investigate further :)
right, make that something like
(ps |grep 82515 | grep -v grep); ./mozilla -g

(you're looking for the mozilla-bin commandline, and some people run multiple 
mozilla-bin's, so grepping for that isn't always a good idea, whereas looking 
for a magic string that's part of the url that mozilla-bin given in the 
commandline should be more unique)
This is also a problem for me on WinXP Pro. As Nick seems to have disapeared for
a while, would I be able to help? If someone can tell me what to do I would be
willing to spend a few hours crashing Mozilla to try and get some helpful info.
One thing that may be a problem though is that Windows seems to detect the crash
before Mozilla does and tries to send the data to Microsoft rather than Mozilla
handling it. Then again is the SVG+MathML zip file talkback enabled?
Perhaps I should also have mentioned that I also use Linux (in case the tools
required are only available on Linux). 

BTW, the workaround of giving local files a .xml suffix doesn't work for me on
Windows. Mozilla still crashes so I have no way to use Mozilla with SVG files. 
XML extension doesn't help much anyway :)
You just get to see a few data portions, doesn't get parsed as SVG - for me anyway.
*** Bug 153897 has been marked as a duplicate of this bug. ***
I have the same ASSERTION message when I want to view a SVG file.
I followed the instructions given to debug, here is the output of list :
in xpfe/bootstrap/nsAppRunner.cpp

1711	  InstallUnixSignalHandlers(argv[0]);
1712	#endif
1714	#if defined(XP_OS2)
1715	  __argc = argc;
1716	  __argv = argv;
1717	#endif /* XP_OS2 */
1719	#if defined(XP_BEOS)
1720	  if (NS_OK != InitializeBeOSApp())
that means that gdb couldn't find symbols for the function you were actually 
in -- iow it's useless. you need to get symbols.
This is now fixed on SVG_20020806_BRANCH.
Crashes are also observed with SVG enabled Mozilla/5.0 (X11; U; FreeBSD i386;
en-US; rv:1.2a) Gecko/20020912.  build ID 2002091299, wfiw. 
NATIVE_THEME_SUPPORT used, unknown at this point whether that's related, but the
offending function, by gdb, is as noted in comment #6.

Sample URLs:

URLs that exhibit expected behavior:

sorry for paste, here's --debug output from browsing is similar.  "(no
debugging symbols found)..." spam deleted:

% /usr/local/mozilla/1.2a/mozilla/mozilla --debug
/usr/local/mozilla/1.2a/mozilla/ -g
/usr/bin/gdb /usr/local/mozilla/1.2a/mozilla/mozilla-bin -x /tmp/mozargs518
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)...
(gdb) run
Starting program: /usr/local/mozilla/1.2a/mozilla/mozilla-bin 
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x28ab689c in nsDocument::ResetToURI () from
(gdb) backtrace 
#0  0x28ab689c in nsDocument::ResetToURI () from
#1  0x28ab6709 in nsDocument::Reset () from
#2  0x28a18204 in nsXMLDocument::Reset () from
#3  0x28ab6cf6 in nsDocument::StartDocumentLoad () from
#4  0x28a192df in nsXMLDocument::StartDocumentLoad () from
#5  0x289077cb in nsContentDLF::CreateDocument () from
#6  0x289070c0 in nsContentDLF::CreateInstance () from
#7  0x29085294 in nsDocShell::NewContentViewerObj () from
#8  0x29084d37 in nsDocShell::CreateContentViewer () from
#9  0x290933f2 in nsDSURIContentListener::DoContent () from
#10 0x28fd54e6 in nsDocumentOpenInfo::DispatchContent () from
#11 0x28fd48f4 in nsDocumentOpenInfo::OnStartRequest () from
#12 0x287536c6 in nsHttpChannel::ProcessNormal () from
#13 0x2875308f in nsHttpChannel::ProcessResponse () from
#14 0x2875b3db in nsHttpChannel::OnStartRequest () from
#15 0x28774ae4 in nsOnStartRequestEvent::HandleEvent () from
#16 0x28706c50 in nsARequestObserverEvent::HandlePLEvent () from
#17 0x281f578d in PL_HandleEvent () from /usr/local/mozilla/1.2a/mozilla/
#18 0x281f5695 in PL_ProcessPendingEvents () from
#19 0x281f67db in nsEventQueueImpl::ProcessPendingEvents () from
#20 0x28d32abf in nsAppShell::SetDispatchListener () from
#21 0x28d327ee in keysym2ucs () from
#22 0x283f364c in g_io_unix_dispatch () from /usr/local/lib/
#23 0x283f4cf3 in g_main_dispatch () from /usr/local/lib/
#24 0x283f531c in g_main_iterate () from /usr/local/lib/
#25 0x283f54b4 in g_main_run () from /usr/local/lib/
#26 0x2831582b in gtk_main () from /usr/X11R6/lib/
#27 0x28d32f94 in nsAppShell::Run () from
#28 0x28cfc252 in nsAppShellService::Run () from
#29 0x8051c1c in getCountry ()
#30 0x805257c in main ()
#31 0x804cc59 in _start ()

Depends on: svgbranch
On Linux with latest CVS I get a different stack trace.  The top few lines are:

#0  0x4212b1e7 in main_arena () from /lib/i686/
#1  0x0806f499 in nsCOMPtr_base::~nsCOMPtr_base() ()
#2  0x40c76e6e in NS_NewXMLContentSink(nsIXMLContentSink**, nsIDocument*,
nsIURI*, nsIWebShell*, nsIChannel*) ()
   from /usr/src/mozilla/dist/bin/components/
#3  0x40c823ac in nsXMLDocument::StartDocumentLoad(char const*, nsIChannel*,
nsILoadGroup*, nsISupports*, nsIStreamListener**, int, nsIContentSink*) ()
   from /usr/src/mozilla/dist/bin/components/
#4  0x40de7a73 in nsSVGDocument::StartDocumentLoad(char const*, nsIChannel*,
nsILoadGroup*, nsISupports*, nsIStreamListener**, int, nsIContentSink*) ()
   from /usr/src/mozilla/dist/bin/components/
#5  0x40985c52 in nsContentDLF::CreateDocument(char const*, nsIChannel*,
nsILoadGroup*, nsISupports*, nsID const&, nsIStreamListener**,
nsIContentViewer**) ()
   from /usr/src/mozilla/dist/bin/components/
This problem is still occuring for me as well. I recently upgraded

Mozilla 1.2.1
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030204

And I am still crashing on SVG files. In particular when looking to open the SVG
files on the W3's new reccomendation of SVG 1.1

I really don't know why it crashes, but it still does.
ssieb, the crash you're seeing is caused by bug 188729 (or rather the fix to
it).  I'll post a patch for it there.
And with that patch I am _not_ seeing a crash anymore (I just get a helper app
dialog because our parser doesn't know it can handle SVG).
No crash occurs, only helper application dialog opens with 2003-07-16
SVG(libart) enabled build on FreeBSD.

I think this is WFM and remaining problem is bug 155730, bug 160882.
(Adobe SVG plugin issue is bug 133567)
Fixed by branch landing (bug 182533)
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.