[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 #29 from Jefferson Carpenter --- (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. -- 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 Jefferson Carpenter changed: What|Removed |Added Attachment #126950|0 |1 is obsolete|| Attachment #126977|0 |1 is obsolete|| --- Comment #26 from Jefferson Carpenter --- Created attachment 128132 --> https://bugs.kde.org/attachment.cgi?id=128132=edit Add read_pe_debug_info: v3 Apparently the attachment didn't attach. Attached it again. -- 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 #25 from Jefferson Carpenter --- Removed the spurious output. Did not manually add a mapping, to fix the "DiCfsi invariant (1) verification failed" message. Also removed the dwarf3 code - the patch still seems to work for me, and native PE files will of course not have dwarf3 debug info. There are still some things I'm very unsure about whether this patch does correctly. 1: Latest version, I changed the search_all_symtabs logic to search for text sections using di->text_present and so on, instead of looking at di->fsm properties. It seems logical, but since I'm not very familiar with the Valgrind code it could be a breaking change. Someone would have to look at it. 2: The way read_pe_debug_info is called into is IMO a messy hack. I did add a function for detecting whether a binary is a PE object file, but I think passing a boolean argument into di_notify_ACHIEVE_ACCEPT_STATE is not the cleanest way to do it. The way PDB debug info is requested is through client requests, so maybe PE debug info should be requested the same way. 3: There's generally a little bit of code duplication. Some duplicate "if (!ML_(img_valid)(...))" statements I could try to combine or replace with a macro. Also the PE executable file format is modeled both in readpdb.c and readpe.c currently and should be factored out into a header. I just didn't bother to do that at this early stage. -- 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 #22 from Jefferson Carpenter --- (In reply to Jefferson Carpenter from comment #21) > I created the patch using git format-patch, so you should apply it using > either > > $ git apply 0001-Add-read_pe_debug_info-V2.patch > > or > > $ patch -p 1 <0001-Add-read_pe_debug_info-V2.patch > > I'm still not clear on the best way to create patch files. Here's what I think happened - by default patch strips all directories off of the path in the patch file. Since Makefile.am does exist in the root directory patch attempts to apply HUNK 1 but fails because HUNK 1 is actually for the coregrind/Makefile.am file. (Then, since coregrind/m_debuginfo/debuginfo.c is modified but debuginfo.c does not exist in the root directory of valgrind, patch has to ask for its directory. priv_readpe.h and readpe.c are both new files, but patch again strips their directories and places them in the root directory). Moral of the story: run patch with a -p option if the patch file has knowledge of the directory structure of your project. -- 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 #21 from Jefferson Carpenter --- (In reply to Austin English from comment #20) > 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) I created the patch using git format-patch, so you should apply it using either $ git apply 0001-Add-read_pe_debug_info-V2.patch or $ patch -p 1 <0001-Add-read_pe_debug_info-V2.patch I'm still not clear on the best way to create patch files. -- 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 #19 from Jefferson Carpenter --- Created attachment 126977 --> https://bugs.kde.org/attachment.cgi?id=126977=edit 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. -- 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 #18 from Jefferson Carpenter --- Created attachment 126950 --> https://bugs.kde.org/attachment.cgi?id=126950=edit Hackish patch: Add read_pe_debug_info -- 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 Jefferson Carpenter changed: What|Removed |Added CC||jeffersoncarpenter2@gmail.c ||om --- Comment #17 from Jefferson Carpenter --- (In reply to fenrir+kde-bugs from comment #5) > I have attached a very hackish patch against valgrind 3.6.0 that I have > made to load the informations. It partially works for VLC: I have the file > and line number working but that's all. e.g. In order to get the function names, you may have to iterate through the PE/COFF symbol table, and insert the symbols into the debuginfo. I have also attached a very hackish patch, one that reads debug info from the PE32 file itself having been compiled with mingw. It does not support PE64. In addition to being hackish, it contains numerous lies. It currently assumes that the .text section is sections[0] for no particular reason. It also adds a DebugInfoMap covering the range [image_base, image_base + size_of_image) assuming that's where the image will be during execution (I think a better way to do that would be to intercept the call that moves it there, be that a memcpy, memmove, mmap, or what have you). Furthermore, I was not able to tell if there is a way to get the ending address of symbols - only the starting address. So I have it pushing all of the symbols into an array, sorting it descending by symbol starting address, and setting each symbol's address range to go from its starting address to just before starting address of the next symbol. (The last symbol is then said to end at the end of the text section.) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 418795] command line to inform valgrind of symbols for code that is loaded outside of the normal flow
https://bugs.kde.org/show_bug.cgi?id=418795 Jefferson Carpenter changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #2 from Jefferson Carpenter --- Sorry, this isn't very well defined. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 418795] command line to inform valgrind of symbols for code that is loaded outside of the normal flow
https://bugs.kde.org/show_bug.cgi?id=418795 --- Comment #1 from Jefferson Carpenter --- It looks like VG_(di_notify_mmap) could be modified to load symbols for the exe in this case. That would be a better solution. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 418795] New: command line to inform valgrind of symbols for code that is loaded outside of the normal flow
https://bugs.kde.org/show_bug.cgi?id=418795 Bug ID: 418795 Summary: command line to inform valgrind of symbols for code that is loaded outside of the normal flow Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: jeffersoncarpent...@gmail.com Target Milestone: --- SUMMARY gdb has an "add-symbol-file" command to inform the debugger of the symbols to use for code loaded into a certain address. It would be nice if Valgrind had this feature too. In addition to giving more complete stack traces for errors that occur in dynamically loaded code, this can be used in conjunction with suppression files to suppress errors in such code. Use case: Debugging windows executables under wine, the subroutine `chkstk` is called, and part of the correct behavior for that function is to read past the end of the stack. These executables are loaded outside of the normal dlopen flow, and so valgrind does not have symbol information. The chkstk errors can be suppressed using --ignore-range-below-sp, but this could prevent valgrind from picking up real errors. STEPS TO REPRODUCE (Desired behavior): 1. valgrind --suppressions=chkstk.supp --add-symbol-file=./main.exe@0x0040100 --trace-children-yes wine main.exe No desire on the specific command line syntax for adding symbol info. OBSERVED RESULT (Desired result): With a suitable suppressions file, valgrind ignores errors that occur in __chkstk_ms. Without the suppressions file, trace includes: Invalid read of size 4 at 0x402424: __chkstk_ms (cygwin.S:158) Instead of: Invalid read of size 4 at 0x402424: ??? ADDITIONAL INFORMATION: I asked about this feature in this email thread https://sourceforge.net/p/valgrind/mailman/message/36810610/ Julian did suggest using --ignore-range-below-sp but did not say the feature was a bad idea, so I am posting it here. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414278] New: VG_(memcpy) used for overlapping moves
https://bugs.kde.org/show_bug.cgi?id=414278 Bug ID: 414278 Summary: VG_(memcpy) used for overlapping moves Product: valgrind Version: 3.15 SVN Platform: unspecified OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: jeffersoncarpent...@gmail.com Target Milestone: --- Created attachment 124003 --> https://bugs.kde.org/attachment.cgi?id=124003=edit Specify that memcpy supports overlapping moves This is used to positive effect in some cases for performance of XArray etc. It would be a good idea to specify that VG_(memcpy) additionally supports overlapping areas if dest < src, since memcpy explicitly states the contrary. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 373984] xmodmap settings interfere with shortcut keys
https://bugs.kde.org/show_bug.cgi?id=373984 --- Comment #1 from Jefferson Carpenter <jeffersoncarpent...@gmail.com> --- Created attachment 102912 --> https://bugs.kde.org/attachment.cgi?id=102912=edit the xmodmap file i'm using -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 373984] New: xmodmap settings interfere with shortcut keys
https://bugs.kde.org/show_bug.cgi?id=373984 Bug ID: 373984 Summary: xmodmap settings interfere with shortcut keys Product: systemsettings Version: 5.8.4 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: kcm_keys Assignee: k...@michael-jansen.biz Reporter: jeffersoncarpent...@gmail.com Target Milestone: --- I use xmodmap to turn my capslock key into a ctrl, my ctrl into an alt, and my alt into a capslock. This interferes with KDE keybindings. Specifically, when I press alt+tab to switch windows, instead of displaying a window list the window manager takes me back and fourth between the two most recent windows. I can assign the key binding like normal using my mapped keys, just not use it. As a workaround, I've mapped win+tab to switch windows. Just submitting this bug so that you know about this glitch. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 373981] Initial volume levels for notifications are loud - weird bug
https://bugs.kde.org/show_bug.cgi?id=373981 Jefferson Carpenter <jeffersoncarpent...@gmail.com> changed: What|Removed |Added Version|unspecified |5.29.0 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 373981] New: Initial volume levels for notifications are loud - weird bug
https://bugs.kde.org/show_bug.cgi?id=373981 Bug ID: 373981 Summary: Initial volume levels for notifications are loud - weird bug Product: frameworks-knotifications Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mklape...@kde.org Reporter: jeffersoncarpent...@gmail.com CC: kdelibs-b...@kde.org Target Milestone: --- When KDE applications create notifications, the first notification is quite loud, and subsequent ones are quieter. For instance, this bug happens each time I open System Settings. When I modify a field and then switch to a different tab, the notification is loud. Subsequent times, the notification is quiet. This also appears to affect KDE's desktop's notifications. The first desktop notification sound is loud compared to the ones following it. While jumping out of my seat is a good way to keep the adrenaline pumping, for now I have disabled all notification sounds as a workaround :) -- You are receiving this mail because: You are watching all bug changes.
