https://bugs.kde.org/show_bug.cgi?id=395991
Bug ID: 395991
Summary: wine's unit tests enter a signal delivery loop under
valgrind on armv7l when SIGSEGV is used
Product: valgrind
Version: 3.14 SVN
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: austinengl...@gmail.com
Target Milestone: ---
This affects several tests on armv7l (arm64 and amd64 are NOT affected). The
list of affected tests so far:
dlls/comctl32/tests/imagelist.ok
dlls/comctl32/tests/treeview.ok
dlls/crypt32/tests/encode.ok
dlls/d3d8/tests/visual.ok
dlls/d3d9/tests/d3d9ex.ok
dlls/d3d10core/tests/device.ok
dlls/d3d11/tests/d3d11.ok
dlls/imm32/tests/imm32.ok
dlls/kernel32/tests/file.ok
dlls/kernel32/tests/heap.ok
dlls/kernel32/tests/thread.ok
dlls/kernel32/tests/virtual.ok
dlls/msacm32/tests/msacm.ok
dlls/msvcp90/tests/misc.ok
dlls/ntdll/tests/file.ok
dlls/ntdll/tests/time.ok
dlls/oleaut32/tests/safearray.ok
dlls/oleaut32/tests/tmarshal.ok
dlls/ws2_32/tests/sock.ok
I ran with --trace-signals=yes, which showed an infinite loop. E.g., for
dlls/kernel32/tests/heap, I got:
--7171-- sync signal handler: signal=11, si_code=1, EIP=0x546a784,
eip=0x687bbd4c, from kernel
--7171-- SIGSEGV: si_code=1 faultaddr=0xdeadbeed tid=1 ESP=0x5affb00
seg=0xbebf7000-0xfffeffff
--7171-- delivering signal 11 (SIGSEGV):1 to thread 1
--7171-- push_signal_frame (thread 1): signal 11
==7171== at 0x546A784: GlobalFree (heap.c:762)
==7171== by 0x5854AA3: test_heap (heap.c:220)
==7171== by 0x58560F3: func_heap (heap.c:1233)
==7171== by 0x57EE75F: main (test.h:615)
--7171-- VG_(sigframe_create): continuing in handler with PC=0x4fc627c
--7171-- vg_pop_signal_frame (thread 1): isRT=1 valid magic; PC=0x546a784
endlessly.
Speaking with Julian about it, armv7l may need some extra work that's already
done for arm64. I need to track down some extra info for him, first:
======================
So the program takes a segfault at 0x546A784 which is GlobalFree (heap.c:762),
runs the handler, which returns (unusual for a segfault handler), and it then
restarts the faulting insn 0x546A784, so it continues indefinitely.
Can you dig into this a bit further, to verify what's going on? I'd prefer
to be a bit more sure about it before hacking up a patch. In particular:
(1) do you expect there to be a segfault raised at heap.c:762 ?
(2) can you identify the fault handler being run? How is the program
supposed to make forward progress after the handler returns? Does
it modify the PC in the mcontext, or is there something else going on?
If you can find the handler, can you give me a pointer to it?
Number (2) is really the most important.
======================
I'm travelling, so that will likely be next week. I wanted to a have a bug
filed that I could share with wine guys in the meantime, though ;)
--
You are receiving this mail because:
You are watching all bug changes.
