Last Comment Bug 526299 - Spidermonkey regression causes treehydra trunk to fail 6 tests
: Spidermonkey regression causes treehydra trunk to fail 6 tests
Status: NEW
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: David Anderson [:dvander]
:
Mentors:
: 541554 (view as bug list)
Depends on:
Blocks: 437502 489834 569973
  Show dependency treegraph
 
Reported: 2009-11-03 11:56 PST by David Humphrey (:humph)
Modified: 2010-06-03 11:51 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Added check to see if property is defined. This results in a succesful build (535 bytes, patch)
2010-01-23 13:01 PST, martinbijl
no flags Details | Diff | Review

Description David Humphrey (:humph) 2009-11-03 11:56:03 PST
Today I'm trying to get callgraph stuff hooked into dxr, and I'm unable to get a working treehydra.  I've updated tried updating just dehydra, then I updated gcc w/plugins using the new stuff in the patch queue, and it doesn't matter.  Running make check_treehydra fails like this:

Test Failure: 
    Test command: /var/www/html/dxr/tools/gcc-dehydra/installed/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus -quiet -fplugin=../gcc_treehydra.so -o /dev/null -fplugin-arg=test_locks_bad3.js locks_bad3.cc
    Failure msg: Expected 'locks_bad3.cc:10: error: precondition not met' in error output; not found. stderr:../libs/treehydra.js:12: JS Exception: No case_val in this lazy object
:0:     #0: Error("No case_val in this lazy object")
../libs/treehydra.js:12:        #1: unhandledLazyProperty("case_val")
../libs/unstable/esp.js:481:    #2: ()
./esp_lock.js:41:       #3: process_tree([object GCCNode])

Test Failure: 
    Test command: /var/www/html/dxr/tools/gcc-dehydra/installed/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus -quiet -fplugin=../gcc_treehydra.so -o /dev/null -fplugin-arg=test_locks_good.js locks_good.cc
    Failure msg: Expected no error output, got error output :../libs/treehydra.js:12: JS Exception: No case_val in this lazy object
:0:     #0: Error("No case_val in this lazy object")
../libs/treehydra.js:12:        #1: unhandledLazyProperty("case_val")
../libs/unstable/esp.js:481:    #2: ()
./esp_lock.js:41:       #3: process_tree([object GCCNode])

Test Failure: 
    Test command: /var/www/html/dxr/tools/gcc-dehydra/installed/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus -quiet -fplugin=../gcc_treehydra.so -o /dev/null -fplugin-arg=test_locks_good2.js locks_good2.cc
    Failure msg: Expected no error output, got error output :../libs/treehydra.js:12: JS Exception: No case_val in this lazy object
:0:     #0: Error("No case_val in this lazy object")
../libs/treehydra.js:12:        #1: unhandledLazyProperty("case_val")
../libs/unstable/esp.js:481:    #2: ()
./esp_lock.js:41:       #3: process_tree([object GCCNode])

Test Failure: 
    Test command: /var/www/html/dxr/tools/gcc-dehydra/installed/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus -quiet -fplugin=../gcc_treehydra.so -o /dev/null -fplugin-arg=test_locks_bad4.js locks_bad4.cc
    Failure msg: Expected 'locks_bad4.cc:13: error: precondition not met' in error output; not found. stderr:../libs/treehydra.js:12: JS Exception: No case_val in this lazy object
:0:     #0: Error("No case_val in this lazy object")
../libs/treehydra.js:12:        #1: unhandledLazyProperty("case_val")
../libs/unstable/esp.js:481:    #2: ()
./esp_lock.js:41:       #3: process_tree([object GCCNode])

Test Failure: 
    Test command: /var/www/html/dxr/tools/gcc-dehydra/installed/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus -quiet -fplugin=../gcc_treehydra.so -o /dev/null -fplugin-arg=test_locks_bad2.js locks_bad2.cc
    Failure msg: Expected 'locks_bad2.cc:12: error: precondition not met' in error output; not found. stderr:../libs/treehydra.js:12: JS Exception: No case_val in this lazy object
:0:     #0: Error("No case_val in this lazy object")
../libs/treehydra.js:12:        #1: unhandledLazyProperty("case_val")
../libs/unstable/esp.js:481:    #2: ()
./esp_lock.js:41:       #3: process_tree([object GCCNode])

Test Failure: 
    Test command: /var/www/html/dxr/tools/gcc-dehydra/installed/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus -quiet -fplugin=../gcc_treehydra.so -o /dev/null -fplugin-arg=test_locks_bad1.js locks_bad1.cc
    Failure msg: Expected 'locks_bad1.cc:11: error: precondition not met' in error output; not found. stderr:../libs/treehydra.js:12: JS Exception: No case_val in this lazy object
:0:     #0: Error("No case_val in this lazy object")
../libs/treehydra.js:12:        #1: unhandledLazyProperty("case_val")
../libs/unstable/esp.js:481:    #2: ()
./esp_lock.js:41:       #3: process_tree([object GCCNode])


Unit Test Suite Summary:
     32 passed
      6 failed
      0 error(s)
make[1]: *** [check_treehydra] Error 1
make[1]: Leaving directory `/var/www/html/dxr/tools/gcc-dehydra/dehydra/test'
make: *** [check] Error 2
Comment 1 David Humphrey (:humph) 2009-11-03 14:31:40 PST
Rebuilt *everything* and no difference.  I'm on a 64-bit Fedora box, if that matters.
Comment 2 David Humphrey (:humph) 2009-11-03 17:24:07 PST
Regression window is between:

http://hg.mozilla.org/mozilla-central/rev/89e665eb9944 (passes all tests)
http://hg.mozilla.org/mozilla-central/rev/d04601f54db5 (6 tests fail)

Changesets in between these don't build.
Comment 3 David Mandelin [:dmandelin] 2009-11-04 17:37:03 PST
Looks like tracing recursion broke it.
Comment 4 Jason Orendorff [:jorendorff] 2009-11-10 12:02:39 PST
Taras, any idea at all what circumstances lead to these failures? A minimal jsapi-test makes this kind of thing much easier to fix.
Comment 5 (dormant account) 2009-11-10 12:06:00 PST
(In reply to comment #4)
> Taras, any idea at all what circumstances lead to these failures? A minimal
> jsapi-test makes this kind of thing much easier to fix.

The bugs haven't been related so far. I think they are caused by the the fact that we have a very large amount of js code and we embed spidermonkey slightly differently from firefox.
Comment 6 (dormant account) 2009-11-25 12:28:58 PST
Disregard comment 5, I thought I was replying to bug 527744.

This testcase would be pretty hard to reduce as it involves a native resolve func code and a pile of js code. At least one spidermonkey dev is very familiar with Dehydra code in question so it shouldn't be too much of a stumbling block to debug this in dehydra.
Comment 7 Mike Shaver (:shaver -- probably not reading bugmail closely) 2009-11-25 12:32:23 PST
Yeah, a JSAPI test can provide a native resolve func and you can copy the JS code in place.  I'm sure that some of the JS developers are familiar with dehydra, but not the one to whom the bug was assigned, so you can help them help you by reducing (or even telling how to reproduce with dehydra, starting from "I have never tried to use dehydra before", as a start).
Comment 8 (dormant account) 2009-11-25 13:03:22 PST
To reproduce this, follow Dehydra installation instructions on https://developer.mozilla.org/En/Dehydra/Installing_Dehydra

After compiling dehydra, run make check_treehydra to see the failures. This will output the exact command that is failing so one can run it through gdb. I'm happy to help with any questions in #static

If setting up dehydra build env is too troublesome, we arrange ssh access to a mozilla machine with everything setup & ready to fail(but that is likely more time consuming).

As I said before, a testcase would be difficult to produce(ie weeks) without a better understanding of spidermonkey internals that are failing. It doesn't fail on every native resolve call, seems to require a certain codepath.
Comment 9 (dormant account) 2010-01-14 15:34:13 PST
As of my last comment, using 1.9.2 spidermonkey was a reasonable workaround while the trunk fixed. 

Now the bug is also in 1.9.2 spidermonkey and is likely to get released, meaning that Treehydra will not function with neither the mozilla's bleeding edge spidermonkeys, nor distribution ones.
Comment 10 (dormant account) 2010-01-14 17:44:06 PST
(In reply to comment #9)
> As of my last comment, using 1.9.2 spidermonkey was a reasonable workaround
> while the trunk fixed. 

Correction, I got my build trees swapped, trunk is still broken and 192 is ok.
Comment 11 Joshua Cranmer [:jcranmer] 2010-01-23 07:04:38 PST
*** Bug 541554 has been marked as a duplicate of this bug. ***
Comment 12 martinbijl 2010-01-23 13:01:58 PST
Created attachment 423169 [details] [diff] [review]
Added check to see if property is defined. This results in a succesful build

Note You need to log in before you can comment on or make changes to this bug.