642199 - Disable the Windows crash dialog in JS test binaries

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Armen [:armenzg]]

Attachment: [screenshot] jsapi-tests.exe stopped working

I am trying to bring Windows 64-bit builds to production but the dependent builds are failing on "make -k check".

I have disabled the JIT debugger by following theses instructions [1] & [2] and taking these steps [3].

It crashes with jsapi-tests.exe and it prevents the process from continuing (see screenshot) since we have to close the crashing dialog that appears.

I will have to disable the "make -k check" step for Win64 builds so the builds won't hang until we fix this.
This is important to fix so we can full coverage for Windows 64-bit.

[1] http://msdn.microsoft.com/en-us/library/5hs4b7a6.aspx#bkmk_enabling
[2] http://msdn.microsoft.com/en-us/library/2ac5yxx6%28v=VS.90%29.aspx
[3]
 In the Registry Editor window, locate and delete the follow registry keys:
 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger

Comment 1

[Jeff Walden [:Waldo]]

We should figure out the hang, not hack around this.  (Although to be sure, you're probably still going to want a way to forcibly discontinue a test that hangs like this.)  What are the steps to produce a build which will hang?  I have a Win7 64-bit box and can debug if you can tell me what to do beyond just a standard Firefox mozconfig to get this.

Comment 2

[Armen [:armenzg]]

Here is the mozconfig used:
http://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla2/win64/mozilla-central/nightly/mozconfig

Here is a piece of code that ted pointed out to me:
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3981

Thanks!

Comment 3

[David Mandelin [:dmandelin]]

The JS engine already has a feature to disable just-in-time debugging. Code is here, in js.cpp:

        const char *crash_option = getenv("XRE_NO_WINDOWS_CRASH_DIALOG");
        if (crash_option && strncmp(crash_option, "1", 1)) {
            DWORD oldmode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
            SetErrorMode(oldmode | SEM_NOGPFAULTERRORBOX);
        }

If that doesn't work, you can file a bug for it.

Comment 4

[Armen [:armenzg]]

I have been able to disable it on my side by doing this:
> When one of the tests run by "make -k check" crashes it reports a crash dialog
> saying "program.exe stoppped working" which can be disabled by doing the
> following:
> * gpedit.msc
> * Computer configuration -> Administrative Templates
> * Windows Components -> Windows Error Reporting
> * Set "Prevent display of the user interface for critical errors" to Enabled 

I will run it through buildbot and see if it works.
If it does I will remove the dependency and you can decide what to do with this bug.

Comment 5

[Jeff Walden [:Waldo]]

It's a stack overflow trying to mark stuff.  RecursionTooDeep doesn't happen because the stack limit in the JSTracer is 0, because |cx->stackLimit == 0|.  So it looks like we need a JS_SetNativeStackQuota(cx, ???) in JSAPITest::createContext.  Anyone willing to say anything about what that quota should be?

(It looks like we hit this due to differences in native stack size on various platforms.  If I bump up the loop limit with another zero I can hit this on Linux 64-bit as well.)

Comment 6

[Makoto Kato [:m_kato]]

(In reply to comment #5)
> It's a stack overflow trying to mark stuff.  RecursionTooDeep doesn't happen
> because the stack limit in the JSTracer is 0, because |cx->stackLimit == 0|. 
> So it looks like we need a JS_SetNativeStackQuota(cx, ???) in
> JSAPITest::createContext.  Anyone willing to say anything about what that quota
> should be?
> 
> (It looks like we hit this due to differences in native stack size on various
> platforms.  If I bump up the loop limit with another zero I can hit this on
> Linux 64-bit as well.)

see bug 582910.  We need -STACK:2097152 for win64

Comment 7

[Armen [:armenzg]]

Disabling the Windows Error Reporting allowed us to finish the whole run.

This is the latest run's log:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1300308096.1300321956.11130.gz

The error is this:
make[2]: Leaving directory `/e/builds/moz2_slave/cen-win64/build/obj-firefox/js/src/jsapi-tests'
d:/mozilla-build/python/python2.6.exe /e/builds/moz2_slave/cen-win64/build/js/src/config/check-sync-dirs.py /e/builds/moz2_slave/cen-win64/build/js/src/config /e/builds/moz2_slave/cen-win64/build/config
make[2]: *** [check] Error 253
make[1]: *** [check] Error 2

Comment 8

[(not currently active) Ted Mielczarek]

Well, yes, the test is still crashing, so it fails, it's just not popping up a dialog anymore. The crash needs to be fixed before the tests will pass.

Comment 9

[Jeff Walden [:Waldo]]

(In reply to comment #6)
> see bug 582910.  We need -STACK:2097152 for win64

I'm confused.  If the problem is cx->stackLimit is 0 because it's never getting set properly, how would changing compiler/linker/mumble flags affect that?

Comment 10

[Jeff Walden [:Waldo]]

Moreover, how would changing Windows flags fix the same problem on Linux if I bump up the loop limit?

Comment 11

[Makoto Kato [:m_kato]]

(In reply to comment #9)
> (In reply to comment #6)
> > see bug 582910.  We need -STACK:2097152 for win64
> 
> I'm confused.  If the problem is cx->stackLimit is 0 because it's never getting
> set properly, how would changing compiler/linker/mumble flags affect that?

As long as I test, this test needs 2.2MB stack on Win64 build.  You can modify it by editbin.exe.


(In reply to comment #10)
> Moreover, how would changing Windows flags fix the same problem on Linux if I
> bump up the loop limit?

On Linux, default is 8MB.  So this won't occur.

Comment 12

[Jeff Walden [:Waldo]]

Attachment: Patch, and change the test to fail on more than just win64 without the patch

The test change alone causes this test to fail on Linux64 debug for me.  With the tests.h change, it passes.  I'd be very surprised if this didn't also fix Win64.

Comment 13

[Jeff Walden [:Waldo]]

http://hg.mozilla.org/tracemonkey/rev/af2445263a46

Comment 14

[Chris Leary [:cdleary] (not checking bugmail)]

http://hg.mozilla.org/mozilla-central/rev/af2445263a46

Comment 15

[(not currently active) Ted Mielczarek]

Can you re-summarize this bug to be about what you actually fixed?