686919 - TI: sqlite.js gives incorrect behavior

Status: RESOLVED DUPLICATE of bug 687768

(Core :: JavaScript Engine, defect)

Description

[Alon Zakai (:azakai)]

Attachment: sqlite compiled to js

The attachment is SQLite compiled to JS. Running it with -m -j -p gives something like this:

'startup' : took 0 ms
create table : took 179 ms
25,000 inserts : took 2789 ms
[..more stuff..]

whereas with -m -n the result is

'startup' : took 0 ms
create table : took 3352 ms
SQL error on 1007: out of memory
uncaught exception: exit(1) called, at __exit(1)@/home/alon/Documents/sqlite.js:2838
_exit(1)@/home/alon/Documents/sqlite.js:2840
_main(1,1091252,0)@/home/alon/Documents/sqlite.js:32359
callMain([object Array])@/home/alon/Documents/sqlite.js:217698
run()@/home/alon/Documents/sqlite.js:219046
@/home/alon/Documents/sqlite.js:219082

So 'create table' takes 19X more time with TI, and in addition we get an incorrect failure afterwards.

Note that the failure says "out of memory", but that is an internal SQLite error message (which should not have occurred here), not an actual out of memory problem in the JS engine.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Requesting tracking for the correctness regression....

Comment 2

[Jan de Mooij [:jandem]]

I considered reducing this, but it will take a long time. This works for me with a JM build from about a month ago, so bisecting (using nightly shell builds?) may be faster.

Comment 3

[Jan de Mooij [:jandem]]

Regression from bug 670493; I will have a look tomorrow.

Comment 4

[Jan de Mooij [:jandem]]

OK so at some point we recompile, inline several functions and then it fails. Hard to debug 219,076 lines of JS so I'm going to reduce this first. Atm it's down to 159k lines.

Comment 5

[Alon Zakai (:azakai)]

I filed a followup bug for the speed issue, bug 687127. Turns out that running closure compiler avoids the correctness issue, but the slowdown remains. So focusing this bug on correctness and the followup on speed.

Comment 6

[Brendan Eich [:brendan]]

Can we reduce using lithium or delta or something automatic?

http://delta.tigris.org/using_delta.html

/be

Comment 7

[Jan de Mooij [:jandem]]

(In reply to Brendan Eich [:brendan] from comment #6)
> Can we reduce using lithium or delta or something automatic?

Yeah, I'm already using lithium and delta. Lithium in this case because it seems to be faster for very large files and its console output is cleaner and easier to understand. Takes a long time for large files like this, but that's fine as it just runs in the background while I spend my time doing other stuff :)

Comment 8

[Jeff Walden [:Waldo]]

We're really using JS to (wrongly, but still) emulate OOM in C here?  "The hearts of men, moreover, are full of evil and there is madness in their hearts while they live."

;-)

Comment 9

[Jan de Mooij [:jandem]]

Attachment: Reduced

Down to 1500 lines using Lithium and my Reflect.parse-based reducer. Gives different error message with -n -m -a. Not finished yet.

Comment 10

[Jan de Mooij [:jandem]]

Duplicate of bug 687768. sqlite.js no longer fails on m-c tip but the patch in bug 687768 fixes the reduced testcase. I also verified that applying the patch to an older m-c revision, where I can still reproduce the problem, fixes sqlite.js

Comment 11

[LegNeato]

Tracking the original for Fx9, removing the flag from this bug.