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.

Reply via email to