Closed
Bug 280813
Opened 19 years ago
Closed 19 years ago
MOZJS.DLL crashes with SYS3183
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mozilla, Assigned: mkaply)
Details
(Keywords: fixed-aviary1.0.5)
Attachments
(2 files, 1 obsolete file)
499 bytes,
patch
|
Details | Diff | Splinter Review | |
541 bytes,
patch
|
Details | Diff | Splinter Review |
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.
Comment 1•19 years ago
|
||
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?
Assignee | ||
Comment 2•19 years ago
|
||
If you want to force this error, just remove our new floating point patch completely. I'm pretty sure it happened all the time.
Comment 3•19 years ago
|
||
(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...
Comment 4•19 years ago
|
||
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 .
Comment 5•19 years ago
|
||
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.
Comment 6•19 years ago
|
||
Comment 7•19 years ago
|
||
Comment 8•19 years ago
|
||
Ooops... the first attempt had a reference to a non-existent file
Attachment #177054 -
Attachment is obsolete: true
Assignee | ||
Comment 9•19 years ago
|
||
r=mkaply. Fix checked in. NICE WORK!
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Keywords: fixed-aviary1.0.5
You need to log in
before you can comment on or make changes to this bug.
Description
•