diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-06-30 12:24:58 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-06-30 12:27:06 +0000 |
| commit | 33606b41d35115f887ea688b1a16f2ff85bf2fe4 (patch) | |
| tree | 406b2c7b19a087ba437c68f3dbf0b589fa1d6150 /results/scraper/launchpad-without-comments/1913913 | |
| parent | adedf8771bc4de3113041ca21bd4d0d1c0014b6a (diff) | |
| download | emulator-bug-study-33606b41d35115f887ea688b1a16f2ff85bf2fe4.tar.gz emulator-bug-study-33606b41d35115f887ea688b1a16f2ff85bf2fe4.zip | |
add launchpad bug reports without comments
Diffstat (limited to 'results/scraper/launchpad-without-comments/1913913')
| -rw-r--r-- | results/scraper/launchpad-without-comments/1913913 | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1913913 b/results/scraper/launchpad-without-comments/1913913 new file mode 100644 index 00000000..bc45885c --- /dev/null +++ b/results/scraper/launchpad-without-comments/1913913 @@ -0,0 +1,18 @@ +i386-linux-user returns -1 in sigcontext->trapno + +QEMU development version, git commit 74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in 5.2.0 generally. + +Certain 16-bit windows programs crash WINE under QEMU linux-user with: + +0084:err:seh:segv_handler Got unexpected trap -1 +wine: Unhandled illegal instruction at address 00006D65 (thread 0084), starting debugger... + +They run correctly on native i386. + +Upon further inspection,it becomes clear these programs are failing at addresses where they are making DOS calls (int 21h ie CD 21 for instance). + +It is also clear that WINE is expecting an exception/signal at this point, to patch in the actual int21h handling code inside WINE. + +However, wine uses sigcontext output extensively to do its structured exception handling. sigcontext->trapno being set to -1 seems to confuse it, causing it to treat the exception as an actual unhandled error. + +I do not know if exception_index is being left at -1 due to the case of privileged instructions being executed in 16-bit ldts not being handled specifically, or if there is some other illegal instruction case causing this. \ No newline at end of file |