288410 - Using fastLoad in a xul app results in ReadSegments underflow assertions

Status: RESOLVED WORKSFORME

(Toolkit Graveyard :: XULRunner, defect)

Description

[:Gijs (back August 25; he/him)]

Note: This bug probably needs to go somewhere else, but I do not know where, so
I'm filing it here for the moment.

When loading ChatZilla under XULRunner, I'm already getting an "unresponsive
script" warning whenever I start it (unsure if this has anything to do with it).
The first time I use it (so without fastLoad), things work after clicking
"Continue" on the warning.
The second, and sometimes only at the third time, fastLoad goes haywire. I get
assertions spewed to the console (I'm using a debug build built on 2005-03-29)

###!!! ASSERTION: demux ReadSegments underflow!: 'entry->mBytesLeft >= *aResult'
, file c:/devel/mozilla-trees/xulrunner/mozilla/xpcom/io/nsFastLoadFile.cpp, lin
e 614
###!!! ASSERTION: some strange stream corruption!: '!closure.mHasCarryoverByte',
 file c:/devel/mozilla-trees/xulrunner/mozilla/xpcom/io/nsBinaryStream.cpp, line
 596
###!!! ASSERTION: URI mapped to two different specs?: 'uriMapEntry->mDocMapEntry
 == nsnull', file c:/devel/mozilla-trees/xulrunner/mozilla/xpcom/io/nsFastLoadFi
le.cpp, line 423

Then XULRunner proceeds to just hang, occupying roughly 180MB in swap file and
varying amounts of RAM (30-50MB).

I will attach a zip of the files I'm currently using. This is a modified version
of ChatZilla as it is currently in CVS. I will be testing what happens when
using the version as it is in CVS at the moment.

Comment 1

[:Gijs (back August 25; he/him)]

Attachment: chatzilla folder as used when reproducing this bug

I forgot to add, after replacing the jar with a newly generated one, the app
will work another time, and fail the second or third time I start it again, so
this bug is reproducable.

Comment 2

[:Gijs (back August 25; he/him)]

Lowering to major severity, removing 'hang' from summary and keyword list.

It turns out, when the thread seems to 'hang', it actually pops up *another*
unresponsive script dialog, (under the various other windows I have open). When
clicking continue *again*, ChatZilla will open, however, it will still be
consuming about 180MB of swap space, which can hardly be called normal. The same
goes for these assertions, I think.

Comment 3

[Benjamin Smedberg]

oooh, fun!

Comment 4

[:Gijs (back August 25; he/him)]

Attachment: Modified 'simple' app, which produces the same results.

Okay, after also being able to reproduce this on chatzilla as pulled straight
from cvs, I chose to modify the simple app that comes with XULRunner a bit, to
see if I could get similar results.
Note that chrome.manifest has also been modified to save me from having to put
every modification back into the jar file. It uses relative paths now, and
seems to work fine like this, except for the bug you're reading right now.

When you click the submit button (nothing happens before that point), the
following code gets executed:

function init()
{
    // Loop, and loop, and loop...
    alert("executed");
    var bound = 1000000000;
    var foo;
    for (var i = 0; i < bound; i++)
    {
	dump("test\n");
    }
}

Weird thing:
* The assertion fires (and XR starts taking up huge amounts of RAM /swap space)
BEFORE the alert box shows. Does it have anything to do with the loop? Yes,
because when you comment it out, everything works fine again.
* Just changing the js file does not affect the reproducability (whereas
changing the jar, when still using one, DID change that). Maybe the xul file is
considered more important?

I'm still trying more stuff, but if anyone has hints / ideas, that would be
helpful :-).

(My apologies for a rather top to bottom approach, my C knowledge (and
knowledge of the Mozilla's internal workings) is practically non-existant, so
I'm left to trial and error on most of this)

Comment 5

[Brendan Eich [:brendan]]

Hannibal, what happens if there's no dump, just an empty loop?  Does XR bloat
and swap?  How about if you dump ever (i & 15) == 0 times through the loop?  How
about (i & 255) == 0?  If the bloat and thrash scale down with greater masks, it
seems dump is leaking.

Whether that could also be corrupting the heap, leading to assertions, I don't
know.  A script's execution should not affect how it is deserialized before it
is executed, or saved in the FastLoad file after being compiled but *before*
being executed.  So this smells like heap corruption.

/be

Comment 6

[:Gijs (back August 25; he/him)]

Memory usage varies between 20 and 25 MB when dumping (all) -  ((i & 65535) ==
0) times, while swap space stays constant at about 169MB when getting the first
warning dialog about the readsegments underflow error.
An empty loop (or a loop just doing: foo="foo";) also produces these assertions.

I am wondering if I should have marked this bug Platform/OS All/All; Can anyone
confirm this kind of behaviour on any other Platform/OS ?

The bug now seems to just be <sometimes> reproducable. If I try (re-)starting
the app 1-3 times, I get the assertions, and any subsequent tries after getting
assertions a first time will produce them again and again on each restart until
I change one of the files. It seems something is 'triggering' here, but I can't
find out what.
When ignoring the assertions, stopping the loop when the dialog comes up
("Unresponsive script..."), and re-clicking the "Submit" button, the code
executes without problems. Restarting after that always has the assertions
appear again.

Comment 7

[:Gijs (back August 25; he/him)]

I'm totally marking this WFM because I haven't seen this in ages and I haven't got the energy or cycles to reinstall w2k on my old box and start re-testing this. And well, after two years... :-)

Comment 8

[:Gijs (back August 25; he/him)]

I'm totally marking this WFM because I haven't seen this in ages and I haven't got the energy or cycles to reinstall w2k on my old box and start re-testing this. And well, after two years... :-)