diff options
Diffstat (limited to 'results/classifier/zero-shot/118/permissions/1914021')
| -rw-r--r-- | results/classifier/zero-shot/118/permissions/1914021 | 135 |
1 files changed, 135 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/permissions/1914021 b/results/classifier/zero-shot/118/permissions/1914021 new file mode 100644 index 00000000..a34b9326 --- /dev/null +++ b/results/classifier/zero-shot/118/permissions/1914021 @@ -0,0 +1,135 @@ +permissions: 0.902 +performance: 0.867 +user-level: 0.864 +debug: 0.843 +peripherals: 0.834 +semantic: 0.828 +risc-v: 0.827 +device: 0.822 +hypervisor: 0.811 +graphic: 0.800 +assembly: 0.800 +arm: 0.798 +virtual: 0.797 +architecture: 0.793 +register: 0.788 +mistranslation: 0.781 +PID: 0.770 +TCG: 0.743 +ppc: 0.710 +boot: 0.696 +vnc: 0.691 +network: 0.681 +kernel: 0.672 +files: 0.665 +socket: 0.662 +x86: 0.646 +i386: 0.643 +VMM: 0.630 +KVM: 0.549 + +qemu: uncaught target signal 4 (Illegal instruction) but gdb remote-debug exited normally + +I'm getting Illegal instruction (core dumped) when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +readelf -h a.out_err +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0x8220 + Start of program headers: 52 (bytes into file) + Start of section headers: 54228 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 3 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 15 + +qemu-arm version 4.0.0 + + + +QEMU 4.0 is quite old now -- does this reproduce with a more recent QEMU? + + +yes, it reproduced on QEMU 5.0.0. + +For me, with current head-of-git QEMU, the program crashes with a SIGSEGV very early in execution, because: + +0x00008260: e59f30f0 ldr r3, [pc, #0xf0] + +loads 0 into r3, and then + +0x00008270: e1a0d003 mov sp, r3 + +sets sp to 0, and then + +0x000087b0: e92d4030 push {r4, r5, lr} + +tries to write to addres 0, which causes a SEGV. + +This happens whether using the gdbstub or not. + + + 0x00008260 <+64>: ldr r3, [pc, #240] + 0x00008264 <+68>: cmp r1, #0 +=> 0x00008268 <+72>: beq 0x8270 + 0x0000826c <+76>: mov r3, r1 + 0x00008270 <+80>: mov sp, r3 + +(gdb) p/x $r1 +$2 = 0xfffef690 + +But r1 is not zero when using Gdb remote-debug, so it will enter + 0x0000826c <+76>: mov r3, r1 + +QEMU 5.0.0. +GNU gdb (GDB; SUSE Linux Enterprise 12) 8.0.1 + + +Oh, your code is trying to use the SYS_HEAPINFO semihosting call to figure out where the stack and heap are. This is generally a bad idea if you're using QEMU user-mode emulation: you start with a perfectly good stack pointer and you should just use the usual Linux syscalls to allocate heap if you need it. + +I have no idea where your code is getting r1 from -- it's too painful to try to reverse-engineer it from the binary. I can't repro any difference between with-gdb and without -- for me with current QEMU r1 is 0 whether running with the gdb stub or not. + + +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.] + |