200777 - DocBook/HTML stylesheet doesn't work in Mozilla

Status: RESOLVED FIXED

(Core :: XSLT, defect)

Description

[Roland Mainz]

Trying to browse a DocBook/XML document using a DocBook--->HTML XSL stylesheet
crashes Mozilla (2003-03-27-08-trunk).

Steps to reproduce:
1. Download
http://aleron.dl.sourceforge.net/sourceforge/docbook/docbook-xsl-1.60.1.tar.gz
2. Unpack archive 
% mkdir /tmp/docbook_xsl ; cd /tmp/docbook_xsl
% gzcat docbook-xsl-1.60.1.tar.gz | tar -xf -
3. Add stylesheet reference
(/tmp/docbook_xsl/docbook-xsl-1.60.1/html/docbook.xsl) to the DocBook/XML
document
4. Browse document

Result:
Crash

Expected result:
No crash

Additional details:
Stack trace looks like this:
-- snip --
% ./mozilla -g -d dbx
./run-mozilla.sh -g -d dbx ./mozilla-bin
MOZILLA_FIVE_HOME=.
[snip]
detected a multithreaded program
(dbx) run file:///tmp/docbook_xsl/docbook-xsl-1.60.1/x.xml
Running: mozilla-bin file:///tmp/docbook_xsl/docbook-xsl-1.60.1/x.xml 
(process id 22453)
Reading libCrun.so.1
[snip]
Reading libtransformiix.so
Start reading in bookmarks.html
Finished reading in bookmarks.html  (125224 microseconds)
Reading xomEuro.so.2
WEBSHELL+ = 4
t@1 (l@4) signal ILL (illegal opcode) in (unknown) at 0x8f9984
0x008f9984:     unimp   0x1
Current function is nsCOMPtr_base::~nsCOMPtr_base
   65                           NSCAP_RELEASE(this, mRawPtr);
(dbx) where
current thread: t@1
  [1] 0x8f9984(0x8f9980, 0xf9df1a30, 0x1, 0xff3e4270, 0xf941e6c4, 0x1e6), at
0x8f9983
=>[2] nsCOMPtr_base::~nsCOMPtr_base(this = 0x88a460), line 65 in "nsCOMPtr.cpp"
  [3] nsCOMPtr<nsIAtom>::~nsCOMPtr(0x88a460, 0x0, 0xff2b5eec, 0xff130ae0,
0xffbee714, 0x2b08), at 0xf94cdadc
  [4] txNameTest::~txNameTest(this = 0x88a458), line 42 in "txNameTest.cpp"
  [5] __SLIP.DELETER__C(0x88a458, 0x1, 0x8b2958, 0x8b2978, 0x7dd7e8, 0x8), at
0xf94ce130
  [6] txStepPattern::~txStepPattern(this = 0x9bdab0), line 464 in
"txXSLTPatterns.cpp"
  [7] __SLIP.DELETER__O(0x9bdab0, 0x1, 0xff2b5eec, 0xff3e4270, 0xf9413125,
0x261), at 0xf957ada0
  [8] nsAutoPtr<txPattern>::~nsAutoPtr(this = 0x7f9d38), line 99 in
"nsAutoPtr.h"
  [9] txTemplateItem::~txTemplateItem(0x7f9d30, 0xf9df1a30, 0x1, 0xff3e4270,
0xf941e6c4, 0x1e6), at 0xf9569038
  [10] __SLIP.DELETER__K(0x7f9d30, 0x1, 0x1, 0xff3e4270, 0xf941dc6a, 0x9), at
0xf9568928
  [11] txStylesheet::ImportFrame::~ImportFrame(this = 0x83dba0), line 675 in
"txStylesheet.cpp"
  [12] txStylesheet::~txStylesheet(this = 0x83da98), line 123 in
"txStylesheet.cpp"
  [13] txStylesheet::Release(this = 0x83da98), line 78 in "txStylesheet.h"
  [14] nsRefPtr<txStylesheet>::~nsRefPtr(this = 0x8d921c), line 989 in
"nsAutoPtr.h"
  [15] txStylesheetCompilerState::~txStylesheetCompilerState(this = 0x8d9218),
line 577 in "txStylesheetCompiler.cpp"
  [16] txStylesheetCompiler::~txStylesheetCompiler(0x8d9218, 0x4, 0xff344570,
0xff130ae0, 0xffbee008, 0x0), at 0xf95642e0
  [17] __SLIP.DELETER__C(0x8d9218, 0x1, 0xff35ca24, 0xffbee2dc, 0x8d6bf0, 0x0),
at 0xf9563d58
  [18] txStylesheetCompiler::Release(this = 0x8d9218), line 80 in
"txStylesheetCompiler.cpp"
  [19] nsRefPtr<txStylesheetCompiler>::~nsRefPtr(this = 0x8d6c00), line 989 in
"nsAutoPtr.h"
  [20] txStylesheetSink::~txStylesheetSink(this = 0x8d6bf0), line 95 in
"txMozillaStylesheetCompiler.cpp"
  [21] __SLIP.DELETER__E(0x8d6bf0, 0x1, 0xf95f136d, 0x0, 0x1c000, 0x879), at
0xf9506f68
  [22] txStylesheetSink::Release(this = 0x8d6bf0), line 97 in
"txMozillaStylesheetCompiler.cpp"
  [23] nsParser::~nsParser(this = 0x8d96b8), line 364 in "nsParser.cpp"
  [24] __SLIP.DELETER__D(0x8d96b8, 0x1, 0xfac2563d, 0x0, 0xffbee008, 0x0), at
0xfabab0d0
  [25] nsParser::Release(this = 0x8d96b8), line 379 in "nsParser.cpp"
  [26] nsCOMPtr_base::assign_assuming_AddRef(this = 0x8d9520, newPtr = (nil)),
line 440 in "nsCOMPtr.h"
  [27] nsCOMPtr_base::assign_with_AddRef(this = 0x8d9520, rawPtr = (nil)), line
74 in "nsCOMPtr.cpp"
dbx: warning: can't find file
"/shared/bigtmp2/mozilla/2003-03-27-08-trunk_cvs/objdir_ws7_gtk/netwerk/build/nsFileChannel.o"
dbx: warning: see `help finding-files'
  [28] nsCOMPtr<nsIStreamListener>::operator=(0x8d9520, 0x0, 0x0, 0x0, 0x1c000,
0x879), at 0xfce4bfa0
  [29] nsFileChannel::OnStopRequest(0x8d94f0, 0x8daae0, 0x0, 0x0, 0x1c000,
0x879), at 0xfce4b9cc
dbx: warning: can't find file
"/shared/bigtmp2/mozilla/2003-03-27-08-trunk_cvs/objdir_ws7_gtk/netwerk/build/nsInputStreamPump.o"
  [30] nsInputStreamPump::OnStateStop(0x8daae0, 0x1, 0xffffffff, 0xfffffff8,
0x0, 0x9d2f99), at 0xfccafeec
  [31] nsInputStreamPump::OnInputStreamReady(0x8daae0, 0x8dab9c, 0xff35ca24,
0xffbee964, 0xfe35155b, 0x378), at 0xfccaf49c
dbx: warning: can't find file
"/shared/bigtmp2/mozilla/2003-03-27-08-trunk_cvs/objdir_ws7_gtk/xpcom/build/nsStreamUtils.o"
  [32] nsInputStreamReadyEvent::EventHandler(0xafde44, 0x1, 0x0, 0x0, 0x0, 0x0),
at 0xfd9b72b8
dbx: warning: can't find file
"/shared/bigtmp2/mozilla/2003-03-27-08-trunk_cvs/objdir_ws7_gtk/xpcom/build/plevent.o"
  [33] PL_HandleEvent(0xafde44, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfda14038
  [34] PL_ProcessPendingEvents(0x145360, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfda13cd0
dbx: warning: can't find file
"/shared/bigtmp2/mozilla/2003-03-27-08-trunk_cvs/objdir_ws7_gtk/xpcom/build/nsEventQueue.o"
  [35] nsEventQueueImpl::ProcessPendingEvents(0x14a5d0, 0x0, 0x0, 0x0, 0x0,
0x0), at 0xfda17f40
  [36] event_processor_callback(data = 0x14a5d0, source = 7, condition =
GDK_INPUT_READ), line 194 in "nsAppShell.cpp"
  [37] our_gdk_io_invoke(source = 0x31b890, condition = G_IO_IN, data =
0x261148), line 72 in "nsAppShell.cpp"
dbx: warning: can't find file
"/home/gisburn/package-builds/glib/glib-1.2.8/objdir/giounix.lo"
  [38] g_io_unix_dispatch(0x31e588, 0xffbeed40, 0x261148, 0xff3e4270,
0xff35ca24, 0xffbeeca8), at 0xfe2b2dc8
dbx: warning: can't find file
"/home/gisburn/package-builds/glib/glib-1.2.8/objdir/gmain.lo"
  [39] g_main_dispatch(0xffbeed40, 0x100eb8, 0x1, 0x261148, 0xfe35155b, 0x378),
at 0xfe2b6dc8
  [40] g_main_iterate(0x1, 0x1, 0x0, 0x0, 0x0, 0x0), at 0xfe2b7bcc
  [41] g_main_run(0x153988, 0x153988, 0x0, 0x0, 0x0, 0x0), at 0xfe2b7f64
dbx: warning: can't find file
"/home/gisburn/package-builds/gtk+/gtk+-1.2.8/objdir/gtk/gtkmain.lo"
  [42] gtk_main(0x14a5d0, 0x0, 0xffbeee98, 0x0, 0x0, 0x0), at 0xfe4d60a0
  [43] nsAppShell::Run(this = 0x369700), line 334 in "nsAppShell.cpp"
  [44] nsAppShellService::Run(this = 0x1c10a0), line 479 in
"nsAppShellService.cpp"
  [45] main1(argc = 2, argv = 0xffbef304, nativeApp = 0x14e8e0), line 1271 in
"nsAppRunner.cpp"
  [46] main(argc = 2, argv = 0xffbef304), line 1642 in "nsAppRunner.cpp"
(dbx) print this
this = 0x88a460
(dbx) print mRawPtr
mRawPtr = 0x8f9980
-- snip --

Comment 1

[Axel Hecht]

so, x.xml is not part of the testcases, afaict.
Does this happen with just one testcase, or could you give a name of one
that crashes?

Comment 2

[Roland Mainz]

Axel Hecht wrote:
> so, x.xml is not part of the testcases, afaict.
> Does this happen with just one testcase, or could you give a name of one
> that crashes?

x.xml was just the README.xml from the tarball where I explicitly added the full
path to the XSL stylesheet.

Comment 3

[Roland Mainz]

It seems that any XML document with that XSL stylesheet triggers the crash...
;-(

Comment 4

[Axel Hecht]

spun off bug 200999 for the crasher.
bummers is, it still doesn't work, even more my dtd-from-file loading build.
(Note that docbook stylesheet do some fancy XML stuff for l10n.)
Didn't find why and where yet, and it works on standalone.
I have the feeling that we don't propagate some errors nicely, as 
txCompileObserver::onDoneCompiling isn't called at all, AFAICT.

Over to Jonas, he might have an idea where stuff is supposed to go.

Comment 5

[Axel Hecht]

btw, on my debug build, just compiling the docbook stylesheets takes ages.
Sounds like one should profile this.

Comment 6

[Axel Hecht]

... and, why does it take longer than on standalone? That doesn't make sense
at all. To me.

Comment 7

[Axel Hecht]

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

Comment 8

[Axel Hecht]

Attachment: read dtds from file://

so that others know why this may work a tad further on my tree, I attach the
patch I have to load DTDs from file:// urls

Comment 9

[Axel Hecht]

ok, I have added some logging to see which files load, and it seems like
module takes ages, but finishes. It just doesn't call back into content.
That is, I get a warning from the viewer that mDocument is null.
I don't see any warning up to the successful load of article.001.xml (which is
what I use).

The only difference is that due to async loading in module, the main stylesheet
is done loading while the subsheets are still coming in. I guess it drops the 
feedback somewhere. Not sure where.

Logging patch is in bug 70855.

Comment 10

[Axel Hecht]

Attachment: log for xslt:1 with io logging patch.

Comment 11

[Axel Hecht]

so, these stylesheets use a xml file called VERSION, which is displayed fine
in the browser (prettyprinting kicks in).
but we don't get a doneLoading for that one, so that file might be the culprit,
as, AFAICT, it's the only file in the suite of files that requires content 
sniffing.
bz, I know you're writing docs on this, could you enlighten us?
The load happens here:
http://lxr.mozilla.org/seamonkey/source/extensions/transformiix/source/xslt/txMozillaStylesheetCompiler.cpp#306

Comment 12

[Boris Zbarsky [:bzbarsky]]

This load isn't going through the URILoader at all... it's just a direct load
into the parser....

Where is this "VERSION" file?  I assume that if we sniff the wrong content type
for it bad things happen?

(oh, and what's the point of the charset stuff in that function?  It's a
complete no-op....)

Comment 13

[Axel Hecht]

works from file, due to peterv adding sniffing for file to achieve compatibility
with uriloader. All others pay cash, that is, you have to change VERSION.
I wonder why Roland is shipping builds and not closing this bug.