diff options
Diffstat (limited to 'results/classifier/zero-shot/105/instruction/1913913')
| -rw-r--r-- | results/classifier/zero-shot/105/instruction/1913913 | 84 |
1 files changed, 84 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/105/instruction/1913913 b/results/classifier/zero-shot/105/instruction/1913913 new file mode 100644 index 000000000..1ca71cfd1 --- /dev/null +++ b/results/classifier/zero-shot/105/instruction/1913913 @@ -0,0 +1,84 @@ +instruction: 0.870 +other: 0.862 +device: 0.756 +graphic: 0.695 +socket: 0.665 +network: 0.653 +semantic: 0.633 +mistranslation: 0.573 +vnc: 0.515 +boot: 0.487 +assembly: 0.476 +KVM: 0.330 + +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. + +I have identified the core issue: + +Synchronous exceptions/traps in linux-user/i386/cpu_loop.c are handled as a return value from cpu_exec(). +cpu_exec() resets exception_index to -1 in cpu_handle_exception() + +This means that queue_signal() (called from gen_signal() in the cpu loop) does not store the actual CPU trap value anywhere. + +If we abuse env->exception_nr to store the trapnr, and retrieve it from there in setup_sigcontext() in linux-user/i386/signal.c instead of using exception_index (which will be set to -1 for all synchronous excptions). + +The main issue is if this breaks asynchronous signals, and under what conditions exception_nr should be set to -1. + + + + + + + + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + |