[filelight] [Bug 427185] Filelight seg faults with qt5ct installed
https://bugs.kde.org/show_bug.cgi?id=427185 Austin Kilgore changed: What|Removed |Added Summary|Filelight crashed when |Filelight seg faults with |starting application|qt5ct installed -- 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.
[filelight] [Bug 415732] Filelight 19.12.0-1 in Arch Linux Fails to Launch with qt5ct
https://bugs.kde.org/show_bug.cgi?id=415732 Austin Kilgore changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #5 from Austin Kilgore --- Just tested, it is working as of filelight version 20.11.80. System specs: Arch Linux 5.9.8-zen1-1-zen. -- 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 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 #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 #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 #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 #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 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 #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 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.
[ksysguard] [Bug 455346] New: KSysGuard: Detailed Memory Information window - "Save page" and "View page source" not working
https://bugs.kde.org/show_bug.cgi?id=455346 Bug ID: 455346 Summary: KSysGuard: Detailed Memory Information window - "Save page" and "View page source" not working Product: ksysguard Version: 5.24.5 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ksysguard Assignee: ksysguard-b...@kde.org Reporter: austinkee...@pm.me CC: plasma-b...@kde.org Target Milestone: --- Created attachment 149750 --> https://bugs.kde.org/attachment.cgi?id=149750&action=edit The right-click menu within the Detailed Memory Information window. SUMMARY In KSysGuard, you can right-click on a process and select "Detailed Memory Information" to open a new window that gives extensive information about the memory profile of the process. Right clicking on this window provides multiple options, two of which are "Save page" and "View page source". Clicking on either of these options does not appear to do anything. The options list just closes. I am not sure what the expected behavior is. I have never seen this feature work. STEPS TO REPRODUCE 1. Open KSysGuard. 2. View the Process Table tab. 3. Right click on a process and select "Detailed Memory Information". A new window opens. 4. Within the Detailed memory Information window, right-click and select either "Save page" or "View page source" from the list of options that appears. 5. The options list closes. Nothing appears to have happened. OBSERVED RESULT After selecting either "Save page" or "View page source", the options list closes, and nothing happens. EXPECTED RESULT I am unsure of the specifics because I have never seen this feature working. However, for "Save page" I would expect a file manager window to open, giving me an option to save a file containing the information displayed within the Detailed Memory Information window. For "View page source" I would expect to be shown the Detailed Memory Information window's XML (or whatever markup language used). SOFTWARE/OS VERSIONS Windows: NA macOS: NA Linux/KDE Plasma: Manjaro 5.15.45-1 / Plasma 5.24.5 (available in About System) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[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.
[kdeconnect] [Bug 477104] KDE Connect crashes after Bluetooth headphones power off (workaround: disable "System volume" plugin on desktop)
https://bugs.kde.org/show_bug.cgi?id=477104 Nick Austin changed: What|Removed |Added CC||n...@smartaustin.com -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 477104] KDE Connect crashes after Bluetooth headphones power off (workaround: disable "System volume" plugin on desktop)
https://bugs.kde.org/show_bug.cgi?id=477104 --- Comment #23 from Nick Austin --- Created attachment 165551 --> https://bugs.kde.org/attachment.cgi?id=165551&action=edit New crash information added by DrKonqi kdeconnectd (23.08.4) using Qt 5.15.12 I disconnected my Sony WH-CH720N headphones using the disconnect button in the bluetooth control widget in KDE. -- Backtrace (Reduced): #4 0x7fb3dc48de17 in PulseAudioQt::CardPrivate::update (this=0x5630d0b97050, info=) at /usr/src/debug/pulseaudio-qt-1.3-5.fc39.x86_64/src/card.cpp:72 #5 0x7fb3dc43ed9f in context_get_card_info_callback (pd=pd@entry=0x5630d0b37720, command=command@entry=2, tag=tag@entry=584, t=t@entry=0x5630d0a1ed90, userdata=userdata@entry=0x5630d09036f0) at ../src/pulse/introspect.c:990 #6 0x7fb3dc3d7588 in run_action (pd=0x5630d0b37720, r=0x5630d0e25a80, command=2, ts=0x5630d0a1ed90) at ../src/pulsecore/pdispatch.c:291 #7 0x7fb3dc3dbb1c in pa_pdispatch_run (pd=0x5630d0b37720, packet=packet@entry=0x5630d0970730, ancil_data=ancil_data@entry=0x5630d0c58278, userdata=userdata@entry=0x5630d0c77d60) at ../src/pulsecore/pdispatch.c:344 #8 0x7fb3dc42d1ab in pstream_packet_callback (p=, packet=0x5630d0970730, ancil_data=0x5630d0c58278, userdata=0x5630d0c77d60) at ../src/pulse/context.c:364 -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 477377] New: Is there a specific reason why Environment Canada engine uses HTTP and not HTTPS?
https://bugs.kde.org/show_bug.cgi?id=477377 Bug ID: 477377 Summary: Is there a specific reason why Environment Canada engine uses HTTP and not HTTPS? Classification: Plasma Product: kdeplasma-addons Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Weather Assignee: plasma-b...@kde.org Reporter: i...@austinhuang.me Target Milestone: --- SUMMARY https://invent.kde.org/plasma/plasma-workspace/-/blob/master/dataengines/weather/ions/envcan/ion_envcan.cpp Sometimes (exact conditions unclear but it does happen in a variety of them) I can't connect to them at all, despite being able to manually visit the URLs in the source code. So I suspect that the program is not following 301 redirects...? STEPS TO REPRODUCE 1. Attempt to search for Canadian locations. 2. 3. OBSERVED RESULT Environment Canada locations don't show up. EXPECTED RESULT Environment Canada locations should show up. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux ARM 6.5.0-asahi-15-1-edge-ARCH (64-bit) (available in About System) KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 477377] Is there a specific reason why Environment Canada engine uses HTTP and not HTTPS?
https://bugs.kde.org/show_bug.cgi?id=477377 --- Comment #1 from Austin Huang --- Please ignore my initial comment, it does seem to be dependent on network conditions. -- 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.
[Haruna] [Bug 476577] New: Setting maximum recent files to 0 still stores 1 file
https://bugs.kde.org/show_bug.cgi?id=476577 Bug ID: 476577 Summary: Setting maximum recent files to 0 still stores 1 file Classification: Applications Product: Haruna Version: 0.12.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: generic Assignee: georgefb...@gmail.com Reporter: austinkee...@pm.me Target Milestone: --- Created attachment 162878 --> https://bugs.kde.org/attachment.cgi?id=162878&action=edit Shows the settings and harunarc SUMMARY In Settings > General the "Maximum recent files" can be set to 0. After watching a video, File > Recent Files is empty, however .config/harunarc shows the recent video and url. Watching a subsequent video does not update the entry. STEPS TO REPRODUCE 1. In Settings > General, set "Maximum recent files" to 0. 2. Watch a video 3. View the File > Recent menu. There are no entries. 4. View .config/harunarc. The file name and url of the video is listed. 5. Watch a different video. 6. File > Recent is still empty. 7. The file and url from the first video remains the same. OBSERVED RESULT .config/harunarc shows the file and url of the first video watched. EXPECTED RESULT .config/harunarc should not show any file or url history SOFTWARE/OS VERSIONS Linux Kernel: 6.5.0-10-generic (64-bit) KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 476577] Setting maximum recent files to 0 still stores 1 file
https://bugs.kde.org/show_bug.cgi?id=476577 Austin Keeton changed: What|Removed |Added Platform|Other |Kubuntu -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 476577] Setting maximum recent files to 0 still stores 1 file
https://bugs.kde.org/show_bug.cgi?id=476577 --- Comment #2 from Austin Keeton --- Thank you, but maybe I wasn't clear in my description because it doesn't seem like intended behavior. Let me try again: 1. Both File > Recent and .config/harunarc do not show any files or urls 2. Set the Maximum recent files to 0 3. Watch a video and close Haruna 4. File > Recent remains empty 5. .config/harunarc now shows the file and url It seems like since harunarc had no history to begin with that it shouldn't have added an entry at all. -- You are receiving this mail because: You are watching all bug changes.
[Haruna] [Bug 476577] Setting maximum recent files to 0 still stores 1 file
https://bugs.kde.org/show_bug.cgi?id=476577 Austin Keeton changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #4 from Austin Keeton --- Upgrading to 0.12.2 fixed the issue. I apologize for the trouble. -- You are receiving this mail because: You are watching all bug changes.
[NeoChat] [Bug 476731] New: Room preview: username height affects room avatar height, breaking layout
https://bugs.kde.org/show_bug.cgi?id=476731 Bug ID: 476731 Summary: Room preview: username height affects room avatar height, breaking layout Classification: Applications Product: NeoChat Version: 23.08.2 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: fe...@posteo.de Reporter: i...@austinhuang.me CC: c...@carlschwan.eu Target Milestone: --- Created attachment 162961 --> https://bugs.kde.org/attachment.cgi?id=162961&action=edit The extreme scenario where someone put linebreaks in their display name, severely breaking the layout SUMMARY In a room preview, if the last author's display name has emojis or, in extreme cases, line breaks, then their display name would take more space vertically. The room preview does not seem to account for this, so if the display name's space is stretched, then it will also stretch the room icon on the left. STEPS TO REPRODUCE 1. Be in a room where someone has a display name that either contains an emoji or line breaks. 2. Let them send the latest message. OBSERVED RESULT It stretches the entire space for that room's preview. Notably it stretches the room avatar. EXPECTED RESULT The space taken by each room is constant. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch ARM (Asahi Linux) KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[NeoChat] [Bug 476731] Room preview: username height affects room avatar height, breaking layout
https://bugs.kde.org/show_bug.cgi?id=476731 --- Comment #1 from Austin Huang --- Created attachment 162962 --> https://bugs.kde.org/attachment.cgi?id=162962&action=edit The usual scenario where one has emojis in display name -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 476737] New: Plasma crashed (and reset) itself a few moments after sleep
https://bugs.kde.org/show_bug.cgi?id=476737 Bug ID: 476737 Summary: Plasma crashed (and reset) itself a few moments after sleep Classification: Plasma Product: plasmashell Version: 5.27.5 Platform: Debian stable OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: starzainia5...@gmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 Application: plasmashell (5.27.5) Qt Version: 5.15.8 Frameworks Version: 5.103.0 Operating System: Linux 6.1.0-13-amd64 x86_64 Windowing System: X11 Distribution: Debian GNU/Linux 12 (bookworm) DrKonqi: 5.27.5 [CoredumpBackend] -- Information about the crash: I had just ejected a USB drive and closed down my windows when Plasma suddenly crashed, I don't really know if this is gonna be fixed, but I hope this report does something. The reporter is unsure if this crash is reproducible. -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault PID: 1183 (plasmashell) UID: 1000 (starzainia) GID: 1000 (starzainia) Signal: 11 (SEGV) Timestamp: Thu 2023-11-09 01:01:32 EST (39s ago) Command Line: /usr/bin/plasmashell --no-respawn Executable: /usr/bin/plasmashell Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/plasma-plasmashell.service Unit: user@1000.service User Unit: plasma-plasmashell.service Slice: user-1000.slice Owner UID: 1000 (starzainia) Boot ID: 0046674693594c1199ca3af3121bc8ef Machine ID: c21971c1e67944b4a47923f641b117aa Hostname: zanaris Storage: /var/lib/systemd/coredump/core.plasmashell.1000.0046674693594c1199ca3af3121bc8ef.1183.169950969200.zst (present) Size on Disk: 20.8M Message: Process 1183 (plasmashell) of user 1000 dumped core. Module libsystemd.so.0 from deb systemd-252.17-1~deb12u1.amd64 Module libudev.so.1 from deb systemd-252.17-1~deb12u1.amd64 Stack trace of thread 1183: #0 0x7fd1a70a9d3c n/a (libc.so.6 + 0x8ad3c) #1 0x7fd1a705af32 raise (libc.so.6 + 0x3bf32) #2 0x7fd1a9746b46 _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 0x5b46) #3 0x7fd1a705afd0 n/a (libc.so.6 + 0x3bfd0) #4 0x7fd1a70a9d3c n/a (libc.so.6 + 0x8ad3c) #5 0x7fd1a705af32 raise (libc.so.6 + 0x3bf32) #6 0x7fd1a705afd0 n/a (libc.so.6 + 0x3bfd0) #7 0x7fd1a70a4da4 n/a (libc.so.6 + 0x85da4) #8 0x7fd1a70a7468 pthread_cond_wait (libc.so.6 + 0x88468) #9 0x7fd1a72d1a2b _ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt5Core.so.5 + 0xd1a2b) #10 0x7fd1a920bd58 n/a (libQt5Quick.so.5 + 0x20bd58) #11 0x7fd1a9276e20 _ZN12QQuickWindow5eventEP6QEvent (libQt5Quick.so.5 + 0x276e20) #12 0x7fd1a8362fae _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 + 0x162fae) #13 0x7fd1a74b16f8 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 0x2b16f8) #14 0x7fd1a792c4b3 _ZN15QPlatformWindow11windowEventEP6QEvent (libQt5Gui.so.5 + 0x12c4b3) #15 0x7fd1a836a1f9 _ZN12QApplication6notifyEP7QObjectP6QEvent (libQt5Widgets.so.5 + 0x16a1f9) #16 0x7fd1a74b16f8 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 0x2b16f8) #17 0x7fd1a7508c31 _ZN14QTimerInfoList14activateTimersEv (libQt5Core.so.5 + 0x308c31) #18 0x7fd1a75094c4 n/a (libQt5Core.so.5 + 0x3094c4) #19 0x7fd1a5f797a9 g_main_context_dispatch (libglib-2.0.so.0 + 0x547a9) #20 0x7fd1a5f79a38 n/a (libglib-2.0.so.0 + 0x54a38) #21 0x7fd1a5f79acc g_main_context_iteration (libglib-2.0.so.0 + 0x54acc) #22 0x7fd1a7509836 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x309836) #23 0x7fd1a74b017b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2b017b) #24 0x7fd1a74b82d6 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2b82d6) #25 0x55aa382fadc3 n/a (plasmashell + 0x26dc3) #26 0x7fd1a70461ca n/a (libc.so.6 + 0x271ca) #27 0x7fd1a7046285 __libc_start_main (libc.so.6 + 0x27285) #28 0x55aa382faee1 n/a (plasmashell + 0x26ee1) Stack trace of thread 1219: #0 0x7fd1a711b05f __poll (libc.so.6 + 0xfc05f) #1 0x7f
[NeoChat] [Bug 476731] Room preview: username height affects room avatar height, breaking layout
https://bugs.kde.org/show_bug.cgi?id=476731 --- Comment #3 from Austin Huang --- Extracted from membership state events: "Access forbidden!\n\nYou don't have permission to access the requested directory. There is either no index document or the directory is read-protected.\n\nIf you think this is a server error, please contact the webmaster.\nError 403\nlocalhost\nApache” So it’s literally \n > On Nov 11, 2023, at 18:55, Tobias Fella wrote: > > https://bugs.kde.org/show_bug.cgi?id=476731 > > Tobias Fella changed: > > What|Removed |Added > > Status|REPORTED|NEEDSINFO > Resolution|--- |WAITINGFORINFO > > --- Comment #2 from Tobias Fella --- > do you know which character exactly is used as a linebreak here? for the usual > candidates, this is already filtered out, so it's probably something more > exotic, maybe unicode > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[NeoChat] [Bug 476731] Room preview: username height affects room avatar height, breaking layout
https://bugs.kde.org/show_bug.cgi?id=476731 Austin Huang changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- -- You are receiving this mail because: You are watching all bug changes.
[NeoChat] [Bug 476731] Room preview: username height affects room avatar height, breaking layout
https://bugs.kde.org/show_bug.cgi?id=476731 --- Comment #5 from Austin Huang --- It’s a user display name, not a room topic/name. -- You are receiving this mail because: You are watching all bug changes.
[NeoChat] [Bug 476731] Room preview: username height affects room avatar height, breaking layout
https://bugs.kde.org/show_bug.cgi?id=476731 --- Comment #8 from Austin Huang --- But I also mentioned that putting some unicode characters also affect the height of the last author field in room previews. Element seems to just cut off the extra height for this. I don’t know if it’s my issue (sorry I’m new to Linux lol) of not installing a font, but fixing the height of the field could be considered. -- You are receiving this mail because: You are watching all bug changes.
[NeoChat] [Bug 476731] Room preview: username height affects room avatar height, breaking layout
https://bugs.kde.org/show_bug.cgi?id=476731 --- Comment #11 from Austin Huang --- Yes; see attachment 162962, comment 1. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 484358] New: Automatic adaptive sync fails to deactivate on exit
https://bugs.kde.org/show_bug.cgi?id=484358 Bug ID: 484358 Summary: Automatic adaptive sync fails to deactivate on exit Classification: Plasma Product: kwin Version: 5.27.11 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: austinkau...@gmail.com Target Milestone: --- SUMMARY Automatic adaptive sync leaves the desktop in a VRR state after closing the fullscreen application that triggered it. This persists even after disabling adaptive sync in display settings, but is fixed by switching to another refresh rate. STEPS TO REPRODUCE 1. Enable adaptive sync 2. Observe desktop is properly vsynced still 3. Open a fullscreen application 4. Observe application enables VRR as expected 5. Close fullscreen application 5. Observe desktop is stuck in a VRR state (as seen by monitor OSD display and flickering behavior) OBSERVED RESULT Desktop is stuck in incorrect VRR state until the refresh rate is switched to another and back. EXPECTED RESULT Desktop returns to normal vsynced state after closing application SOFTWARE/OS VERSIONS KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 Kernel Version: 6.7.9-204.fsync.fc39.x86_64 Graphics Platform: Wayland ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 484358] Automatic adaptive sync fails to deactivate on exit
https://bugs.kde.org/show_bug.cgi?id=484358 --- Comment #1 from Austin Kauble --- In this bad state, switching vrr to "never" has no effect but "always" and then "never" gets back to a good state. -- 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 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 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 #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 #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.
[dolphin] [Bug 367890] Dolphin crashed when moving many files in parallel from a external HD to athe internal SSD
https://bugs.kde.org/show_bug.cgi?id=367890 Austin Kilgore changed: What|Removed |Added CC|kilgorephotos...@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 --- 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 #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 #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 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 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 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 #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 --- 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.
[krita] [Bug 401939] New: Startup hangs if recent files points to missing mount
https://bugs.kde.org/show_bug.cgi?id=401939 Bug ID: 401939 Summary: Startup hangs if recent files points to missing mount Product: krita Version: 4.1.5 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: austinabut...@gmail.com Target Milestone: --- SUMMARY Startup hangs indefinitely at "Loading Main Window" if there's a recent file in the RecentFiles section of kritarc that lives on a mount that's no longer present. If I remove the entry by hand, Krita loads in a few seconds. STEPS TO REPRODUCE 1. Open .config/kritarc 2. Under [RecentFiles], add File1[$e]=/mnt/NAS/image.jpg 3. Under that line add Name1[$e]=image.jpg' 4. Save the file 5. Run Krita OBSERVED RESULT Krita hangs indefinitely at "Loading Main Window." EXPECTED RESULT Krita ignores or removes the inaccessible file from recent files. SOFTWARE/OS VERSIONS Linux: Arch 4.19.6-1-ck-ivybridge KDE Plasma: N/A Qt Version: 5.11.2-3 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 400830] New: Crashed moving files
https://bugs.kde.org/show_bug.cgi?id=400830 Bug ID: 400830 Summary: Crashed moving files Product: dolphin Version: 17.12.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: kilgorephotos...@gmail.com CC: elvis.angelac...@kde.org Target Milestone: --- Application: dolphin (17.12.3) Qt Version: 5.9.5 Frameworks Version: 5.44.0 Operating System: Linux 4.15.0-39-generic x86_64 Distribution: Ubuntu 18.04.1 LTS -- Information about the crash: I have a clean installation of Kubuntu on new SSD and was moving my files off my old HDD when Dolphin crashed. -- Backtrace: Application: Dolphin (dolphin), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f10f3cef6c0 (LWP 1657))] Thread 5 (Thread 0x7f10bbfff700 (LWP 1663)): #0 0x7f10f3554bf9 in __GI___poll (fds=0x7f10b40049b0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f10e638c539 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f10e638c64c in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f10ed6eb90b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f10ed6909ea in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f10ed4af22a in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f10ed4b416d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f10e85276db in start_thread (arg=0x7f10bbfff700) at pthread_create.c:463 #8 0x7f10f356188f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 4 (Thread 0x7f10c9367700 (LWP 1662)): #0 0x7f10e852d9f3 in futex_wait_cancelable (private=, expected=0, futex_word=0x55fd05215db8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x55fd05215d68, cond=0x55fd05215d90) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x55fd05215d90, mutex=0x55fd05215d68) at pthread_cond_wait.c:655 #3 0x7f10cee4046b in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so #4 0x7f10cee40197 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so #5 0x7f10e85276db in start_thread (arg=0x7f10c9367700) at pthread_create.c:463 #6 0x7f10f356188f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7f10ca19f700 (LWP 1661)): #0 0x7f10e852d9f3 in futex_wait_cancelable (private=, expected=0, futex_word=0x55fd05213904) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x55fd052138b0, cond=0x55fd052138d8) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x55fd052138d8, mutex=0x55fd052138b0) at pthread_cond_wait.c:655 #3 0x7f10cee4046b in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so #4 0x7f10cee40197 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so #5 0x7f10e85276db in start_thread (arg=0x7f10ca19f700) at pthread_create.c:463 #6 0x7f10f356188f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7f10d6097700 (LWP 1660)): #0 0x7f10e63d2049 in g_mutex_lock () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7f10e638baa3 in g_main_context_prepare () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f10e638c46b in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f10e638c64c in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f10ed6eb90b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f10ed6909ea in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f10ed4af22a in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f10edb6dd45 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #8 0x7f10ed4b416d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7f10e85276db in start_thread (arg=0x7f10d6097700) at pthread_create.c:463 #10 0x7f10f356188f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f10f3cef6c0 (LWP 1657)): [KCrash Handler] #6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #7 0x7f10f3480801 in __GI_abort () at abort.c:79 #8 0x7f10f347039a in __assert_fail_base (fmt=0x7f10f35f77d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f10f1b0a650 "!q->hasSubjobs()", file=file@entry=0x7f10f1b0ba70 "/build/kio-3qUw81/kio-5.44.0/src/core/copyjob.cpp", line=line@entry=1467, function=function@entry=0x7f10f1b0ac40 "void KIO::CopyJobPrivate::slotResultErrorCop
[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 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 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 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 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 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 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 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.
[print-manager] [Bug 329918] KDE Systrem Settings window crashes repeatably.
https://bugs.kde.org/show_bug.cgi?id=329918 --- Comment #5 from William Austin --- On 2018-01-26 19:08, Daniel Nicoletti wrote: > https://bugs.kde.org/show_bug.cgi?id=329918 > > --- Comment #4 from Daniel Nicoletti --- > Can you please reproduce the issue with debug symbols installed so that I can > know which lines crash... > Apologies for the delay getting back to you, Daniel. (We sold our house and moved and I'm just now getting back to any semblance of normalcy.) That problem was reported under FC19 and as I am now running FC25, FC26, and FC27 on the 3 Linux machines at my desk, I can't wipe one of them out to re-install FC19. The problem does not seem to occur under FC25-27, and I don't know whether it was fixed (accidentally or otherwise) or whether instead it "went away" as the result of some other change (the law of unintended consequences... sigh). So I'd make this one closed if you don't mind. Thanks - WWA -- 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 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 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 #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 #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 #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 #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 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 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 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 #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.
[kleopatra] [Bug 389642] New: Kleo won't import or create new keys
https://bugs.kde.org/show_bug.cgi?id=389642 Bug ID: 389642 Summary: Kleo won't import or create new keys Product: kleopatra Version: 3.0.2 Platform: Other OS: MS Windows Status: UNCONFIRMED Severity: grave Priority: NOR Component: general Assignee: aheine...@intevation.de Reporter: stevenaustinhow...@gmail.com CC: kdepim-b...@kde.org, m...@kde.org Target Milestone: --- Created attachment 110218 --> https://bugs.kde.org/attachment.cgi?id=110218&action=edit screenshot 1 I have Kleo on my old laptop (runs Win 10) which has worked perfectly fine without a hitch. I now have a new laptop and I am trying to import my existing keys onto my new system (again Win 10) however everytime I try to import it goes through the same process and ends up telling me "Secret Keys NOT Imported: 1" (see screenshot 1) No matter what options I check when exporting my keys from my old machine the files that I get just simply won't import- same message everytime. Alright, I think. Maybe I'll just create a brand new key altogether and update others to the new public key. However, everytime I create a new key pair it runs through the process as if everything is just fine and when it comes time to create a backup of my newly generated key pair I get the message "Invalid UserID" (see screenshot 2) and then the keypair simply doesn't show up under my list of certificates in Kleopatra as if I never clicked the Create New Pair button. Kleo simply brings me right back to the Welcome page saying to begin I need to either Import or Create a New Key (screenshot 3) I read on forum that perhaps I should try using GPA instead to create the key. Whenever I open GPA I get the error "GPGME library returned an unexpected error. This could be an installation error" (screenshot 4) and once again any attempts at importing/creating keys are futile. I've fresh installed the newest version (3.0.3) and every other version going back to 3.0.0 to see if maybe there's an issue with the current update but nope, each fresh install gives me the exact same errors every time. I'm beginning to suspect it's not a bug with your software but some background process on my machine that is prohibiting a successful install but I've no idea what it could be. Running the .exe installation as an Admin doesn't help. I've also ran the self-test to check for errors but everything appears to be fine as per screenshot 5. Please if you've any idea on how to fix this it would be greatly appreciated! -- You are receiving this mail because: You are watching all bug changes.
[kleopatra] [Bug 389642] Kleo won't import or create new keys
https://bugs.kde.org/show_bug.cgi?id=389642 --- Comment #1 from Austin Howard --- Created attachment 110219 --> https://bugs.kde.org/attachment.cgi?id=110219&action=edit screenshot 2 -- You are receiving this mail because: You are watching all bug changes.
[kleopatra] [Bug 389642] Kleo won't import or create new keys
https://bugs.kde.org/show_bug.cgi?id=389642 --- Comment #2 from Austin Howard --- Created attachment 110220 --> https://bugs.kde.org/attachment.cgi?id=110220&action=edit screenshot 3 -- You are receiving this mail because: You are watching all bug changes.
[kleopatra] [Bug 389642] Kleo won't import or create new keys
https://bugs.kde.org/show_bug.cgi?id=389642 --- Comment #3 from Austin Howard --- Created attachment 110221 --> https://bugs.kde.org/attachment.cgi?id=110221&action=edit screenshot 4 -- You are receiving this mail because: You are watching all bug changes.
[kleopatra] [Bug 389642] Kleo won't import or create new keys
https://bugs.kde.org/show_bug.cgi?id=389642 --- Comment #4 from Austin Howard --- Created attachment 110222 --> https://bugs.kde.org/attachment.cgi?id=110222&action=edit screenshot 5 -- 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 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] 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 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 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] 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 #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 #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 #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 #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 #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 #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 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 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 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] 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 #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 #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 #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 #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 #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 #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 #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 #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 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 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.
