Closed Bug 642199 Opened 9 years ago Closed 9 years ago

Disable the Windows crash dialog in JS test binaries

Categories

(Core :: JavaScript Engine, defect, critical)

x86_64
Windows Server 2008
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: armenzg, Assigned: Waldo)

References

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(2 files)

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
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.
Assignee: general → jwalden+bmo
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.
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.
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.)
(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
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
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.
(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?
Moreover, how would changing Windows flags fix the same problem on Linux if I bump up the loop limit?
(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.
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.
Attachment #520336 - Flags: review?(wmccloskey)
Attachment #520336 - Flags: review?(wmccloskey) → review+
http://hg.mozilla.org/tracemonkey/rev/af2445263a46
Status: NEW → ASSIGNED
Whiteboard: fixed-in-tracemonkey
http://hg.mozilla.org/mozilla-central/rev/af2445263a46
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Can you re-summarize this bug to be about what you actually fixed?
You need to log in before you can comment on or make changes to this bug.