[valgrind] [Bug 477044] Valgrind complains about wld_mmap being in Text segment
https://bugs.kde.org/show_bug.cgi?id=477044 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 461855] (wine xsavec64) vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xA1 0xC0 0x0 0x0 0x0 0x48 0xF
https://bugs.kde.org/show_bug.cgi?id=461855 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com --- Comment #3 from Austin English --- (In reply to John Reiser from comment #2) > Next, the supposedly-reproducible test case "valgrind --trace-children=yes > wine64 a.out.so > temp.out 2>&1" runs wine64, which requires an actual > "install" of Microsoft Windows (probably version 10). This can be seen by ... > Because I don't have Windows installed, then most of the output from Wine does not depend on or use native Windows installations. It _can_ use native windows DLLs in some cases, but this example doesn't use that. The 'windows binaries' seen are provided by Wine itself (windows doesn't have any executables called 'wineboot.exe' ;)). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #10 from Austin English --- (In reply to Mark Wielaard from comment #8) > So I see both examples are for 32bit Debian packages (i386 and arm32). Is > this an 32bit only issue or are you seeing the same for 64bit packages? Just tried, I'm not seeing it with 64-bit (though I don't normally run wine's tests under 64-bit, so don't take that as 100% certain). (In reply to Mark Wielaard from comment #9) > commit 8b1961511c93962ea2a9b918af8e9c32e3c24d71 > Author: Balint Reczey > Date: Thu Nov 28 13:34:21 2019 +0100 > > Don't look for debug alt file in debug image if it is already found > > With dwz the .gnu_debuglink section may appear duplicated in the > debug file referenced originally in the .gnu_debuglink section. > > https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1848211 > > https://bugs.kde.org/show_bug.cgi?id=396656 > https://bugs.kde.org/show_bug.cgi?id=427969 > > Signed-off-by: Balint Reczey Thanks! This works for me on x86 (can't easily test arm at the moment, but will report back if there's a problem there). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #6 from Austin English --- (In reply to Mark Wielaard from comment #5) > Thanks for including the files, this is really odd the main ELF file has > both a .gnu_debuglink section and a .gnu_debugaltlink section, but no .debug > sections itself. The .debug file itself also has a .gnu_debugaltlink. > > (Sidenote, the .gnu_debugaltlink is absolute, instead of a relative path > from the .debug file, which makes it slightly harder to find unless you > replicate the fill file system layout.) > > This looks suspiciously like an Ubuntu bug: > https://bugs.kde.org/show_bug.cgi?id=396656 I'm running Debian, not Ubuntu, to be clear, but fair enough. Should I report this to Debian or should I gather some other information first? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #33 from Austin English --- To follow up, I misunderstood the scope of Remi's work. The patchset *does* work for DWARF symbols in PE binaries in modern wine (i.e., with wine having a mingw compiled ntdll). PDB support is a separate problem and should not stop the patches from going in. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #32 from Austin English --- Hi Remi, Using both wine patches: https://source.winehq.org/patches/data/196764 https://source.winehq.org/patches/data/196765 and valgrind patches: https://sourceforge.net/p/valgrind/mailman/message/37164939/ https://sourceforge.net/p/valgrind/mailman/message/37164938/ https://sourceforge.net/p/valgrind/mailman/message/37164940/ on top of wine-6.0-rc2 and valgrind-VALGRIND_3_15_0-405-g41504d33d, with llvm-mingw, I don't get symbols: ==8917== 2,048 bytes in 1 blocks are possibly lost in loss record 86 of 92 ==8917==at 0x7BC23550: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC2F91F: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC29921: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC2E1F7: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC2DC01: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x46E061E: start_main_thread (loader.c:1580) ==8917==by 0x46E061E: __wine_main (???:0) ==8917==by 0x7D001287: main (main.c:157) ==8917== compared to non pdb build: ==31534== 2,048 bytes in 1 blocks are possibly lost in loss record 100 of 108 ==31534==at 0x7BC51E61: RtlAllocateHeap (heap.c:261) ==31534==by 0x7BC625C3: init_load_order (loadorder.c:234) ==31534==by 0x7BC625C3: get_load_order (???:0) ==31534==by 0x7BC5DA27: load_dll (loader.c:2644) ==31534==by 0x7BC5FFD1: process_init (loader.c:4017) ==31534==by 0x7BC61D7B: __wine_set_unix_funcs (loader.c:4114) ==31534==by 0x46E061E: start_main_thread (loader.c:1580) ==31534==by 0x46E061E: __wine_main (???:0) ==31534==by 0x7D001287: main (main.c:157) ==31534== (that's dlls/avifil32/tests/api.c) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #4 from Austin English --- Created attachment 133681 --> https://bugs.kde.org/attachment.cgi?id=133681&action=edit armv7l library I also see this with 32-bit arm(v7l): --10058-- WARNING: Serious error when reading debug info --10058-- When reading debug info from /usr/lib/arm-linux-gnueabihf/libbrotlidec.so.1.0.9: --10058--debuginfo section duplicates a section in the main ELF file austin@arm7:~$ readelf -S /usr/lib/arm-linux-gnueabihf/libbrotlidec.so.1.0.9 There are 25 section headers, starting at offset 0x7208: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .note.gnu.bu[...] NOTE00f4 f4 24 00 A 0 0 4 [ 2] .gnu.hash GNU_HASH0118 000118 5c 04 A 3 0 4 [ 3] .dynsym DYNSYM 0174 000174 000210 10 A 4 3 4 [ 4] .dynstr STRTAB 0384 000384 0002fb 00 A 0 0 1 [ 5] .gnu.version VERSYM 0680 000680 42 02 A 3 0 2 [ 6] .gnu.version_rVERNEED 06c4 0006c4 40 00 A 4 2 4 [ 7] .rel.dyn REL 0704 000704 60 08 A 3 0 4 [ 8] .rel.plt REL 0764 000764 68 08 AI 3 18 4 [ 9] .init PROGBITS07cc 0007cc 0c 00 AX 0 0 4 [10] .plt PROGBITS07d8 0007d8 b0 04 AX 0 0 4 [11] .text PROGBITS0888 000888 004b10 00 AX 0 0 4 [12] .fini PROGBITS5398 005398 08 00 AX 0 0 4 [13] .rodata PROGBITS53a0 0053a0 001888 00 A 0 0 4 [14] .eh_frame PROGBITS6c28 006c28 04 00 A 0 0 4 [15] .init_array INIT_ARRAY 00016ef8 006ef8 04 04 WA 0 0 4 [16] .fini_array FINI_ARRAY 00016efc 006efc 04 04 WA 0 0 4 [17] .dynamic DYNAMIC 00016f00 006f00 000100 08 WA 4 0 4 [18] .got PROGBITS00017000 007000 64 04 WA 0 0 4 [19] .data PROGBITS00017064 007064 04 00 WA 0 0 4 [20] .bss NOBITS 00017068 007068 04 00 WA 0 0 1 [21] .ARM.attributes ARM_ATTRIBUTES 007068 31 00 0 0 1 [22] .gnu_debugaltlink PROGBITS 007099 4d 00 0 0 1 [23] .gnu_debuglinkPROGBITS 0070e8 34 00 0 0 4 [24] .shstrtab STRTAB 00711c ec 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), y (purecode), p (processor specific) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #3 from Austin English --- austin@debian-desktop ~/src/valgrind (master) $ readelf -S /usr/lib/i386-linux-gnu/libbrotlidec.so.1.0.9 There are 27 section headers, starting at offset 0xc1b0: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .note.gnu.bu[...] NOTE0154 000154 24 00 A 0 0 4 [ 2] .gnu.hash GNU_HASH0178 000178 5c 04 A 3 0 4 [ 3] .dynsym DYNSYM 01d4 0001d4 0001e0 10 A 4 1 4 [ 4] .dynstr STRTAB 03b4 0003b4 0002e6 00 A 0 0 1 [ 5] .gnu.version VERSYM 069a 00069a 3c 02 A 3 0 2 [ 6] .gnu.version_rVERNEED 06d8 0006d8 40 00 A 4 1 4 [ 7] .rel.dyn REL 0718 000718 58 08 A 3 0 4 [ 8] .rel.plt REL 0770 000770 58 08 AI 3 21 4 [ 9] .init PROGBITS1000 001000 20 00 AX 0 0 4 [10] .plt PROGBITS1020 001020 c0 04 AX 0 0 16 [11] .plt.got PROGBITS10e0 0010e0 08 08 AX 0 0 8 [12] .text PROGBITS10f0 0010f0 0073f4 00 AX 0 0 16 [13] .fini PROGBITS84e4 0084e4 14 00 AX 0 0 4 [14] .rodata PROGBITS9000 009000 001b00 00 A 0 0 32 [15] .eh_frame_hdr PROGBITSab00 00ab00 0001bc 00 A 0 0 4 [16] .eh_frame PROGBITSacbc 00acbc 000e94 00 A 0 0 4 [17] .init_array INIT_ARRAY cee0 00bee0 04 04 WA 0 0 4 [18] .fini_array FINI_ARRAY cee4 00bee4 04 04 WA 0 0 4 [19] .dynamic DYNAMIC cee8 00bee8 f8 08 WA 4 0 4 [20] .got PROGBITScfe0 00bfe0 20 04 WA 0 0 4 [21] .got.plt PROGBITSd000 00c000 38 04 WA 0 0 4 [22] .data PROGBITSd038 00c038 04 00 WA 0 0 4 [23] .bss NOBITS d03c 00c03c 04 00 WA 0 0 1 [24] .gnu_debugaltlink PROGBITS 00c03c 48 00 0 0 1 [25] .gnu_debuglinkPROGBITS 00c084 34 00 0 0 4 [26] .shstrtab STRTAB 00c0b8 f7 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), p (processor specific) Note that this seems to occur for all/most 32-bit libraries (I see 133 different .so files referenced so far when running the full wine test suite). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #2 from Austin English --- Created attachment 132556 --> https://bugs.kde.org/attachment.cgi?id=132556&action=edit .debug files There are a few .debug files listed for this package, so I included all of them. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 Austin English changed: What|Removed |Added Attachment #132554|.so file|libbrotlidec.so.1.0.9 description|| -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #1 from Austin English --- Created attachment 132554 --> https://bugs.kde.org/attachment.cgi?id=132554&action=edit .so file -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] New: debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 Bug ID: 427969 Summary: debuginfo section duplicates a section in the main ELF file Product: valgrind Version: unspecified Platform: Debian testing OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- When running wine's 32bit tests under valgrind with debian's debug symbols installed, I get a ton of errors like: --1235044-- WARNING: Serious error when reading debug info --1235044-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlidec.so.1.0.9: --1235044--debuginfo section duplicates a section in the main ELF file --1235044-- WARNING: Serious error when reading debug info --1235044-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlicommon.so.1.0.9: --1235044--debuginfo section duplicates a section in the main ELF file --1235057-- WARNING: Serious error when reading debug info --1235057-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlidec.so.1.0.9: --1235057--debuginfo section duplicates a section in the main ELF file --1235057-- WARNING: Serious error when reading debug info --1235057-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlicommon.so.1.0.9: --1235057--debuginfo section duplicates a section in the main ELF file -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #30 from Austin English --- Created attachment 128946 --> https://bugs.kde.org/attachment.cgi?id=128946&action=edit compiled test/pdb (In reply to Jefferson Carpenter from comment #29) > (In reply to Austin English from comment #28) > > Created attachment 128170 [details] > > the impossible happened > > > > Upon manual review, it didn't assert, but the impossible happened: > > > > PUTI(136:8xI8)[t1,0] = 0x0:I8 > > > > > > > > vex: the `impossible' happened: > > > >stmt_is_guardable: unhandled stmt > > > > vex storage: T total 9579053828 bytes allocated > > > > vex storage: P total 496 bytes allocated > > > > > > > > valgrind: the 'impossible' happened: > > > >LibVEX called failure_exit(). > > > > > > > > in dlls/atl/tests/registrar.c > > I ran the same test (valgrind --trace-children=yes > ../../../../wine-source/tools/runtest -q -P ../../../loader/wine -T ../../.. > -M atl.dll -p atl_test.exe.so registrar), and the impossible didn't happen > on my machine. (My configure command included --without-mingw because > that's what causes the .exe.so files to be generated). Can you confirm that > the bug happens with my patch applied and not on master? It seems like some > spooky action at a distance if my patch caused new problems generating IR. After some more testing, it only occurs if: ./configure --with-mingw CROSSDEBUG=pdb is used for the build. I'm not sure why the other log shows .exe.so. Maybe a dirty tree, or maybe wine's build system changed.. I've attached the exe and pdb file, it should be enough to reproduce without having to get llvm-mingw/rebuild wine. $ export VALGRIND_OPTS="-q --trace-children=yes --track-origins=yes --gen-suppressions=all --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-ignore --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-external --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-known-bugs --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-gecko --leak-check=full --num-callers=20 --workaround-gcc296-bugs=yes --vex-iropt-register-updates=allregs-at-mem-access" # make sure to use the full path for wine: $ valgrind /usr/local/bin/wine avifil32_test.exe api preloader: Warning: failed to reserve range 0011-6800 preloader: Warning: failed to reserve range 7f00-8200 0140:err:heap:HEAP_GetPtr Invalid heap (nil)! size: 136926 ==31466== LOAD_PDB_DEBUGINFO: Find PDB file: /tmp/valgrind_petmp31466_1cb84028 is empty ==31466== Warning: Missing or un-stat-able /home/austin/.wine/drive_c/windows/system32/kernelbase.pdb size: 135558 ==31466== LOAD_PDB_DEBUGINFO: Find PDB file: /tmp/valgrind_petmp31466_1cb84028 is empty ==31466== Warning: Missing or un-stat-able /usr/local/lib64/wine/kernelbase.pdb symbol table size is 0. Not reading debug information for /tmp/tmp.emEgO3p387/bug-211031-avifil32-test/avifil32_test.exe valgrind: m_debuginfo/debuginfo.c:1672 (vgPlain_di_notify_pdb_debuginfo): Assertion 'di && !di->fsm.have_rx_map && !di->fsm.have_rw_map' failed. host stacktrace: ==31466==at 0x58041CF9: show_sched_status_wrk (m_libcassert.c:406) ==31466==by 0x58041E20: report_and_quit (m_libcassert.c:477) ==31466==by 0x58041F14: vgPlain_assert_fail (m_libcassert.c:543) ==31466==by 0x58076146: vgPlain_di_notify_pdb_debuginfo (debuginfo.c:1672) ==31466==by 0x580A252D: do_client_request (scheduler.c:2121) ==31466==by 0x580A252D: vgPlain_scheduler (scheduler.c:1516) ==31466==by 0x580F72C2: thread_wrapper (syswrap-linux.c:101) ==31466==by 0x580F72C2: run_a_thread_NORETURN (syswrap-linux.c:154) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 31466) ==31466==at 0x7BCD6494: map_image (virtual.c:1749) ==31466==by 0x7BCD6A71: virtual_map_section (virtual.c:1835) ==31466==by 0x7BC79293: open_dll_file (loader.c:2371) ==31466==by 0x7BC79D9E: find_dll_file (loader.c:3014) ==31466==by 0x7BC7FDAB: load_dll (loader.c:3044) ==31466==by 0x7BC84857: __wine_process_init (loader.c:4426) ==31466==by 0x7BC84F42: __wine_set_unix_funcs (loader.c:4488) ==31466==by 0x7C001341: main (main.c:285) client stack range: [0xFECB8000 0xFECBDFFF] client SP: 0xFECBA900 valgrind stack range: [0x881FD000 0x882FCFFF] top usage: 7372 of 1048576 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #28 from Austin English --- Created attachment 128170 --> https://bugs.kde.org/attachment.cgi?id=128170&action=edit the impossible happened Upon manual review, it didn't assert, but the impossible happened: PUTI(136:8xI8)[t1,0] = 0x0:I8 vex: the `impossible' happened: stmt_is_guardable: unhandled stmt vex storage: T total 9579053828 bytes allocated vex storage: P total 496 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). in dlls/atl/tests/registrar.c -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #27 from Austin English --- No assertions so far (running still, up to d3d8:visual). Stacktraces look good. Lots of (valid) warnings for missing symbols in wine: symbol table size is 0. Not reading debug information for /home/austin/.wine-valgrind/drive_c/windows/system32/winex11.drv ==14040== LOAD_PDB_DEBUGINFO: Find PDB file: /tmp/valgrind_petmp14040_6f021bc4 is empty ==14040== Warning: Missing or un-stat-able /home/austin/.wine-valgrind/drive_c/windows/system32/winex11.pdb The symbol table size warning should match current format, of course. I haven't checked, but it likely corresponds to the un-stat-able message, so is it really needed? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #24 from Austin English --- Getting a failed assertion in some tests: valgrind: m_debuginfo/debuginfo.c:694 (check_CFSI_related_invariants): Assertion '!ranges_overlap(map->avma, map->size, map2->avma, map2->size)' failed. valgrind: DiCfsi invariant (1) verification failed host stacktrace: ==6286==at 0x58041CF9: show_sched_status_wrk (m_libcassert.c:406) ==6286==by 0x58041E20: report_and_quit (m_libcassert.c:477) ==6286==by 0x58041F14: vgPlain_assert_fail (m_libcassert.c:543) ==6286==by 0x58075670: check_CFSI_related_invariants (debuginfo.c:692) ==6286==by 0x58075670: di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:992) ==6286==by 0x58075670: vgPlain_di_notify_mmap (debuginfo.c:1326) ==6286==by 0x580A8D51: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2400) ==6286==by 0x580B5F25: vgSysWrap_x86_linux_sys_mmap2_before (syswrap-x86-linux.c:987) ==6286==by 0x580A45BE: vgPlain_client_syscall (syswrap-main.c:1914) ==6286==by 0x580A090C: handle_syscall (scheduler.c:1208) ==6286==by 0x580A246F: vgPlain_scheduler (scheduler.c:1526) ==6286==by 0x580F7312: thread_wrapper (syswrap-linux.c:101) ==6286==by 0x580F7312: run_a_thread_NORETURN (syswrap-linux.c:154) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 192 (lwpid 6286) ==6286==at 0x435A253: mmap64 (mmap64.c:56) ==6286==by 0x7BCAAFFE: map_pe_header (virtual.c:1491) ==6286==by 0x7BCAC3E6: map_image (virtual.c:1569) ==6286==by 0x7BCADA02: virtual_map_section (virtual.c:1838) ==6286==by 0x7BC68BFC: open_dll_file (loader.c:2515) ==6286==by 0x7BC68DA8: search_dll_file (loader.c:3074) ==6286==by 0x7BC6923F: find_dll_file (loader.c:3154) ==6286==by 0x7BC6CBF9: load_dll (loader.c:3186) ==6286==by 0x7BC6C0F8: import_dll (loader.c:801) ==6286==by 0x7BC6C64B: fixup_imports (loader.c:1165) ==6286==by 0x7BC6C8AF: load_native_dll (loader.c:2570) ==6286==by 0x7BC6CB26: load_builtin_dll (loader.c:2930) ==6286==by 0x7BC6CE08: load_dll (loader.c:3231) ==6286==by 0x7BC6C0F8: import_dll (loader.c:801) ==6286==by 0x7BC6C64B: fixup_imports (loader.c:1165) ==6286==by 0x7BC6E372: LdrInitializeThunk (loader.c:3987) ==6286==by 0x7BC99953: attach_thread (signal_i386.c:3050) ==6286==by 0x7BC9634F: ??? (in /home/austin/wine-valgrind/dlls/ntdll/ntdll.dll.so) client stack range: [0x4A62000 0x4B5] client SP: 0x4B5D22C valgrind stack range: [0x881D3000 0x882D2FFF] top usage: 7092 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. e.g., avifil32/tests/api.c -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #23 from Austin English --- I usually use -p1, so not sure what was wrong..anyway, recently tried again, with a clean tree, and it applies fine, so yeah, it was something on my end. With the patch, I see an improvement using badfree.c from the original post: No patch: ==10542== Invalid free() / delete / delete[] / realloc() ==10542==at 0x7BC70261: notify_free (heap.c:268) ==10542==by 0x7BC70261: RtlFreeHeap.part.7 (???:0) ==10542==by 0x7BC72034: RtlFreeHeap (heap.c:1748) ==10542==by 0x516469D: msvcrt_heap_free (heap.c:114) ==10542==by 0x51651DF: MSVCRT_free (heap.c:414) ==10542==by 0x401599: ??? ==10542==by 0x401395: ??? ==10542==by 0x7B4504F1: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==10542==by 0x7B4508DF: start_process (process.c:153) ==10542==by 0x7B4504FD: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==10542== Address 0x87654321 is on thread 1's stack ==10542== Patch: ==8665== Invalid free() / delete / delete[] / realloc() ==8665==at 0x7BC70261: notify_free (heap.c:268) ==8665==by 0x7BC70261: RtlFreeHeap.part.7 (???:0) ==8665==by 0x7BC72034: RtlFreeHeap (heap.c:1748) ==8665==by 0x516469D: msvcrt_heap_free (heap.c:114) ==8665==by 0x51651DF: MSVCRT_free (heap.c:414) ==8665==by 0x401599: _main (badfree.c:12) ==8665==by 0x401395: ??? (crtexe.c:339) ==8665==by 0x7B4504F1: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==8665==by 0x7B4508DF: start_process (process.c:153) ==8665==by 0x7B4504FD: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==8665== Address 0x87654321 is on thread 1's stack ==8665== namely badfree.c:12 and crtexe.c:339. Note that there's some spurious output from the patch, e.g.,: size: 130284 @Julian, if feasible, it would be great to target this for valgrind-3.16.0. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #20 from Austin English --- (In reply to Jefferson Carpenter from comment #19) > Created attachment 126977 [details] > Hackish patch: Add read_pe_debug_info: v2 > > Fixed some of the most significant lies from my first patch. No longer > assumes .text is the first section. Instead of "main.exe" uses the basename > of the executable as the soname (I don't know whether this is even correct). > Uses correct-looking arenas for allocations. Correctly sorts symbols in > descending order and corrects addSym calls. Fails to build: make[3]: *** No rule to make target 'm_debuginfo/readpe.c', needed by 'm_debuginfo/libcoregrind_amd64_linux_a-readpe.o'. Stop. (try 1 compiles okay) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #16 from Austin English --- I recently tested llvm-mingw (from https://github.com/mstorsjo/llvm-mingw/), and built wine with llvm's pdb debug symbols. That gives similar results to gnu mingw: ==23786== Invalid read of size 2 ==23786==at 0x7B01F09E: ??? ==23786==by 0x60B93DA: ??? ==23786==by 0x60B89AC: ??? ==23786==by 0x507872F: ??? (in /home/austin/wine-valgrind-mingw/dlls/user32/user32.dll.so) ==23786==by 0x5078CFE: call_window_proc (winproc.c:249) ==23786==by 0x507A02C: WINPROC_CallProcAtoW (winproc.c:609) ==23786==by 0x507ABC4: WINPROC_call_window (winproc.c:956) ==23786==by 0x5043C8D: call_window_proc (message.c:2225) ==23786==by 0x5046E09: send_message (message.c:3294) ==23786==by 0x50498B9: SendMessageA (message.c:3517) ==23786==by 0x41C0A6: ??? ==23786==by 0x4143D1: ??? ==23786==by 0x49F862: ??? ==23786==by 0x49F71C: ??? ==23786==by 0x401394: ??? ==23786==by 0x7B449E31: ??? (in /home/austin/wine-valgrind-mingw/dlls/kernel32/kernel32.dll.so) ==23786==by 0x7B44A262: start_process (process.c:153) ==23786==by 0x7B449E3D: ??? (in /home/austin/wine-valgrind-mingw/dlls/kernel32/kernel32.dll.so) ==23786== Address 0x5ec1a08 is 744 bytes inside a block of size 1,024 free'd ==23786==at 0x7BC6255E: notify_free (heap.c:268) ==23786==by 0x7BC64B94: RtlFreeHeap (heap.c:1771) ==23786==by 0x52123C3: free_heap_bits (bitblt.c:168) ==23786==by 0x521CF08: nulldrv_StretchDIBits (dib.c:606) ==23786==by 0x521D285: StretchDIBits (dib.c:636) ==23786==by 0x500C450: create_icon_from_bmi (cursoricon.c:1265) ==23786==by 0x500D26B: CURSORICON_Load (cursoricon.c:1867) ==23786==by 0x500F153: LoadImageW (cursoricon.c:3065) ==23786==by 0x6111289: ??? ==23786==by 0x60B1CE7: ??? ==23786==by 0x61221E0: ??? ==23786==by 0x7BC667C9: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==23786==by 0x7BC6A582: MODULE_InitDLL (loader.c:1331) ==23786==by 0x7BC6A80A: process_attach (loader.c:1425) ==23786==by 0x7BC6CBD2: LdrLoadDll (loader.c:3094) ==23786==by 0x7B01436E: ??? ==23786==by 0x7B014279: ??? ==23786==by 0x7B01419B: ??? ==23786==by 0x7B01415E: ??? ==23786==by 0x4145B5: ??? ==23786== Block was alloc'd at ==23786==at 0x7BC62514: notify_alloc (heap.c:260) ==23786==by 0x7BC65377: RtlAllocateHeap (heap.c:1725) ==23786==by 0x5212AB4: convert_bits (bitblt.c:183) ==23786==by 0x521D045: nulldrv_StretchDIBits (dib.c:589) ==23786==by 0x521D285: StretchDIBits (dib.c:636) ==23786==by 0x500C450: create_icon_from_bmi (cursoricon.c:1265) ==23786==by 0x500D26B: CURSORICON_Load (cursoricon.c:1867) ==23786==by 0x500F153: LoadImageW (cursoricon.c:3065) ==23786==by 0x6111289: ??? ==23786==by 0x60B1CE7: ??? ==23786==by 0x61221E0: ??? ==23786==by 0x7BC667C9: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==23786==by 0x7BC6A582: MODULE_InitDLL (loader.c:1331) ==23786==by 0x7BC6A80A: process_attach (loader.c:1425) ==23786==by 0x7BC6CBD2: LdrLoadDll (loader.c:3094) ==23786==by 0x7B01436E: ??? ==23786==by 0x7B014279: ??? ==23786==by 0x7B01419B: ??? ==23786==by 0x7B01415E: ??? ==23786==by 0x4145B5: ??? ==23786== which is interesting, given that valgrind has some pdb support. LLVM uses the publicly documented pdb info from https://github.com/Microsoft/microsoft-pdb, fwiw. Note that I did run until other issues in some tests with this setup, see bug 416779. Tested with VALGRIND_3_15_0-193-gfe6805efc -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 416779] New: valgrind: m_debuginfo/debuginfo.c:454 (discard_or_archive_DebugInfo): Assertion '!di->have_dinfo || is_DebugInfo_active(di)' failed.
https://bugs.kde.org/show_bug.cgi?id=416779 Bug ID: 416779 Summary: valgrind: m_debuginfo/debuginfo.c:454 (discard_or_archive_DebugInfo): Assertion '!di->have_dinfo || is_DebugInfo_active(di)' failed. Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- Tested with VALGRIND_3_15_0-193-gfe6805efc STEPS TO REPRODUCE 1. build wine, with https://github.com/mstorsjo/llvm-mingw/ and enable pdb symbols 2. cd ./dlls/crypt32/tests 3. make cert.ok Result: ../../../tools/runtest -q -P wine -T ../../.. -M crypt32.dll -p crypt32_test.exe cert && touch cert.ok valgrind: m_debuginfo/debuginfo.c:454 (discard_or_archive_DebugInfo): Assertion '!di->have_dinfo || is_DebugInfo_active(di)' failed. host stacktrace: ==27633==at 0x58041809: show_sched_status_wrk (m_libcassert.c:406) ==27633==by 0x58041930: report_and_quit (m_libcassert.c:477) ==27633==by 0x58041A24: vgPlain_assert_fail (m_libcassert.c:543) ==27633==by 0x58072C1B: discard_or_archive_DebugInfo (debuginfo.c:454) ==27633==by 0x58072E24: discard_syms_in_range (debuginfo.c:526) ==27633==by 0x580751C8: vgPlain_di_notify_munmap (debuginfo.c:1336) ==27633==by 0x580AEE96: vgModuleLocal_notify_core_and_tool_of_munmap (syswrap-generic.c:246) ==27633==by 0x580AEE96: vgSysWrap_generic_sys_munmap_after (syswrap-generic.c:3949) ==27633==by 0x580A2829: vgPlain_post_syscall (syswrap-main.c:2172) ==27633==by 0x580A2E42: vgPlain_client_syscall (syswrap-main.c:2093) ==27633==by 0x5809EFFC: handle_syscall (scheduler.c:1208) ==27633==by 0x580A0B5F: vgPlain_scheduler (scheduler.c:1526) ==27633==by 0x580F58F2: thread_wrapper (syswrap-linux.c:101) ==27633==by 0x580F58F2: run_a_thread_NORETURN (syswrap-linux.c:154) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 91 (lwpid 27633) ==27633==at 0x437A2C6: munmap (syscall-template.S:78) ==27633==by 0x7BCA7BF1: unmap_area (virtual.c:799) ==27633==by 0x7BCA7C3F: delete_view (virtual.c:836) ==27633==by 0x7BCAC4F1: NtUnmapViewOfSection (virtual.c:3409) ==27633==by 0x7BC68D7C: free_modref (loader.c:3586) ==27633==by 0x7BC68E66: MODULE_FlushModrefs (loader.c:3613) ==27633==by 0x7BC6AB0B: LdrUnloadDll (loader.c:3687) ==27633==by 0x7B013D20: ??? ==27633==by 0x4BD0B9F: CryptFreeOIDFunctionAddress (oid.c:481) ==27633==by 0x4B9E51B: CertVerifyRevocation (cert.c:2024) ==27633==by 0x40AC79: ??? ==27633==by 0x4035BF: ??? ==27633==by 0x445332: ??? ==27633==by 0x4451EC: ??? ==27633==by 0x401394: ??? ==27633==by 0x7B449E31: ??? (in /home/austin/wine-valgrind-mingw/dlls/kernel32/kernel32.dll.so) ==27633==by 0x7B44A262: start_process (process.c:153) ==27633==by 0x7B449E3D: ??? (in /home/austin/wine-valgrind-mingw/dlls/kernel32/kernel32.dll.so) client stack range: [0x4A52000 0x4B4] client SP: 0x4B4FA58 valgrind stack range: [0x8815E000 0x8825DFFF] top usage: 16748 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. make[1]: *** [Makefile:234: cert.ok] Error 1 Expected result: Assertion doesn't fail austin@laptop ~/wine-valgrind/dlls/crypt32/tests (master) $ file *pdb crypt32_test.pdb: MSVC program database ver 7.00, 4096*194 bytes Note that this occurs for many, but not all, tests. Out of the first 176 tests (I had to stop for unrelated reasons), 41 tests showed this failure. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #15 from Austin English --- As of wine-4.6, wine now supports building its dlls with mingw: https://source.winehq.org/git/wine.git/commitdiff/a3cf86a18446e9d7df4e045b83d3aa3d9193512a the plan is to eventually make that the default (not sure if there's a timeline for that yet, but I would guess that before next stable release is likely). When compiling wine with mingw support, stacktraces are pretty poor. As a comparison, here's the same test with native gcc (8.3.0) versus mingw (i686-w64-mingw32-gcc (Gentoo 9.2.0-r2 p3) 9.2.0). With dlls/comctl32/tests/edit.c in wine-4.20-213-gddec23013e native: ==10945== Invalid read of size 2 ==10945==at 0x4F0C401: LocalLock (memory.c:661) ==10945==by 0x63FAE1A: EDIT_LockBuffer (edit.c:1195) ==10945==by 0x640216D: EDIT_WindowProc (edit.c:4608) ==10945==by 0x55FB4A7: ??? (in /home/austin/wine-valgrind-no-mingw/dlls/user32/user32.dll.so) ==10945==by 0x55FBA94: call_window_proc (winproc.c:249) ==10945==by 0x55FCEFE: WINPROC_CallProcAtoW (winproc.c:609) ==10945==by 0x55FDB4D: WINPROC_call_window (winproc.c:956) ==10945==by 0x55C38CE: call_window_proc (message.c:2225) ==10945==by 0x55C6EB6: send_message (message.c:3294) ==10945==by 0x55C9B02: SendMessageA (message.c:3517) ==10945==by 0x5016FDF: test_EM_GETHANDLE (edit.c:3041) ==10945==by 0x5018F22: func_edit (edit.c:3411) ==10945==by 0x50A0581: run_test (test.h:637) ==10945==by 0x50A0E08: main (test.h:721) ==10945== Address 0x4952a58 is 16 bytes after a recently re-allocated block of size 32 alloc'd ==10945==at 0x7BC6656F: notify_alloc (heap.c:260) ==10945==by 0x7BC695B5: RtlAllocateHeap (heap.c:1725) ==10945==by 0x59177B7: create_family (freetype.c:1594) ==10945==by 0x59278A4: load_font_list_from_cache (freetype.c:1768) ==10945==by 0x59283B9: WineEngInit (freetype.c:4458) ==10945==by 0x5928CCD: DllMain (gdiobj.c:693) ==10945==by 0x594011C: __wine_spec_dll_entry (dll_entry.c:44) ==10945==by 0x7BC6AA95: ??? (in /home/austin/wine-valgrind-no-mingw/dlls/ntdll/ntdll.dll.so) ==10945==by 0x7BC6EC1A: MODULE_InitDLL (loader.c:1331) ==10945==by 0x7BC6EEBB: process_attach (loader.c:1425) ==10945==by 0x7BC6EDFD: process_attach (loader.c:1411) ==10945==by 0x7BC6EDFD: process_attach (loader.c:1411) ==10945==by 0x7BC6EDFD: process_attach (loader.c:1411) ==10945==by 0x7BC715B9: LdrInitializeThunk (loader.c:3782) ==10945==by 0x7BC9C556: attach_thread (signal_i386.c:2746) ==10945==by 0x7BC991C3: ??? (in /home/austin/wine-valgrind-no-mingw/dlls/ntdll/ntdll.dll.so) mingw: ==15488== Invalid read of size 2 ==15488==at 0x7BC74A86: RtlInitNlsTables (locale.c:760) ==15488==by 0x7125EB11: ??? ==15488==by 0x7126254F: ??? ==15488==by 0x71262871: ??? ==15488==by 0x7BC6AAD5: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==15488==by 0x7BC6EC5A: MODULE_InitDLL (loader.c:1331) ==15488==by 0x7BC6EEFB: process_attach (loader.c:1425) ==15488==by 0x7BC6EE3D: process_attach (loader.c:1411) ==15488==by 0x7BC6EE3D: process_attach (loader.c:1411) ==15488==by 0x7BC715F9: LdrInitializeThunk (loader.c:3782) ==15488==by 0x7BC9D12A: attach_thread (signal_i386.c:2746) ==15488==by 0x7BC99D97: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==15488== Address 0x2 is not stack'd, malloc'd or (recently) free'd ==15488== interestingly, mingw shows RtlInitNlsTables while gcc doesn't (but that's likely it, since RtlInitNlsTables is in dlls/ntdll/locale.c at line 760 and that's the ??? in the gcc output. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 350228] Unhandled ioctl 0x6458 (i965/mesa)
https://bugs.kde.org/show_bug.cgi?id=350228 --- Comment #9 from Austin English --- Created attachment 119495 --> https://bugs.kde.org/attachment.cgi?id=119495&action=edit add DRM_IOCTL_I915_GEM_THROTTLE -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 350228] Unhandled ioctl 0x6458 (i965/mesa)
https://bugs.kde.org/show_bug.cgi?id=350228 --- Comment #8 from Austin English --- Created attachment 119494 --> https://bugs.kde.org/attachment.cgi?id=119494&action=edit Patch: mention strace as a data source for syscall/ioctl information -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 350228] Unhandled ioctl 0x6458 (i965/mesa)
https://bugs.kde.org/show_bug.cgi?id=350228 Austin English changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOT A BUG |--- Ever confirmed|0 |1 --- Comment #7 from Austin English --- Reopening, because I *finally* found something useful on github. strace has some info on this; apparently it can be: DRM_IOCTL_I915_GEM_THROTTLE, drm/i915_drm.h: https://github.com/strace/strace/blob/7cc6eb706ba7f67d1e84fe903e59ce824f799df5/linux/32/ioctls_inc_align16.h#L273 or: DRM_IOCTL_RADEON_CP_RESUME, drm/radeon_drm.h: https://github.com/strace/strace/blob/7cc6eb706ba7f67d1e84fe903e59ce824f799df5/linux/32/ioctls_inc_align16.h#L364 In my case it would be the intel definition (probably), as I've got a mixed intel/nvidia setup (but not radeon). note to self: check strace next time. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 350228] Unhandled ioctl 0x6458 (i965/mesa)
https://bugs.kde.org/show_bug.cgi?id=350228 --- Comment #6 from Austin English --- (In reply to Austin English from comment #5) > I asked in the intel-gfx and xorg IRC channels about these ioctls, and the > answers were basically "try newer Valgrind" and "look at the source..oh > they're not there, macros are a hell of a drug," so I don't expect upstream > to be very helpful. > > Given that I no longer have access to this hardware, I'm just going to close > this. I can reproduce this on my current hardware again; though I don't have any leads on actually fixing, so I'm not reopening (though it is reproducible again). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 400538] vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55
https://bugs.kde.org/show_bug.cgi?id=400538 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com --- Comment #7 from Austin English --- Okay, I can reproduce this, it needs a couple more valgrind arguments. # First, start a wine process (so that wineserver is running before valgrind starts): $ wine64 start /min winemine # Then, start notepad under valgrind: $ austin@laptop:~/src/valgrind$ valgrind --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access /opt/oldwow64/wine-4.5/bin/wine64 notepad ==2874== Memcheck, a memory error detector ==2874== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2874== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2874== Command: /opt/oldwow64/wine-4.5/bin/wine64 notepad ==2874== ==2874== Memcheck, a memory error detector ==2874== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2874== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2874== Command: /opt/oldwow64/wine-4.5/bin/wine64-preloader /opt/oldwow64/wine-4.5/bin/wine64 notepad ==2874== preloader: Warning: failed to reserve range 0011-6800 ==2874== vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==2874== valgrind: Unrecognised instruction at address 0x7bc9bff3. ==2874==at 0x7BC9BFF3: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874==by 0x7BC9C0CA: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874== Your program just tried to execute an instruction that Valgrind ==2874== did not recognise. There are two possible reasons for this. ==2874== 1. Your program has a bug and erroneously jumped to a non-code ==2874==location. If you are running Memcheck and you just saw a ==2874==warning about a bad jump, it's probably your program's fault. ==2874== 2. The instruction is legitimate but Valgrind doesn't handle it, ==2874==i.e. it's Valgrind's fault. If you think this is the case or ==2874==you are not sure, please let us know and we'll try to fix it. ==2874== Either way, Valgrind will now raise a SIGILL signal which will ==2874== probably kill your program. 005d:err:seh:segv_handler Got unexpected trap 0 ==2874== Invalid write of size 8 ==2874==at 0x7BC9BFF8: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874==by 0x7BC9BFF2: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874==by 0x7BC9C0CA: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874== Address 0x7e20f4b8 is in a rw- anonymous segment ==2874== 005d:err:seh:NtRaiseException Unhandled exception code c01d flags 0 addr 0x7bc9bff3 ==2874== ==2874== HEAP SUMMARY: ==2874== in use at exit: 731,905 bytes in 6,501 blocks ==2874== total heap usage: 13,837 allocs, 7,336 frees, 2,963,926 bytes allocated ==2874== ==2874== LEAK SUMMARY: ==2874==definitely lost: 318 bytes in 2 blocks ==2874==indirectly lost: 0 bytes in 0 blocks ==2874== possibly lost: 0 bytes in 0 blocks ==2874==still reachable: 731,587 bytes in 6,499 blocks ==2874== suppressed: 0 bytes in 0 blocks ==2874== Rerun with --leak-check=full to see details of leaked memory ==2874== ==2874== For counts of detected and suppressed errors, rerun with: -v ==2874== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Tested with 3.15-rc1 / wine-4.5 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657
--- Comment #24 from Austin English ---
(In reply to Daniel Lehman from comment #23)
> > 0030:err:seh:NtRaiseException Unhandled exception code c01d flags 0
> > addr 0x7bc95b63
>
> that's probably the iretq instruction from set_cpu_context
>
> > What VALGRIND_OPTS are you using?
>
> -v --trace-children=yes --error-limit=no --log-file=output.txt
> --leak-check=full --leak-resolution=high --show-leak-kinds=all
>
> > did I miss a step?
>
> no, sorry, i forgot that i had to create a symlink to find the pdb:
> ln -s $HOME $WINEPREFIX/drive_Y
> because the baked-in path is Y:/stuff/leakage
That's weird..when first trying this, I missed your 'drive_Y' bit and was
symlinking to dosdevices/y:, which failed. With drive_Y, it works (not
valgrind's problem, of course).
I can verify that works for me:
+ /home/austin/src/valgrind/vg-in-place wine64 leakage.exe
preloader: Warning: failed to reserve range 0011-6800
==32694== Conditional jump or move depends on uninitialised value(s)
==32694==at 0x14005F7DE: __strncnt (strncnt.cpp:21)
==32694==by 0x7B9D4E0A8F2C: ???
==32694== Uninitialised value was created by a stack allocation
==32694==at 0x14004BB17: setSBUpLow (in
/tmp/tmp.sYSJGwj3qz/stuff/leakage/leakage.exe)
==32694==
7E018520
setframe: 7E20FCD0
7E01C6D0
006e:fixme:kernelbase:AppPolicyGetProcessTerminationMethod 0xfffa,
0x7e20fd10
==32694== 12,345 bytes in 1 blocks are definitely lost in loss record 92 of 93
==32694==at 0x7BC5BB35: initialize_block (heap.c:238)
==32694==by 0x7BC5BB35: RtlAllocateHeap (???:0)
==32694==by 0x140006BDA: a (leakage.c:9)
==32694==by 0x140006BF8: b (leakage.c:14)
==32694==by 0x140006C18: c (leakage.c:19)
==32694==by 0x140006CF8: main (leakage.c:43)
==32694==
==32694== 23,456 bytes in 1 blocks are definitely lost in loss record 93 of 93
==32694==at 0x7BC5BB35: initialize_block (heap.c:238)
==32694==by 0x7BC5BB35: RtlAllocateHeap (???:0)
==32694==by 0x140006C8C: setframe (leakage.c:28)
==32694==by 0x140006CB8: d (leakage.c:33)
==32694==by 0x140006CD8: e (leakage.c:38)
==32694==by 0x140006D0C: main (leakage.c:44)
==32694==
==
For our valgrind friends, if you'd like to test Daniel's patch, here's a short
script to do so. Get wine64 from your package manager (4.0 stable should work,
or probably any version), then run the script, no special wine knowledge needed
:)
#!/bin/bash
# Requires wine64 (nothing special needed, get it from your package manager)
# and valgrind, of course
export VALGRIND="${VALGRIND:-valgrind}"
export VALGRIND_OPTS="-q --trace-children=yes --track-origins=yes
--leak-check=full --num-callers=20
--vex-iropt-register-updates=allregs-at-mem-access"
export WINEPREFIX="${WINEPREFIX:-$HOME/.wine}"
tmpdir="$(mktemp -d)"
cd "$tmpdir"
mkdir -p stuff/leakage
cd stuff/leakage
wget -O stuff.tar.bz2 "https://bugs.kde.org/attachment.cgi?id=118764";
tar xjf stuff.tar.bz2
ln -sf "$tmpdir" "$WINEPREFIX/drive_Y"
# Here we go:
"$VALGRIND" wine64 leakage.exe
cd
rm -rf "$tmpdir"
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657 --- Comment #22 from Austin English --- That said, it's still an improvement. Without the patchset, I get: austin@laptop:~$ /opt/valgrind/bin/valgrind /opt/oldwow64/wine-4.0-rc1/bin/wine leakage.exe ; echo $? preloader: Warning: failed to reserve range 0011-6800 preloader: Warning: failed to reserve range 7f00-8200 preloader: Warning: failed to reserve range 0011-6800 0030:err:seh:segv_handler Got unexpected trap 0 ==6737== Invalid write of size 8 ==6737==at 0x7BC95B68: ??? (in /opt/oldwow64/wine-4.0-rc1/lib64/wine/ntdll.dll.so) ==6737==by 0x7BC95B62: ??? (in /opt/oldwow64/wine-4.0-rc1/lib64/wine/ntdll.dll.so) ==6737==by 0x7BC95C3A: ??? (in /opt/oldwow64/wine-4.0-rc1/lib64/wine/ntdll.dll.so) ==6737== Address 0x7e20f4b8 is in a rw- anonymous segment ==6737== 0030:err:seh:NtRaiseException Unhandled exception code c01d flags 0 addr 0x7bc95b63 29 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657 --- Comment #21 from Austin English --- (In reply to Daniel Lehman from comment #20) > Created attachment 118764 [details] > leakage.exe and pdb > > attached tested with: > - Visual Studio 2017 (15.9.8) > - wine 4.3 > - valgrind-3.15.0.GIT (4816357b5c7ee5284cdf72800a81d2dd1845388f) Thanks. I wasn't able to reproduce, with same valgrind git commit (+ your patches) and wine-4.0-rc1 (last wow64 build I have handy, but given that you used 3.15 before I don't think it matters). What VALGRIND_OPTS are you using? I tried with: austin@laptop:~$ export VALGRIND_OPTS="-q --trace-children=yes --track-origins=yes --leak-check=full --num-callers=20 --vex-iropt-register-updates=allregs-at-mem-access" and got: austin@laptop:~$ ~/src/valgrind/vg-in-place /opt/oldwow64/wine-4.0-rc1/bin/wine leakage.exe ; echo $? preloader: Warning: failed to reserve range 0011-6800 preloader: Warning: failed to reserve range 7f00-8200 preloader: Warning: failed to reserve range 0011-6800 ==6365== Conditional jump or move depends on uninitialised value(s) ==6365==at 0x14005F7DE: ??? ==6365==by 0x51B686B7C272: ??? ==6365== Uninitialised value was created by a stack allocation ==6365==at 0x14004BB17: ??? ==6365== 7E01B5F0 setframe: 7E20FCD0 7E01F7A0 ==6365== 12,345 bytes in 1 blocks are definitely lost in loss record 86 of 88 ==6365==at 0x7BC5B385: initialize_block (heap.c:238) ==6365==by 0x7BC5B385: RtlAllocateHeap (???:0) ==6365==by 0x140006BDA: ??? ==6365== ==6365== 23,456 bytes in 1 blocks are definitely lost in loss record 88 of 88 ==6365==at 0x7BC5B385: initialize_block (heap.c:238) ==6365==by 0x7BC5B385: RtlAllocateHeap (???:0) ==6365==by 0x140006C8C: ??? ==6365==by 0x51B686B7CD62: ??? ==6365== 0 did I miss a step? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657 --- Comment #19 from Austin English --- (In reply to Daniel Lehman from comment #18) > Created attachment 114891 [details] > simple test case for wine64 pdb Hi Daniel, Would you mind attaching a pre-built binary? I'd like to test this, but I don't currently have Visual Studio set up (and won't be able to for a week or so at the earliest). Thanks! -Austin -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991 --- Comment #9 from Austin English --- (In reply to Julian Seward from comment #8) > (In reply to Austin English from comment #7) > > > Austin, can you show me the source of the signal handler involved? > > > > Yeah, it's here: > > https://source.winehq.org/git/wine.git/blob/ > > bfad5527acacbdbac623da57413a60c532218423:/dlls/kernel32/heap.c#l741 > > Hmm. While that is probably related, it is not a signal handler, > and it also isn't the source of the messages you showed in comment 6. > > The signal handling magic bits will somehow be hidden in the macros > __TRY (line 747), __EXCEPT_PAGE_FAULT (line 785) and __ENDTRY (line 791). > Can you show the definitions of those, so we can find the actual handler? > > A signal handler will have signature "void handler(int signo)" or > (more likely) "void handler(int signo, siginfo_t* siginfo, void* context)". Thanks for the pointer / sorry for the mixup. I believe what you're looking for is in: https://source.winehq.org/git/wine.git/blob/bfad5527acacbdbac623da57413a60c532218423:/include/wine/exception.h#l101 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991 --- Comment #7 from Austin English --- (In reply to Julian Seward from comment #6) > (In reply to Austin English from comment #5) > > While the situation has changed, it still differs from what I see on amd64. > > Log attached. > > Hmm. If I had to guess, I'd say that the signal frame that V creates > doesn't have enough details in it to keep the Wine signal handler happy. > > Austin, can you show me the source of the signal handler involved? Yeah, it's here: https://source.winehq.org/git/wine.git/blob/bfad5527acacbdbac623da57413a60c532218423:/dlls/kernel32/heap.c#l741 FYI wine's development IRC channel is #winehackers if you want to get more info (I think you already knew that, but just in case). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991 --- Comment #5 from Austin English --- Created attachment 115058 --> https://bugs.kde.org/attachment.cgi?id=115058&action=edit valgrind output While the situation has changed, it still differs from what I see on amd64. Log attached. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991
--- Comment #2 from Austin English ---
4:49:22 AM austin_laptop if someone with decent understanding of
kernel32/heap.c has a few minutes, I'd appreciate if someone could help me
answer Julian's questions from https://bugs.kde.org/show_bug.cgi?id=395991 (I'm
happy to forward your answers if you don't have a KDE bz account)
5:01:50 AM _Marcus_ austin_laptop: so if we take a segfault, the handler
would run into the expcetion chain
5:02:02 AM _Marcus_ austin_laptop: but in general, globalalloc should not
fault in my opinion
5:02:54 AM _Marcus_ SetLastError(MAGIC_DEAD);
5:02:54 AM _Marcus_ hsecond = GlobalFree(LongToHandle(0xdeadbeef));
/* bogus handle */
5:03:01 AM _Marcus_ hmm, but this code does
5:03:07 AM austin_laptop thanks _Marcus_. Yeah, from a quick read of the
code, I didn't see why it would segfault, but wasn't completely sure
5:03:29 AM _Marcus_ so basically we are running into the TRY /
__EXCEPT_PAGE_FAULT block in GlobalFree
5:03:37 AM _Marcus_ the testcase causes it to fault
5:03:47 AM _Marcus_ but this is our generic exceptipon handling
5:04:10 AM austin_laptop ok
5:06:40 AM _Marcus_ something in the arm signal handling is not fully
correct I would think :/
5:07:11 AM austin_laptop yeah, that's likely
5:07:36 AM austin_laptop this is armv7l rather than arm64 (and at least
on VG side, is not as complete)
5:07:37 AM _Marcus_ winedebug +heap should print the ERR("invalid
handle %p\n", hmem);
5:07:48 AM _Marcus_ from GlobalFree, if it does not ... we are not
getting there for some reason
Note: I ran with +heap, but do not get that message, so something may be broke
in wine's armv7l exception handling as well.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 332917] Valgrind should warn the user that SSE4 is not supported in the 32-bit mode
https://bugs.kde.org/show_bug.cgi?id=332917 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 344802] disInstr(arm): unhandled instruction: 0xEC510F1E
https://bugs.kde.org/show_bug.cgi?id=344802 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991 Austin English changed: What|Removed |Added Platform|Other |Compiled Sources --- Comment #1 from Austin English --- Using valgrind-3.14.0.GIT-90daa486e8-20180620 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] New: wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
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-0xfffe --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.
[valgrind] [Bug 266035] Support running Valgrind for Android on ARM
https://bugs.kde.org/show_bug.cgi?id=266035 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395777] disInstr(arm): unhandled instruction: 0xE7F000F0 (wine, dlls/msvcp90/tests/misc.c)
https://bugs.kde.org/show_bug.cgi?id=395777 --- Comment #1 from Austin English --- That seems to be #define FBT_BREAKPOINT 0xe7f000f0 according to https://github.com/F-Stack/f-stack/blob/master/freebsd/arm/include/trap.h There's only a few more in that header, so it may be worth implementing all at the same time: #define GDB_BREAKPOINT 0xe611 #define GDB5_BREAKPOINT 0xe7ffdefe #define PTRACE_BREAKPOINT 0xe7f0 #define KERNEL_BREAKPOINT 0xe7ff #define FBT_BREAKPOINT 0xe7f000f0 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395777] New: disInstr(arm): unhandled instruction: 0xE7F000F0 (wine, dlls/msvcp90/tests/misc.c)
https://bugs.kde.org/show_bug.cgi?id=395777 Bug ID: 395777 Summary: disInstr(arm): unhandled instruction: 0xE7F000F0 (wine, dlls/msvcp90/tests/misc.c) Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- As description states: disInstr(arm): unhandled instruction: 0xE7F000F0 cond=14(0xE) 27:20=127(0x7F) 4:4=1 3:0=0(0x0) found when running wine's unit tests, specifically dlls/msvcp90/tests/misc.c (stretch)austin@localhost:~/src/valgrind$ /opt/valgrind/bin/valgrind --version -v valgrind-3.14.0.GIT-90daa486e8-20180620 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com --- Comment #11 from Austin English --- Still in 482e36cb6e-20180203, using gcc 6.4.0. Also reported downstream in Gentoo, see https://bugs.gentoo.org/641806 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 387686] valgrind-3.13.0 tests on Gentoo fail with glibc-2.26 (work with glibc-2.25).
https://bugs.kde.org/show_bug.cgi?id=387686 Austin English changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Austin English --- Closing. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 387686] valgrind-3.13.0 tests on Gentoo fail with glibc-2.26 (work with glibc-2.25).
https://bugs.kde.org/show_bug.cgi?id=387686 Austin English changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Austin English --- My fault for not testing git first. This was already fixed, by: 2b5eab6a8db1b0487a3ad7fc4e7eeda6d3513626 Author: Mark Wielaard Date: Thu Jun 29 15:26:30 2017 + memcheck/tests: Use ucontext_t instead of struct ucontext -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 387686] New: valgrind-3.13.0 tests on Gentoo fail with glibc-2.26 (work with glibc-2.25).
https://bugs.kde.org/show_bug.cgi?id=387686 Bug ID: 387686 Summary: valgrind-3.13.0 tests on Gentoo fail with glibc-2.26 (work with glibc-2.25). Product: valgrind Version: 3.13.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- Created attachment 109247 --> https://bugs.kde.org/attachment.cgi?id=109247&action=edit test failures Originally reported here: https://bugs.gentoo.org/637488 the valgrind-3.13.0 unit tests fail on an unstable Gentoo machine. They work for me on my stable machine. Testing in a chroot, I was able to find that glibc is the source of the problem. The working machine has: sys-libs/glibc-2.25-r9, while sys-libs/glibc-2.26-r3 is broken. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #15 from Austin English --- (In reply to Julian Seward from comment #14) > Landed, c470e0c23c6c79deec943cb6a111b572fc86dbba. Thanks for the quick fix! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #13 from Austin English --- Created attachment 108909 --> https://bugs.kde.org/attachment.cgi?id=108909&action=edit output with patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #12 from Austin English --- Created attachment 108908 --> https://bugs.kde.org/attachment.cgi?id=108908&action=edit output without patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #11 from Austin English --- (In reply to Julian Seward from comment #10) > Created attachment 108896 [details] > TPIDRURW support for 32-bit arm > > This runs the test program shown in comment 6, correctly, both for > Thumb and ARM encodings. For 32 bit only. Austin, can you test this? Seems to work for me, thanks! I'm going to attach logs with/without the patch. I used --verbose instead of -q, which then showed the missing info: disInstr(arm): unhandled instruction: 0xEE0D4F50 cond=14(0xE) 27:20=224(0xE0) 4:4=1 3:0=0(0x0) ==4434== valgrind: Unrecognised instruction at address 0x4fc3bb4. ==4434==at 0x4FC3BB4: signal_init_thread (signal_arm.c:974) ==4434==by 0x4FCACF7: thread_init (thread.c:354) ==4434==by 0x4FA1433: __wine_process_init (loader.c:3341) ==4434==by 0x485FBC3: wine_init (loader.c:979) ==4434==by 0x108A27: main (main.c:258) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #7 from Austin English --- Re arm/thumb: so you said it's arm encoding. I noticed that configure.ac requires thumb? Do both get used? yes, most of wine should be arm what's thumb used for? Windows Apps are Thumb-2, and to call into such functions we need the command "blx" (branch and link while exchanging instruction set if necessary, or something like that), if the compiler targets non-thumb (e.g. arm-only) it doesn't like bx and blx so it targets both arm and thumb? the compiler, yes the instruction I'm checking this right now the instruction encoding seems to be exactly the same for both arm and thumb-2 it's definitely arm -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #6 from Austin English --- (In reply to Julian Seward from comment #4) > (In reply to Julian Seward from comment #3) > > IIUC, TPIDRURW is a 32 bit register that can be both read and > > written from user space. Yes? Does it require any special handling? > > To clarify .. what I mean to ask is: does TPIDRURW behave like a "normal" > integer register, in that each thread has its own copy and can read and > write it independently of other threads? Or does it have some other > behaviour? >From Andre: >> Sure, >> >> it should be ARM encoding. trpidrurw is rw from userspace and needs no >> permissions > Is it specific per thread or shared across? > per thread maybe https://github.com/AndreRH/tpidrurw-test can help to understand it -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #2 from Austin English --- Forgot to include, some background on why we're doing that: https://patchwork.kernel.org/patch/2536641/ -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #1 from Austin English --- (stretch)austin@localhost:~/src/valgrind$ uname -a Linux localhost 3.14.0 #1 SMP PREEMPT Wed Oct 25 21:59:24 PDT 2017 armv7l GNU/Linux (stretch)austin@localhost:~/src/valgrind$ /opt/valgrind/bin/valgrind -v --version valgrind-3.14.0.GIT (confused why that doesn't show the git hash..) (stretch)austin@localhost:~/src/valgrind$ tail -n 1 include/vgversion.h #define VGGIT "2f9cceafa3-20171028" -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] New: running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 Bug ID: 386425 Summary: running valgrind + wine on armv7l gives illegal opcode Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- Every test fails the same way: (stretch)austin@localhost:~/wine-git/dlls/advapi32/tests$ make service.ok ../../../tools/runtest -q -P wine -T ../../.. -M advapi32.dll -p advapi32_test.exe.so service && touch service.ok ==20504== ==20504== Process terminating with default action of signal 4 (SIGILL) ==20504== Illegal opcode at address 0x4FC2C54 ==20504==at 0x4FC2C54: signal_init_thread (signal_arm.c:974) ==20504==by 0x4FCA7CB: thread_init (thread.c:354) ==20504==by 0x4F9F303: __wine_process_init (loader.c:3341) ==20504==by 0x485FBC3: wine_init (loader.c:979) ==20504==by 0x108A27: main (main.c:258) Illegal instruction (core dumped) Makefile:374: recipe for target 'service.ok' failed make: *** [service.ok] Error 132 I reviewed this with the wine ARM maintainer, who pointed out it's likely a valgrind bug. The code in question: https://source.winehq.org/git/wine.git/blob/40b7831cd80607e42b9e1c910a62f022c45ac884:/dlls/ntdll/signal_arm.c#l959 Removing the TEB/TPIDRURW handling get's past this: diff --git a/dlls/ntdll/signal_arm.c b/dlls/ntdll/signal_arm.c index e5e314049e..df050a96ae 100644 --- a/dlls/ntdll/signal_arm.c +++ b/dlls/ntdll/signal_arm.c @@ -968,12 +968,6 @@ void signal_init_thread( TEB *teb ) pthread_key_create( &teb_key, NULL ); init_done = TRUE; } - -#if defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_8A__) -/* Win32/ARM applications expect the TEB pointer to be in the TPIDRURW register. */ -__asm__ __volatile__( "mcr p15, 0, %0, c13, c0, 2" : : "r" (teb) ); -#endif - pthread_setspecific( teb_key, teb ); } and now tests work. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382978] valgrind: LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format
https://bugs.kde.org/show_bug.cgi?id=382978 --- Comment #2 from Austin English --- Forgot to mention in first comment; the PDB format is now publicly documented, at https://github.com/Microsoft/microsoft-pdb -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382515] valgrind: "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/mscoree.c
https://bugs.kde.org/show_bug.cgi?id=382515 Austin English changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #14 from Austin English --- (In reply to Philippe Waroquiers from comment #13) > Thanks for the testing > Patch committed as revision 16465. > > As discussed in comment 12, really handling this kind of debug info > will be another bug (if needed) Fixed in r16465, thanks Philippe. Next bug is bug 382978. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382978] valgrind: LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format
https://bugs.kde.org/show_bug.cgi?id=382978 --- Comment #1 from Austin English --- Created attachment 106999 --> https://bugs.kde.org/attachment.cgi?id=106999&action=edit makecert.pdb I'm also attaching a small pdb file that may be easier to analyze. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382978] New: valgrind: LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format
https://bugs.kde.org/show_bug.cgi?id=382978 Bug ID: 382978 Summary: valgrind: LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- Created attachment 106998 --> https://bugs.kde.org/attachment.cgi?id=106998&action=edit mscorlib.pdb Microsoft's C# compiler (Rosylyn, also used by Mono, https://github.com/dotnet/roslyn/) generates PDBs that are of a different format than those generated by Visual Studio for C/C++. This revealed itself because wine-mono accidentally shipped .pdb files, and running wine's dlls/mscoree/tests/mscoree.c tests crashed valgrind (bug 382515). Now, it ignores those pdb files instead. It would be nice if these files were supported, but at least for Wine, it's probably not worth the effort, as only a tiny part of the code uses it. But if valgrind becomes popular for C#, it may be more important. ==1193== Warning: Missing or un-stat-able /home/austin/.wine/drive_c/windows/mono/mono-2.0/bin/libmono-2.0-x86.pdb ==1193== LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format? ==1193== LOAD_PDB_DEBUGINFO: find_pdb_header found no hdr. possible invalid/unsupported pdb file format? ==1193== LOAD_PDB_DEBUGINFO: failed loading info from /home/austin/.wine/drive_c/windows/mono/mono-2.0/lib/mono/4.5/mscorlib.pdb -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382515] valgrind: "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/mscoree.c
https://bugs.kde.org/show_bug.cgi?id=382515 --- Comment #12 from Austin English --- (In reply to Philippe Waroquiers from comment #11) > Note that the patch is compiling on linux, but is completely untested. > So, expect fire, smoke and explosions ... Thanks Philippe, the patch makes things look much nicer! Here's the output (with wine specific output you don't care about removed): ../../../tools/runtest -q -P wine -T ../../.. -M mscoree.dll -p mscoree_test.exe.so mscoree && touch mscoree.ok ==15080== Warning: Missing or un-stat-able /home/austin/.wine/drive_c/windows/system32/shlwapi.pdb ==15194== Warning: Missing or un-stat-able /home/austin/.wine/drive_c/windows/system32/shlwapi.pdb ==15194== Warning: Missing or un-stat-able /home/austin/.wine/drive_c/windows/mono/mono-2.0/bin/libmono-2.0-x86.pdb ==15194== LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format? ==15194== LOAD_PDB_DEBUGINFO: find_pdb_header found no hdr. possible invalid/unsupported pdb file format? ==15194== LOAD_PDB_DEBUGINFO: failed loading info from /home/austin/.wine/drive_c/windows/mono/mono-2.0/lib/mono/4.5/mscorlib.pdb ==15080== Warning: Missing or un-stat-able /home/austin/.wine/drive_c/windows/mono/mono-2.0/bin/libmono-2.0-x86.pdb ==15080== LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format? ==15080== LOAD_PDB_DEBUGINFO: find_pdb_header found no hdr. possible invalid/unsupported pdb file format? ==15080== LOAD_PDB_DEBUGINFO: failed loading info from /home/austin/.wine/drive_c/windows/mono/mono-2.0/lib/mono/4.5/mscorlib.pdb ==15080== LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format? ==15080== LOAD_PDB_DEBUGINFO: find_pdb_header found no hdr. possible invalid/unsupported pdb file format? ==15080== LOAD_PDB_DEBUGINFO: failed loading info from /home/austin/.wine/drive_c/windows/mono/mono-2.0/lib/mono/gac/Mono.Security/4.0.0.0__0738eb9f132ed756/Mono.Security.pdb the first (missing shlwapi), is valid, wine doesn't build .pdb files for its own dlls. libmono-2.0-x86.pdb is also not included in wine-mono, not sure why it didn't get one when others did, but that's how it is the other two are C# dlls, so the unexpected pdb format makes sense FYI, I've written a patch for this format for `file`, it's header is: BSBJ\001\000\001\000\000\000\000\000\f\000\000\000PDB\ v1.0 though note that the 'v' is case insensitive. As far as I'm concerned, this patch is good enough for now. I'll likely file a follow up bug once this is resolved so that it's known/documented, but I don't think the effort to implement is worth the gain, unless running c# code under valgrind gets popular.. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382515] valgrind: "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/mscoree.c
https://bugs.kde.org/show_bug.cgi?id=382515 --- Comment #8 from Austin English --- (In reply to Philippe Waroquiers from comment #6) > The valgrind code expects something very precise as a header. > See function static void* find_pdb_header( void* pdbimage, > unsigned* signature ) > followed by one of 2 struct (either an old pdb or a new pdb struct). > It looks like the code is not ready at all to read the above. > If only the header (slightly) differs, it might be easy to enhance the > valgrind pdb header. > But if the mscorelib.pdb is very different, then that will be a significant > work. > Note that the readpdb.c seems to be a forked copy of some wine code, as I > understand It seems I misspoke, the pdb comes from mono, via csc/roslyn: http://www.mono-project.com/docs/about-mono/releases/5.0.0/#csc https://github.com/dotnet/roslyn also, note that Microsoft released info about the PDB format a while back for LLVM/Clang, under the MIT license: https://github.com/dotnet/roslyn While getting these pdbs would be cool long term, my immediate concern is valgrind crashing. Printing an error/fixme would be enough for me, for this bug report. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382515] valgrind: "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/mscoree.c
https://bugs.kde.org/show_bug.cgi?id=382515 --- Comment #7 from Austin English --- Created attachment 106926 --> https://bugs.kde.org/attachment.cgi?id=106926&action=edit debug log 2 with --trace-symtab=yes --trace-symtab-patt=*mscorlib* -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382515] valgrind: "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/mscoree.c
https://bugs.kde.org/show_bug.cgi?id=382515 --- Comment #5 from Austin English --- Forgot to say, first line of mingw64's pdb is: BSJB PDB V1.0 first character is \042 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382515] valgrind: "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/mscoree.c
https://bugs.kde.org/show_bug.cgi?id=382515 --- Comment #4 from Austin English --- (In reply to Philippe Waroquiers from comment #3) > This find_pdb_header is searching for a specific character '\032' > and the string "Microsoft C/C++" > Is the pdb file containing the expected pdb header ? No, it does not. These files were produced by mingw64. File considers them data: /home/austin/.wine/drive_c/windows/mono/mono-2.0/lib/mono/4.5/mscorlib.pdb: data whereas real .pdb files from visual studio appear as: ./memory/mozalloc/mozalloc.pdb: MSVC program database ver 7.00, 4096*95 bytes it's produced by Mingw, not Microsoft. Whereas my real pdb's first line is: Microsoft C/C++ MSF 7.00 DS The first hex character is 0x4D, however (maybe I'm misunderstanding what you're asking). FYI, I uploaded the file here: http://austinenglish.com/files/for_valgrind/mscorlib.pdb the genuine pdb files I used are at https://phoenixnap.dl.sourceforge.net/project/wine/Wine%20Gecko/2.36/wine_gecko-2.36-x86-dbg-msvc-pdb.tar.bz2 > I guess wine and/or microsoft-windows have objdump like utilities ? > Or else just look with emacs this pdb and another working pdb, to > see if the expected data is there ? > > Would be good also to redo the tracing above adding something like > --trace-symtab=yes --trace-symtab-patt=*mscorlib* I'll get this in a bit or tomorrow. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382515] valgrind: "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/mscoree.c
https://bugs.kde.org/show_bug.cgi?id=382515 --- Comment #2 from Austin English --- Created attachment 106785 --> https://bugs.kde.org/attachment.cgi?id=106785&action=edit debug log -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382515] New: valgrind: "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/mscoree.c
https://bugs.kde.org/show_bug.cgi?id=382515 Bug ID: 382515 Summary: valgrind: "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/mscoree.c Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- =8481== Warning: Missing or un-stat-able /home/austin/.wine/drive_c/windows/mono/mono-2.0/bin/libmono-2.0-x86.pdb valgrind: m_debuginfo/debuginfo.c:1411 (vgPlain_di_notify_pdb_debuginfo): Assertion 'di->have_dinfo' failed. host stacktrace: ==8481==at 0x580398B9: show_sched_status_wrk (m_libcassert.c:355) ==8481==by 0x580399C1: report_and_quit (m_libcassert.c:426) ==8481==by 0x58039AA3: vgPlain_assert_fail (m_libcassert.c:492) ==8481==by 0x580689A1: vgPlain_di_notify_pdb_debuginfo (debuginfo.c:1411) ==8481==by 0x5808AA4D: do_client_request (scheduler.c:2029) ==8481==by 0x5808AA4D: vgPlain_scheduler (scheduler.c:1433) ==8481==by 0x58098963: thread_wrapper (syswrap-linux.c:103) ==8481==by 0x58098963: run_a_thread_NORETURN (syswrap-linux.c:156) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 8481) ==8481==at 0x7BCAC22A: map_image (virtual.c:1363) ==8481==by 0x7BCB03F2: NtMapViewOfSection (virtual.c:2747) ==8481==by 0x7BC5C2B7: load_native_dll (loader.c:1824) ==8481==by 0x7BC5DDA7: load_dll (loader.c:2334) ==8481==by 0x7BC5E024: LdrLoadDll (loader.c:2367) ==8481==by 0x7B4613D5: load_library (module.c:947) ==8481==by 0x7B461582: LoadLibraryExW (module.c:1007) ==8481==by 0x7B4616BE: LoadLibraryW (module.c:1049) ==8481==by 0x6C663126: ??? Thread 2: status = VgTs_WaitSys (lwpid 8495) ==8481==at 0x424CEEF: ??? (syscall-template.S:84) ==8481==by 0x7BC89730: wait_select_reply (server.c:348) ==8481==by 0x7BC8A49D: server_select (server.c:607) ==8481==by 0x7BC979A8: NtWaitForKeyedEvent (sync.c:1193) ==8481==by 0x7BC98D34: RtlSleepConditionVariableCS (sync.c:1854) ==8481==by 0x7B484166: SleepConditionVariableCS (sync.c:2430) ==8481==by 0x6C762A50: ??? valgrind-3.14.0.SVN-16459-vex-3398 / wine-2.12-205-g9118512135 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 --- Comment #11 from Austin English --- @Henri, I've attached logs use radeonsi_dri.so instead of swrast (which is what I was using before investigating the issue). This contains the repe instruction as before. I've also attached the library itself (built with march), xz compressed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 --- Comment #10 from Austin English --- Created attachment 105950 --> https://bugs.kde.org/attachment.cgi?id=105950&action=edit radeonsi_dri_64.so -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 --- Comment #9 from Austin English --- Created attachment 105949 --> https://bugs.kde.org/attachment.cgi?id=105949&action=edit radeonsi_dri_32.so Had to use xz, bzip2 was over the limit. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 --- Comment #8 from Austin English --- Created attachment 105948 --> https://bugs.kde.org/attachment.cgi?id=105948&action=edit log with march disabled, using radeonsi -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 --- Comment #7 from Austin English --- Created attachment 105947 --> https://bugs.kde.org/attachment.cgi?id=105947&action=edit log with march enabled, using radeonsi -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 --- Comment #6 from Austin English --- So, while testing again, I realized I hadn't rerun the test with software rendering (the full valgrind run and individual test runs are two different scripts, and the later wasn't forcing software mode). The previous (good) run was presumably using radeonsi.so, fwiw. I've updated the individual script and reran, the output is slightly different from the original no march run, but still shows a difference between march and no march. What's interesting, is that with software rendering and march enabled, I get symbols for neither LLVM or mesa. With no march and software rendering, I get symbols for LLVM, but not mesa. I tried running objdump -d/-D, but they are too large to attach, even compressed. The compressed .so files are small enough, so I attached both. This was a 32-bit wine build, so it should be the 32-bit driver, but I've attached both for reference. My end goal is to either not get crashes under valgrind + mesa, or to get useful stacktraces. I'm not particularly tied to radeonsi/software rendering. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 --- Comment #5 from Austin English --- Created attachment 105937 --> https://bugs.kde.org/attachment.cgi?id=105937&action=edit swrast_dir64.so -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 --- Comment #4 from Austin English --- Created attachment 105936 --> https://bugs.kde.org/attachment.cgi?id=105936&action=edit swrast_dir32.so -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 --- Comment #3 from Austin English --- Created attachment 105935 --> https://bugs.kde.org/attachment.cgi?id=105935&action=edit this time, without -march=corei7 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 --- Comment #2 from Austin English --- Created attachment 105934 --> https://bugs.kde.org/attachment.cgi?id=105934&action=edit full bad output -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380869] New: valgrind has issues with mesa comiled with CFLAGS="-march=corei7"
https://bugs.kde.org/show_bug.cgi?id=380869 Bug ID: 380869 Summary: valgrind has issues with mesa comiled with CFLAGS="-march=corei7" Product: valgrind Version: 3.13 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- While running wine's direct3d tests (which invoke OpenGL), I noticed that I got a lot of crashes, with poor debugging info: Backtrace: =>0 0x063bcd77 in swrast_dri.so (+0x59d77) (0x1535f9c0) 1 0x063bd6d9 in swrast_dri.so (+0x5a6d8) (0x) 2 0x063c11de in swrast_dri.so (+0x5e1dd) (0x) 3 0x0659825e in swrast_dri.so (+0x23525d) (0x1535f7f0) 4 0x066dadf3 in swrast_dri.so (+0x377df2) (0x1535f7f0) 5 0x066d9abf in swrast_dri.so (+0x376abe) (0x1535f3a8) 6 0x05cf1959 in libgl.so.1 (+0x3e958) (0x1535f3a8) 7 0x05cca866 glXMakeContextCurrent+0x95() in libgl.so.1 (0x0460c3c0) 8 0x05ccaa86 glXMakeCurrent+0x15() in libgl.so.1 (0x04b8f2d8) 9 0x05935782 X11DRV_WineGL_InitOpenglInfo+0x2fe() [/home/austin/wine-valgrind/dlls/winex11.drv/opengl.c:502] in winex11 (0x04b8f2d8) 10 0x05936f92 init_opengl+0xfbe(once=0x5993e00, param=0x0(nil), context=(nil)) [/home/austin/wine-valgrind/dlls/winex11.drv/opengl.c:679] in winex11 (0x04b8f4e8) This is on gentoo, and llvm/clang/mesa all have USE=debug (mesa also has USE=valgrind enabled). After debugging with some Wine guys, it was pointed out to me that march=native can cause issues. Removing march=core17 from my system CFLAGS and recompiling mesa (nothing else), I got much better info from valgrind: ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so device && touch device.ok preloader: Warning: failed to reserve range 0011-6800 preloader: Warning: failed to reserve range 7f00-8200 ==22129== ==22129== Process terminating with default action of signal 11 (SIGSEGV) ==22129== General Protection Fault ==22129==at 0x7BC8DBC5: setup_exception_record (signal_i386.c:1756) ==22129==by 0x7BC8E8C7: segv_handler (signal_i386.c:2094) ==22129==by 0x42532EF: ??? (in /lib32/libpthread-2.23.so) ==22129== ==22129== Process terminating with default action of signal 11 (SIGSEGV) ==22129== General Protection Fault ==22129==at 0x400E324: _dl_fixup (dl-runtime.c:101) ==22129==by 0x401494F: _dl_runtime_resolve (dl-trampoline.S:43) ==22129==by 0x402556D: _vgnU_freeres (vg_preloaded.c:77) ==22129==by 0x7BC8DB8F: setup_exception_record (signal_i386.c:1756) ==22129==by 0x7BC8E8C7: segv_handler (signal_i386.c:2094) ==22129==by 0x42532EF: ??? (in /lib32/libpthread-2.23.so) ==22129== 8 bytes in 2 blocks are possibly lost in loss record 145 of 3,647 ==22129==at 0x402D2A6: memalign (vg_replace_malloc.c:858) ==22129==by 0x401133C: allocate_and_init (dl-tls.c:603) ==22129==by 0x401133C: tls_get_addr_tail (dl-tls.c:791) ==22129==by 0x4011F81: ___tls_get_addr (dl-tls.c:837) ==22129==by 0x74526E3: __libelf_seterrno (elf_error.c:331) ==22129==by 0x745F549: gelf_getsym (gelf_getsym.c:71) ==22129==by 0x6C64888: parse_symbol_table (radeon_elf_util.c:54) ==22129==by 0x6C64888: radeon_elf_read (radeon_elf_util.c:160) ==22129==by 0x6B93C3D: si_llvm_compile (si_shader_tgsi_setup.c:251) ==22129==by 0x6B8DF9E: si_compile_llvm (si_shader.c:6426) ==22129==by 0x6B8EDC0: si_compile_tgsi_shader (si_shader.c:7631) ==22129==by 0x6BA684F: si_init_shader_selector_async (si_state_shaders.c:1343) ==22129==by 0x68C00EE: util_queue_thread_func (u_queue.c:154) ==22129==by 0x68BFC44: impl_thrd_routine (threads_posix.h:87) ==22129==by 0x4249260: start_thread (pthread_create.c:333) ==22129==by 0x434531D: clone (clone.S:114) ==22129== Let me know if I can provide more info to help debug this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 365327] Support macOS Sierra (10.12)
https://bugs.kde.org/show_bug.cgi?id=365327 --- Comment #15 from Austin English --- (In reply to Louis Brunner from comment #12) > Created attachment 104964 [details] > macOS Sierra incomplete support > > I have been working on a patch to support macOS Sierra. > At the moment, it works for a variety of programs (python, GIMP, most basic > commands like ls, mkdir) but it is still incomplete (warnings in dyld, > libsystem_kernel... crash for some GUI programs). > > The patch adds a few required syscalls with placeholder implementations > (faccessat, fstatat64, csrctl, getentropy and ulock_wake) and the new way of > loading dylib (placing them at the end of the currently loaded segments). > The second change means we need to know where the last segment was loaded, > which means carrying around one more pointer on pointer in every function > (which already have 6-9 arguments), that's why I created a structure > (load_info_t) to store all this information and easily carry it around. > > It also adds one assert in is_in_syscall in > coregrind/m_syswrap/syswrap-main.c to match the other syscall related > functions in the same file. I had a difficult to diagnose crash in this > function because it didn't check for the existence of the syscall table. > > Tell me if you need any change I can confirm that the situation is improved on 10.12 with this patch. E.g., valgrind will at least attempt things now. I noticed that `./vg-in-place ls -al` crashes valgrind, though `./vg-in-place true` works fine (does show some uninitialized memory in OSX though). A basic sanity check on 10.11 also worked for me. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 365327] Support macOS Sierra (10.12)
https://bugs.kde.org/show_bug.cgi?id=365327 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339017] (meta) Valgrind 3.10 cannot load wine on OS X
https://bugs.kde.org/show_bug.cgi?id=339017 --- Comment #10 from Austin English --- (In reply to Rhys Kidd from comment #8) > We have another user, Austin, who is testing some Wine-specific patches and > will aim to run Wine's unit tests under Valgrind shortly. > > The result of that testing will be instructive for the status of our Wine > support with Valgrind. With wine-2.1-153-g9c72376, and valgrind-3.13.0.SVN-16222-vex-3303, every Wine unit test fails due to bug 349804. This occurs with 32 and 64-bit Wine. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 349804] wine/osx: mmap-FIXED(0x1000, 1073741824) failed in UME (load_segment2)
https://bugs.kde.org/show_bug.cgi?id=349804 --- Comment #10 from Austin English --- (In reply to Austin English from comment #9) > (In reply to Austin English from comment #8) > > Created attachment 94210 [details] > > wine+valgrind output > > > > Using wine-1.7.50-26-g6038e2a and valgrind-3.11.0-SVN-r15588. > > With wine-2.1-153-g9c72376, and valgrind-3.13.0.SVN-16222-vex-3303, every > wine unit test fails with: > > ../../../tools/runtest -q -P wine -T ../../.. -M advapi32.dll -p > advapi32_test.exe.so cred && touch cred.ok > valgrind: mmap-FIXED(0x0, 253952) failed in UME (load_segment1) with error > 12 (Cannot allocate memory). > make[1]: *** [cred.ok] Error 1 I also just confirmed that modern wine does work on OSX in 64-bit mode, but it has the same issue: ../../../tools/runtest -q -P wine -T ../../.. -M advapi32.dll -p advapi32_test.exe.so cred && touch cred.ok valgrind: mmap-FIXED(0x0, 253952) failed in UME (load_segment1) with error 12 (Cannot allocate memory). make[1]: *** [cred.ok] Error 1 To be clear, while getting this working for 64-bit would be great, my main interest is 32-bit. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 349804] wine/osx: mmap-FIXED(0x1000, 1073741824) failed in UME (load_segment2)
https://bugs.kde.org/show_bug.cgi?id=349804 --- Comment #9 from Austin English --- (In reply to Austin English from comment #8) > Created attachment 94210 [details] > wine+valgrind output > > Using wine-1.7.50-26-g6038e2a and valgrind-3.11.0-SVN-r15588. With wine-2.1-153-g9c72376, and valgrind-3.13.0.SVN-16222-vex-3303, every wine unit test fails with: ../../../tools/runtest -q -P wine -T ../../.. -M advapi32.dll -p advapi32_test.exe.so cred && touch cred.ok valgrind: mmap-FIXED(0x0, 253952) failed in UME (load_segment1) with error 12 (Cannot allocate memory). make[1]: *** [cred.ok] Error 1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #14 from Austin English --- (In reply to Austin English from comment #13) > This is also relevant again for wine-gecko. Upstream Firefox moved to > require Visual Studio 2013+, and those newer format PDBs don't work with > Wine: > https://bugs.winehq.org/show_bug.cgi?id=37746 > https://bugs.winehq.org/show_bug.cgi?id=38594 > https://bugs.winehq.org/show_bug.cgi?id=38604 Still present in wine-2.1 / valgrind-3.13.0.SVN-16222-vex-3303 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 295084] Hard-coded /usr/include
https://bugs.kde.org/show_bug.cgi?id=295084 --- Comment #10 from Austin English --- (In reply to Rhys Kidd from comment #9) > I'm almost certain there's a problem with your local copy of Xcode or with > multiple versions of Xcode tripping up. > > It's well documented that /usr/include is not present by default on recent > macOS, but is created via: > > $ xcode-select --install > > See further, as examples: > [0] > https://superuser.com/questions/995360/missing-usr-include-in-os-x-el-capitan > [1] https://discussions.apple.com/thread/7124628?start=0&tstart=0 Which is my point. If it's not present by default, it shouldn't be used. It's not included by default because there can be multiple versions of the SDK installed. Using the tip from https://stackoverflow.com/questions/6715454/what-is-the-default-path-for-osx-system-include-files-when-building-a-c-applic: $ echo "" | gcc -xc - -v -E On linux: ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include-fixed /usr/include End of search list. on mac: #include "..." search starts here: #include <...> search starts here: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.0.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks (framework directory) End of search list. and indeed, I have a copy of mach_vm.defs in: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/mach I have run xcode-select --install in the past (which is why I have git and other tools available, which work without /usr/include). I suspect the link was severed during an OS or SDK upgrade, but that's only speculating. If I re-run xcode-select --install, /usr/include exists and valgrind does compile. I still think it's a hack though, as this likely will break if someone tries to compile against a non-default SDK. Not to mention that it will presumably break in a future update, again. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 376027] New: wine's comdlg32/filedlg.c test hangs under valgrind
https://bugs.kde.org/show_bug.cgi?id=376027 Bug ID: 376027 Summary: wine's comdlg32/filedlg.c test hangs under valgrind Product: valgrind Version: 3.13 SVN Platform: Compiled Sources URL: https://bugs.winehq.org/show_bug.cgi?id=39097 OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com CC: sebast...@fds-team.de Target Milestone: --- Hi there, This bug has been discussed a bit on #valgrind-dev already, but I wanted to make sure it wasn't forgotten ;). This bug is 100% reproducible for me on my Gentoo desktop. Sebastian (author of the wine commit that revealed it), has been unable to reproduce. This issue occurs when running wine's unit tests under valgrind. Sebastian's patch: https://source.winehq.org/git/wine.git/commitdiff/4a1629c4117fda9eca63b6f56ea45771dc9734ac which changes wine's NtTerminateProcess() to use _exit() instead of exit(). With this change, wine's unit tests will hang after completing the comdlg32/fildlg tests. When I added printf's to the code, I noticed that the tests all complete (i.e., it's not hanging in the middle of one), but wine doesn't continue on to the next test afterward. To reproduce: For info on running wine under valgrind, see: https://wiki.winehq.org/Wine_and_Valgrind my scripts/suppression files are at: https://github.com/austin987/wine_misc/tree/master/valgrind but in short: # get wine/wine_misc repos $ cd wine-valgrind $ ln -s /path/to/wine_misc/valgrind tools/valgrind $ ./configure && make -j8 $ vi tools/valgrind/vg-wrapper.sh # edit paths to wine/valgrind, if needed $ . tools/valgrind/vg-wrapper.sh $ ./wine start /min notepad $ cd dlls/comdgl32/tests $ make filedlg.ok # BUG Though since Sebastian can't reproduce, it may be something peculiar to my system..This was most recently tested with valgrind-3.13.0.SVN-16204-vex-3299 / wine-2.0 and 2.1 I'm not sure what other information would be helpful here. I found a similar valgrind bug, which is marked fixed (https://bugs.kde.org/show_bug.cgi?id=372504), and may valgrind version is newer than that. This bug is a blocker for wine/valgrind (I have to revert that patch in wine to be able to run the tests). Please let me know what information, if any, would be helpful in resolving this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 350228] Unhandled ioctl 0x6458 (i965/mesa)
https://bugs.kde.org/show_bug.cgi?id=350228 Austin English changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Austin English --- I asked in the intel-gfx and xorg IRC channels about these ioctls, and the answers were basically "try newer Valgrind" and "look at the source..oh they're not there, macros are a hell of a drug," so I don't expect upstream to be very helpful. Given that I no longer have access to this hardware, I'm just going to close this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 354809] Error message for unsupported platform is unhelpful
https://bugs.kde.org/show_bug.cgi?id=354809 --- Comment #1 from Austin English --- With: austin@debian-laptop:~/src/valgrind$ ./vg-in-place --version -v valgrind-3.13.0.SVN-16209-vex-3299 the error message has improved (64-bit valgrind, 32-bit binary): austin@debian-laptop:~/src/valgrind$ ./vg-in-place /tmp/a.out valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory Recompiling as 64-bit binary: austin@debian-laptop:~/src/valgrind$ ./vg-in-place /tmp/a.out ==19785== Memcheck, a memory error detector ==19785== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==19785== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info ==19785== Command: /tmp/a.out ==19785== Alive==19785== ==19785== HEAP SUMMARY: ==19785== in use at exit: 0 bytes in 0 blocks ==19785== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==19785== ==19785== All heap blocks were freed -- no leaks are possible ==19785== ==19785== For counts of detected and suppressed errors, rerun with: -v ==19785== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Fixed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 344139] vex x86->IR: unhandled instruction bytes: 0x36 0x8A 0x18 0x22 (and many other examples)
https://bugs.kde.org/show_bug.cgi?id=344139
--- Comment #2 from Austin English ---
To give a bit more info (and for myself in the future ;).
This is still present in development wine (wine-1.9.24-105-g1d3b944) and
valgrind (valgrind-3.13.0.SVN, #define VGSVN "16171", #define VEXSVN "3285").
It's not reproducible with every wine unit tests. The first case I found was
dlls/advapi32/tests/service.c.
For info on running wine under valgrind, see:
https://wiki.winehq.org/Wine_and_Valgrind
my scripts/suppression files are at:
https://github.com/austin987/wine_misc/tree/master/valgrind
but in short:
# get wine/wine_misc repos
$ cd wine-valgrind
$ ln -s /path/to/wine_misc/valgrind tools/valgrind
$ ./configure && make -j8
$ vi tools/valgrind/vg-wrapper.sh
# edit paths to wine/valgrind, if needed
$ . tools/valgrind/vg-wrapper.sh
$ ./wine start /min notepad
$ cd dlls/advapi32/tests
$ make service.ok
# BUG
If the bug is present, you should see:
../../../tools/runtest -q -P wine -T ../../.. -M advapi32.dll -p
advapi32_test.exe.so service && touch service.ok
preloader: Warning: failed to reserve range 0011-6800
preloader: Warning: failed to reserve range 7f00-8200
err:rpc:I_RpcGetBuffer no binding
err:seh:segv_handler Got unexpected trap 0
wine: Unhandled illegal instruction at address 0x7bc280f5 (thread 006d),
starting debugger...
preloader: Warning: failed to reserve range 0011-6800
preloader: Warning: failed to reserve range 7f00-8200
the key lines being:
err:seh:segv_handler Got unexpected trap 0
wine: Unhandled illegal instruction at address 0x7bc280f5 (thread 006d),
starting debugger...
at that point, it will hang indefinitely.
With a patch from Sebastian (for Wine):
diff --git a/dlls/ntdll/signal_i386.c b/dlls/ntdll/signal_i386.c
index 59dca6c..a8cdb96 100644
--- a/dlls/ntdll/signal_i386.c
+++ b/dlls/ntdll/signal_i386.c
@@ -2076,6 +2076,15 @@ static void segv_handler( int signal, siginfo_t
*siginfo, void *sigcontext )
return;
}
+if (!get_trap_code(context) &&
+siginfo->si_addr == (void *)EIP_sig(context) &&
+*(char *)EIP_sig(context) == 0x36)
+{
+FIXME("---> working around Valgrind SIGILL exception\n");
+EIP_sig(context)++;
+return;
+}
+
/* check for page fault inside the thread stack */
if (get_trap_code(context) == TRAP_x86_PAGEFLT &&
(char *)siginfo->si_addr >= (char *)NtCurrentTeb()->DeallocationStack
&&
the tests will pass and not hang.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 --- Comment #29 from Austin English --- (In reply to Philippe Waroquiers from comment #28) > Strange that the git-svn version does not show a M(odified) marker. Yeah, I noticed that too. I'll try to remember to file a bug upstream. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 295084] Hard-coded /usr/include
https://bugs.kde.org/show_bug.cgi?id=295084 --- Comment #8 from Austin English --- To be more explicit: Austins-Mac-mini:~ austin$ xcode-select --install xcode-select: note: install requested for command line developer tools Austins-Mac-mini:~ austin$ ls /usr/ X11 adicbin lib libexec local sbinshare standalone /usr/include is _not_ there by default, at least on Sierra, and likely other versions. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 295084] Hard-coded /usr/include
https://bugs.kde.org/show_bug.cgi?id=295084 --- Comment #7 from Austin English --- (In reply to Rhys Kidd from comment #6) > Austin, > > Before you do, can you please confirm that you have the latest Xcode Command > Line Tools installed? It is incremental on top of the basic Xcode package > installed. > > Can be installed via: > > $ xcode-select --install Yes, they are, otherwise I wouldn't be able to compile wine from the command line / use git ;) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 295084] Hard-coded /usr/include
https://bugs.kde.org/show_bug.cgi?id=295084 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com --- Comment #5 from Austin English --- (In reply to Rhys Kidd from comment #4) > I don't think this is a valid fix, as you're patching the automake generated > Makefile (not the original from SVN). > > Regardless, the underlying issue is not present on current OS X (10.9) and > Xcode 6 with its standard development environment. I'm seeing this exact issue in OS X Sierra (10.12.1), with valgrind from SVN (valgrind-3.13.0.SVN-16159-vex-3285) and Xcode 8.1. /usr/include does not exist on the machine. It's strange to me as a linux guy, but that's how it is. The actual headers are under: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/ I'm able to compile software with homebrew. I'm also able to compile wine from git (not using homebrew), which also uses autoconf, so it's certainly possible to build software on OS X without /usr/include existing (wine also uses headers from mach/, but not the same ones as valgrind). I'll take a look at rebasing / fixing Samuel's patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 354809] Error message for unsupported platform is unhelpful
https://bugs.kde.org/show_bug.cgi?id=354809 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 --- Comment #27 from Austin English --- (In reply to Austin English from comment #26) > Created attachment 102512 [details] > try 10, extra sanity checks > > try 9 works for me, but I put some extra sanity checks in. In theory, > someone could have valgrind from svn, and VEX in git svn, or vice versa, and > try 9 would break with that. > > I also added '|| exit 1' to the cd command, as a sanity check / to satisfy > shellcheck. Note: version differences aren't a bug, just checked out at different times and I was too lazy to sync them :) Gentoo/AMD64: linux-svn: valgrind-3.13.0.SVN-16159M-vex-3285 linux-git-svn: valgrind-3.12.0.SVN-16107-vex-3276 OS X Sierra: mac-svn: valgrind-3.13.0.SVN-16159M-vex-3285 mac-git-svn: valgrind-3.12.0.SVN-16107-vex-3276 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 --- Comment #26 from Austin English --- Created attachment 102512 --> https://bugs.kde.org/attachment.cgi?id=102512&action=edit try 10, extra sanity checks try 9 works for me, but I put some extra sanity checks in. In theory, someone could have valgrind from svn, and VEX in git svn, or vice versa, and try 9 would break with that. I also added '|| exit 1' to the cd command, as a sanity check / to satisfy shellcheck. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 --- Comment #22 from Austin English --- (In reply to Ivo Raisr from comment #20) > Patch #6 seems to be working well. I tested it on Solaris, inside SVN tree, > outside and after 'make dist'. > > In addition to the last comment by Austin, please change also: > > auxprogs/make_or_upd_vgversion_h: > - when using command lines options: -v --version > + when using command line options: -v --version > > and make sure that auxprogs/make_or_upd_vgversion_h is marked as executable > in SVN repository. Yeah, it fails for me out of the box, with: echo "# This is a generated file, composed of the following suppression rules:" > default.supp auxprogs/make_or_upd_vgversion_h make: execvp: auxprogs/make_or_upd_vgversion_h: Permission denied Makefile:1374: recipe for target 'vgversion.h' failed make: *** [vgversion.h] Error 127 make: *** Waiting for unfinished jobs echo "# " exp-sgcheck.supp xfree-3.supp xfree-4.supp glibc-2.X-drd.supp glibc-2.34567-NPTL-helgrind.supp glibc-2.X.supp >> default.supp cat exp-sgcheck.supp xfree-3.supp xfree-4.supp glibc-2.X-drd.supp glibc-2.34567-NPTL-helgrind.supp glibc-2.X.supp >> default.supp chmod +x auxprogs/make_or_upd_vgversion_h gets past that problem. Next, it fails for VEX, with git svn: valgrind-3.12.0.SVN-16107-vex- +git svn info $1 | grep '^Revision' | cut -d ' ' -f2 | tr -d '\n' won't work the way you expect. It needs to be in the VEX directory for this to work: austin@austin2:~/src/valgrind-git$ git svn info | grep Revision Revision: 16107 austin@austin2:~/src/valgrind-git$ git svn info VEX | grep Revision svn: 'VEX' is not under version control austin@austin2:~/src/valgrind-git$ cd VEX && git svn info | grep Revision Revision: 3276 FYI, I can also text on OSX (once these issues are sorted out ;) ). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 --- Comment #17 from Austin English --- (In reply to Philippe Waroquiers from comment #16) > Created attachment 102468 [details] > try 6 : modified to have vgversion.h also handled as part of make dist > > Changed compared to try5: > * vgversion.h make or update logic moved > from Makefile.am to auxprogs/make_or_upd_vgversion_h > * added dist-hook to copy vgversion.h > > I have tested this (on linux debian 8 amd64) in a 'in place' build, > and in a build from a make dist. I have checked that the dist contains > vgversion.h. I have also tested that outside svn, vgversion.h is created > with unknown svn versions, but that it is not replaced if it already exists. > > Would be nice to do some more tests before commit > (e.g. on other OS solaris, macos) Thanks for working on that Philippe! You've got a syntax error here: +elif [ -d .git/svn ] +git svn info $1 | grep '^Revision' | cut -d ' ' -f2 | tr -d '\n' +then +echo "unknown" +fi +} should be elif ; then ; else -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 --- Comment #13 from Austin English --- (In reply to Austin English from comment #12) > How commonly are tarballs created/used for random SVN revisions rather than > releases? > > To be frank, I'm not very experienced with makefiles, and the current > changes have already been a pain. I don't particularly feel like revamping > it a 6th time for a corner case that doesn't currently work to begin with. It seems to be currently broken, for that matter: $ make dist ... export XML_CATALOG_FILES=/etc/xml/catalog && \ mkdir -p ../docs/print && \ mkdir -p ../docs/print/images && \ cp ../docs/images/*.png ../docs/print/images && \ xsltproc --nonet --xinclude -o ../docs/print/index.fo ../docs/lib/vg-fo.xsl ../docs/xml/index.xml && \ (cd ../docs/print && \ ( pdfxmltex index.fo && \ pdfxmltex index.fo && \ pdfxmltex index.fo ) &> print.log < /dev/null && \ echo "Generating PS file: ../docs/print/index.ps ..." && \ pdftops index.pdf && \ rm -f *.log *.aux *.fo *.out) Making portrait pages on USletter paper (8.5inx11in) Makefile:642: recipe for target 'print-docs' failed make[3]: *** [print-docs] Error 127 make[3]: Leaving directory '/tmp/valgrind/docs' Makefile:450: recipe for target 'distdir' failed make[2]: *** [distdir] Error 2 make[2]: Leaving directory '/tmp/valgrind/docs' Makefile:930: recipe for target 'distdir' failed make[1]: *** [distdir] Error 1 make[1]: Leaving directory '/tmp/valgrind' Makefile:1028: recipe for target 'dist' failed make: *** [dist] Error 2 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 --- Comment #12 from Austin English --- How commonly are tarballs created/used for random SVN revisions rather than releases? To be frank, I'm not very experienced with makefiles, and the current changes have already been a pain. I don't particularly feel like revamping it a 6th time for a corner case that doesn't currently work to begin with. -- You are receiving this mail because: You are watching all bug changes.
