Closed Bug 280813 Opened 19 years ago Closed 19 years ago

MOZJS.DLL crashes with SYS3183

Categories

(SeaMonkey :: General, defect)

x86
OS/2
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mozilla, Assigned: mkaply)

Details

(Keywords: fixed-aviary1.0.5)

Attachments

(2 files, 1 obsolete file)

A lot of users report SYS3183 crashes of various Mozilla products in MOZJS.DLL.
This seems to be caused by trashing of the FPU control word when some (buggy)
DLLs are loaded. A fix for this issue has already been attempted in bug 224487
but it seems to have been unsuccessful.

However, recently Ilya Zakharevich and Rich Walsh have been discussing the
situation in netscape.public.mozilla.os2 and comp.os.os2.bugs. It seems that the
problems can be overcome by the following:

1. Reset the FP flags to something reasonable "in the OS-specific initialization
routine" -- I guess that means early in main() -- by calling
   _control87(MCW_EM, MCW_EM);
This overcomes problems of buggy DLLs loaded at start time.

2. Save and reset the FP flags when loading more (perhaps buggy) DLLs
explicitely via DosLoadModule:
   unsigned fpflag = _control87(0,0);
   DosLoadModule(...);
   control87(fpflag, MCW_EM);

3. Save and reset the FP flags when implicitely loading new (buggy) DLLs. This
seems to occur when calling WinCreateMsgQueue() (or WinStartPaint() which is not
used in Mozilla) and posting the first message to a queue. Similar workaround as
for item 2. will apply here, but details are still worked out in the newsgroup.

After these 3 fixes have been done, the previous workaround from bug 224487 can
be reversed as it should not be necessary any more and does not seem to work
well anyway.
While I'd be happy to help implement a new fix if needed, I'd sure love to know
why an exception handler installed in xre_main() fails to catch these
exceptions.  Is there any known way to force this error?
If you want to force this error, just remove our new floating point patch
completely. I'm pretty sure it happened all the time.
(In reply to comment #2)
> If you want to force this error, just remove our new floating point patch
> completely. I'm pretty sure it happened all the time.

It would be pretty hard to figure out why that patch sometimes fails if I remove
it. :-)  I'd like to force the error, particularly during startup, then
determine why it isn't handled.  I suppose DosRaiseException() would work...
I now got this error upon initial startup of Firefox compiled from the trunk:
 
Process terminated by SIGFPE - pid=0x4efa - tid=0x01 - E:\APP\MOK\FIREFOX.EXE
.
This problem occurs because the ScopedFPHandler class which is supposed to set
the floating point exception handler is never instantiated.  The attached
patches for the XRE and XPFE versions of nsAppRunner.cpp fixes this.
Attached patch XRE FPE patch (obsolete) — Splinter Review
Attached patch XPFE FPE patchSplinter Review
Attached patch XRE FPE PatchSplinter Review
Ooops...  the first attempt had a reference to a non-existent file
Attachment #177054 - Attachment is obsolete: true
r=mkaply.

Fix checked in.

NICE WORK!
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: