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.