Never hard-exit DOSBox when an x87 FPU stack overflow is detected#2564
Merged
Never hard-exit DOSBox when an x87 FPU stack overflow is detected#2564
Conversation
Member
Author
|
@joncampbell123 Maybe you're interested in this. |
Contributor
|
👍 I made a similar change in DOSBox-X a long time ago when some demos would trigger the hard exit despite running perfectly fine without such a hard exit. Though it was done differently. |
Member
Author
Nice, looks like a safe change then. |
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2546
There's no good reason to take such a drastic measure as to hard exit DOSBox when an FPU stack overflow is detected. Real hardware does not do that; the FPU stack over/underflow just happens and sets the overflow bit that the application can optionally inspect and recover from it, etc.
This can prevent programs that cause x87 stack over/underflows but recover from them later from running. I've run into one such example, see linked ticket with repro pack.