[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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 #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 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 #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.
[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 #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.
[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.
[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.
[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 Platform|Other |Kubuntu -- 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.
[kwin] [Bug 463958] Recurring stutter of the whole desktop
https://bugs.kde.org/show_bug.cgi?id=463958 --- Comment #19 from Austin --- (In reply to Tom Englund from comment #18) > if i didnt miss something but seems you all are on ryzens. i would check if > your fTPM/TPM is enabled in bios. unsure when exactly this landed > https://github.com/torvalds/linux/commit/ > b006c439d58db625318bf2207feabf847510a8a6 but it introduces the > https://www.amd.com/en/support/kb/faq/pa-410 which windows 11 users hit when > it began requiring people to enable TPM. i myself hit it aswell. affects > pretty much entire ryzen lineup. some vendors have bios updates to mitigate > this. most dont. they are working on some workaround for this tho > https://bugzilla.kernel.org/show_bug.cgi?id=216989 , i myself dont use the > tpm for anything and simply disabled it in bios. Wow, I would have never thought to try that. Turned off TPM this morning, and so far it's been fine all day. I'm not using Windows 11 or anything else that uses the TPM so no harm done disabling it. So sounds like that may be the culprit. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 463958] Recurring stutter of the whole desktop
https://bugs.kde.org/show_bug.cgi?id=463958 Austin changed: What|Removed |Added CC||doorkno...@gmail.com --- Comment #17 from Austin --- I am having the same issue on my system. Like the others, it occurs randomly and infrequently. Over the course of an 8 hour workday, it might happen less than 10 times. Each "stutter" lasts maybe a second. It affects the sound, mouse movement, video playback, everything. I am usually watching Twitch streams in Firefox when using the computer. Operating System: Arch Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 6.1.9-arch1-2 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT I am using a cheap USB sound device to plug in my headphones (my front panel audio is broken) which I suspected may be part of the problem, but I have not been able to test that theory (I don't have another one handy to swap out). After seeing others here with the same issue, I suspect the sound device is probably not be the issue. I also have not tried X11 to compare (Wayland is generally really nice and smooth without tearing), but I may have to give that a shot for debugging purposes. -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 465379] Broken link
https://bugs.kde.org/show_bug.cgi?id=465379 --- Comment #6 from Austin --- It worked! I played with it and Firefox had pop up blocked at first which was my main issue it seems. Thank you for your help! On Mon, Feb 6, 2023, 4:13 PM Phu H. Nguyen wrote: > https://bugs.kde.org/show_bug.cgi?id=465379 > > --- Comment #5 from Phu H. Nguyen --- > (In reply to Austin from comment #4) > > Created attachment 156006 [details] > > attachment-1014623-0.html > > > > A pop up came up saying would you like kde to open up discover and then > > nothing happens > > How about waiting for 2 or 3 seconds there, so that the "Open Link" button > in > the popup is enabled, then clicking on that button? What happened then? > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 465379] Broken link
https://bugs.kde.org/show_bug.cgi?id=465379 --- Comment #4 from Austin --- A pop up came up saying would you like kde to open up discover and then nothing happens On Mon, Feb 6, 2023, 3:23 PM Phu H. Nguyen wrote: > https://bugs.kde.org/show_bug.cgi?id=465379 > > --- Comment #3 from Phu H. Nguyen --- > (In reply to Austin from comment #2) > > Hello I apologize for the unclear report. > > I was using kde neon and the link seems to essentially not open. I have > > tried this on other distros as well with the same result. If you would > like > > I can upload a screen recording if the ticket if you think that would > help. > > > > Thank you for your time and hard work! > > > > Best, > > Austin > > Hi Austin, > What happened when you click on the badge? > - Did your browser show a popup asking you to choose an application to > open the > link? > - Did your application store (Discover, GNOME Software, etc.) open? > - Or did nothing happen? > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 465379] Broken link
https://bugs.kde.org/show_bug.cgi?id=465379 --- Comment #2 from Austin --- Hello I apologize for the unclear report. I was using kde neon and the link seems to essentially not open. I have tried this on other distros as well with the same result. If you would like I can upload a screen recording if the ticket if you think that would help. Thank you for your time and hard work! Best, Austin On Mon, Feb 6, 2023, 2:33 PM Phu H. Nguyen wrote: > https://bugs.kde.org/show_bug.cgi?id=465379 > > Phu H. Nguyen changed: > >What|Removed |Added > > > CC||phu.ngu...@kdemail.net > > --- Comment #1 from Phu H. Nguyen --- > Hi Austin, > Could you collaborate on what "seems to be broken" mean? And also what > OS(es) > were you using during these attempts? > When you click on the "Install on Linux" badge, the application store on > your > system is supposed to open and show a page for the app (here the app is > Discover). Did your browser show a popup asking you to choose an > application to > open the link? > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 465379] New: Broken link
https://bugs.kde.org/show_bug.cgi?id=465379 Bug ID: 465379 Summary: Broken link Classification: Websites Product: www.kde.org Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: apps.kde.org Assignee: kde-...@kde.org Reporter: austinman...@gmail.com Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Go to https://apps.kde.org/discover/ 2. Click on the install on Linux icon 3. OBSERVED RESULT Link seems to be broken EXPECTED RESULT Sent to a new web page. SOFTWARE/OS VERSIONS Windows: X macOS: X Linux/KDE Plasma: X (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Attempted on multiple systems same result -- 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.
[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.
[krita] [Bug 453279] New: Krita Epub not downloading from manual website
https://bugs.kde.org/show_bug.cgi?id=453279 Bug ID: 453279 Summary: Krita Epub not downloading from manual website Product: krita Version: unspecified Platform: Android OS: All Status: REPORTED Severity: normal Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: austinman...@gmail.com Target Milestone: --- Created attachment 148506 --> https://bugs.kde.org/attachment.cgi?id=148506&action=edit Krazy characters SUMMARY Hello I am on my tab s7 and I was attempting to download the epub manual. This was on both the android tablet and android phone the attachment below shows what happens STEPS TO REPRODUCE 1. Go to the official website 2. Download the epub from the manual link 3. Watch the crazy characters load in OBSERVED RESULT What appears to be a broken link EXPECTED RESULT A download prompt for the epub version SOFTWARE/OS VERSIONS Android at the latest update ADDITIONAL INFORMATION Was reproducible on both samsung internet and chrome -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #10 from Austin English --- (In reply to Mark Wielaard from comment #8) > So I see both examples are for 32bit Debian packages (i386 and arm32). Is > this an 32bit only issue or are you seeing the same for 64bit packages? Just tried, I'm not seeing it with 64-bit (though I don't normally run wine's tests under 64-bit, so don't take that as 100% certain). (In reply to Mark Wielaard from comment #9) > commit 8b1961511c93962ea2a9b918af8e9c32e3c24d71 > Author: Balint Reczey > Date: Thu Nov 28 13:34:21 2019 +0100 > > Don't look for debug alt file in debug image if it is already found > > With dwz the .gnu_debuglink section may appear duplicated in the > debug file referenced originally in the .gnu_debuglink section. > > https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1848211 > > https://bugs.kde.org/show_bug.cgi?id=396656 > https://bugs.kde.org/show_bug.cgi?id=427969 > > Signed-off-by: Balint Reczey Thanks! This works for me on x86 (can't easily test arm at the moment, but will report back if there's a problem there). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #6 from Austin English --- (In reply to Mark Wielaard from comment #5) > Thanks for including the files, this is really odd the main ELF file has > both a .gnu_debuglink section and a .gnu_debugaltlink section, but no .debug > sections itself. The .debug file itself also has a .gnu_debugaltlink. > > (Sidenote, the .gnu_debugaltlink is absolute, instead of a relative path > from the .debug file, which makes it slightly harder to find unless you > replicate the fill file system layout.) > > This looks suspiciously like an Ubuntu bug: > https://bugs.kde.org/show_bug.cgi?id=396656 I'm running Debian, not Ubuntu, to be clear, but fair enough. Should I report this to Debian or should I gather some other information first? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #33 from Austin English --- To follow up, I misunderstood the scope of Remi's work. The patchset *does* work for DWARF symbols in PE binaries in modern wine (i.e., with wine having a mingw compiled ntdll). PDB support is a separate problem and should not stop the patches from going in. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #32 from Austin English --- Hi Remi, Using both wine patches: https://source.winehq.org/patches/data/196764 https://source.winehq.org/patches/data/196765 and valgrind patches: https://sourceforge.net/p/valgrind/mailman/message/37164939/ https://sourceforge.net/p/valgrind/mailman/message/37164938/ https://sourceforge.net/p/valgrind/mailman/message/37164940/ on top of wine-6.0-rc2 and valgrind-VALGRIND_3_15_0-405-g41504d33d, with llvm-mingw, I don't get symbols: ==8917== 2,048 bytes in 1 blocks are possibly lost in loss record 86 of 92 ==8917==at 0x7BC23550: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC2F91F: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC29921: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC2E1F7: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x7BC2DC01: ??? (in /home/austin/wine-valgrind-pdb/dlls/ntdll/ntdll.dll) ==8917==by 0x46E061E: start_main_thread (loader.c:1580) ==8917==by 0x46E061E: __wine_main (???:0) ==8917==by 0x7D001287: main (main.c:157) ==8917== compared to non pdb build: ==31534== 2,048 bytes in 1 blocks are possibly lost in loss record 100 of 108 ==31534==at 0x7BC51E61: RtlAllocateHeap (heap.c:261) ==31534==by 0x7BC625C3: init_load_order (loadorder.c:234) ==31534==by 0x7BC625C3: get_load_order (???:0) ==31534==by 0x7BC5DA27: load_dll (loader.c:2644) ==31534==by 0x7BC5FFD1: process_init (loader.c:4017) ==31534==by 0x7BC61D7B: __wine_set_unix_funcs (loader.c:4114) ==31534==by 0x46E061E: start_main_thread (loader.c:1580) ==31534==by 0x46E061E: __wine_main (???:0) ==31534==by 0x7D001287: main (main.c:157) ==31534== (that's dlls/avifil32/tests/api.c) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #4 from Austin English --- Created attachment 133681 --> https://bugs.kde.org/attachment.cgi?id=133681&action=edit armv7l library I also see this with 32-bit arm(v7l): --10058-- WARNING: Serious error when reading debug info --10058-- When reading debug info from /usr/lib/arm-linux-gnueabihf/libbrotlidec.so.1.0.9: --10058--debuginfo section duplicates a section in the main ELF file austin@arm7:~$ readelf -S /usr/lib/arm-linux-gnueabihf/libbrotlidec.so.1.0.9 There are 25 section headers, starting at offset 0x7208: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .note.gnu.bu[...] NOTE00f4 f4 24 00 A 0 0 4 [ 2] .gnu.hash GNU_HASH0118 000118 5c 04 A 3 0 4 [ 3] .dynsym DYNSYM 0174 000174 000210 10 A 4 3 4 [ 4] .dynstr STRTAB 0384 000384 0002fb 00 A 0 0 1 [ 5] .gnu.version VERSYM 0680 000680 42 02 A 3 0 2 [ 6] .gnu.version_rVERNEED 06c4 0006c4 40 00 A 4 2 4 [ 7] .rel.dyn REL 0704 000704 60 08 A 3 0 4 [ 8] .rel.plt REL 0764 000764 68 08 AI 3 18 4 [ 9] .init PROGBITS07cc 0007cc 0c 00 AX 0 0 4 [10] .plt PROGBITS07d8 0007d8 b0 04 AX 0 0 4 [11] .text PROGBITS0888 000888 004b10 00 AX 0 0 4 [12] .fini PROGBITS5398 005398 08 00 AX 0 0 4 [13] .rodata PROGBITS53a0 0053a0 001888 00 A 0 0 4 [14] .eh_frame PROGBITS6c28 006c28 04 00 A 0 0 4 [15] .init_array INIT_ARRAY 00016ef8 006ef8 04 04 WA 0 0 4 [16] .fini_array FINI_ARRAY 00016efc 006efc 04 04 WA 0 0 4 [17] .dynamic DYNAMIC 00016f00 006f00 000100 08 WA 4 0 4 [18] .got PROGBITS00017000 007000 64 04 WA 0 0 4 [19] .data PROGBITS00017064 007064 04 00 WA 0 0 4 [20] .bss NOBITS 00017068 007068 04 00 WA 0 0 1 [21] .ARM.attributes ARM_ATTRIBUTES 007068 31 00 0 0 1 [22] .gnu_debugaltlink PROGBITS 007099 4d 00 0 0 1 [23] .gnu_debuglinkPROGBITS 0070e8 34 00 0 0 4 [24] .shstrtab STRTAB 00711c ec 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), y (purecode), p (processor specific) -- You are receiving this mail because: You are watching all bug changes.
[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.
[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.
[filelight] [Bug 427185] Filelight crashed when starting application
https://bugs.kde.org/show_bug.cgi?id=427185 --- Comment #2 from Austin Kilgore --- (In reply to Christoph Feck from comment #1) > Does it still happen if you uninstall "qt5ct"? I uninstalled qt5ct and filelight does indeed work with qt5ct removed. Since filelight is the only program experiencing this issue I'm inclinded to think it's a bug with filelight and not qt5ct. I have a lot of programs that rely on qt5ct to function correctly so removing it permanately isn't a option for me. Also, I came across this which might be a duplicate https://bugs.kde.org/show_bug.cgi?id=415732 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #3 from Austin English --- austin@debian-desktop ~/src/valgrind (master) $ readelf -S /usr/lib/i386-linux-gnu/libbrotlidec.so.1.0.9 There are 27 section headers, starting at offset 0xc1b0: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .note.gnu.bu[...] NOTE0154 000154 24 00 A 0 0 4 [ 2] .gnu.hash GNU_HASH0178 000178 5c 04 A 3 0 4 [ 3] .dynsym DYNSYM 01d4 0001d4 0001e0 10 A 4 1 4 [ 4] .dynstr STRTAB 03b4 0003b4 0002e6 00 A 0 0 1 [ 5] .gnu.version VERSYM 069a 00069a 3c 02 A 3 0 2 [ 6] .gnu.version_rVERNEED 06d8 0006d8 40 00 A 4 1 4 [ 7] .rel.dyn REL 0718 000718 58 08 A 3 0 4 [ 8] .rel.plt REL 0770 000770 58 08 AI 3 21 4 [ 9] .init PROGBITS1000 001000 20 00 AX 0 0 4 [10] .plt PROGBITS1020 001020 c0 04 AX 0 0 16 [11] .plt.got PROGBITS10e0 0010e0 08 08 AX 0 0 8 [12] .text PROGBITS10f0 0010f0 0073f4 00 AX 0 0 16 [13] .fini PROGBITS84e4 0084e4 14 00 AX 0 0 4 [14] .rodata PROGBITS9000 009000 001b00 00 A 0 0 32 [15] .eh_frame_hdr PROGBITSab00 00ab00 0001bc 00 A 0 0 4 [16] .eh_frame PROGBITSacbc 00acbc 000e94 00 A 0 0 4 [17] .init_array INIT_ARRAY cee0 00bee0 04 04 WA 0 0 4 [18] .fini_array FINI_ARRAY cee4 00bee4 04 04 WA 0 0 4 [19] .dynamic DYNAMIC cee8 00bee8 f8 08 WA 4 0 4 [20] .got PROGBITScfe0 00bfe0 20 04 WA 0 0 4 [21] .got.plt PROGBITSd000 00c000 38 04 WA 0 0 4 [22] .data PROGBITSd038 00c038 04 00 WA 0 0 4 [23] .bss NOBITS d03c 00c03c 04 00 WA 0 0 1 [24] .gnu_debugaltlink PROGBITS 00c03c 48 00 0 0 1 [25] .gnu_debuglinkPROGBITS 00c084 34 00 0 0 4 [26] .shstrtab STRTAB 00c0b8 f7 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), p (processor specific) Note that this seems to occur for all/most 32-bit libraries (I see 133 different .so files referenced so far when running the full wine test suite). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #2 from Austin English --- Created attachment 132556 --> https://bugs.kde.org/attachment.cgi?id=132556&action=edit .debug files There are a few .debug files listed for this package, so I included all of them. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 Austin English changed: What|Removed |Added Attachment #132554|.so file|libbrotlidec.so.1.0.9 description|| -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 --- Comment #1 from Austin English --- Created attachment 132554 --> https://bugs.kde.org/attachment.cgi?id=132554&action=edit .so file -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427969] New: debuginfo section duplicates a section in the main ELF file
https://bugs.kde.org/show_bug.cgi?id=427969 Bug ID: 427969 Summary: debuginfo section duplicates a section in the main ELF file Product: valgrind Version: unspecified Platform: Debian testing OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- When running wine's 32bit tests under valgrind with debian's debug symbols installed, I get a ton of errors like: --1235044-- WARNING: Serious error when reading debug info --1235044-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlidec.so.1.0.9: --1235044--debuginfo section duplicates a section in the main ELF file --1235044-- WARNING: Serious error when reading debug info --1235044-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlicommon.so.1.0.9: --1235044--debuginfo section duplicates a section in the main ELF file --1235057-- WARNING: Serious error when reading debug info --1235057-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlidec.so.1.0.9: --1235057--debuginfo section duplicates a section in the main ELF file --1235057-- WARNING: Serious error when reading debug info --1235057-- When reading debug info from /usr/lib/i386-linux-gnu/libbrotlicommon.so.1.0.9: --1235057--debuginfo section duplicates a section in the main ELF file -- You are receiving this mail because: You are watching all bug changes.
[filelight] [Bug 427185] New: Filelight crashed when starting application
https://bugs.kde.org/show_bug.cgi?id=427185 Bug ID: 427185 Summary: Filelight crashed when starting application Product: filelight Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: martin.sandsm...@kde.org Reporter: kilgorephotos...@gmail.com Target Milestone: --- Application: filelight (20.08.1) Qt Version: 5.15.1 Frameworks Version: 5.74.0 Operating System: Linux 5.8.12-zen1-1-zen x86_64 Windowing system: X11 Distribution: "Arch Linux" -- Information about the crash: - What I was doing when the application crashed:Nothing I simply went to start filelight and it crashed. I never saw any gui, just the outline of the window as the process died. I'm on Arch Linux x64 5.8.12 Zen Kernel The crash can be reproduced every time. -- Backtrace: Application: Filelight (filelight), signal: Segmentation fault [New LWP 33589] [New LWP 33590] [New LWP 33591] [New LWP 33592] [New LWP 33593] [New LWP 33594] [New LWP 33595] [New LWP 33596] [New LWP 33597] [New LWP 33598] [New LWP 33599] [New LWP 33600] [New LWP 33601] [New LWP 33602] [New LWP 33603] [New LWP 33604] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". 0x7f933dc5b46f in poll () from /usr/lib/libc.so.6 [Current thread is 1 (Thread 0x7f933a51f840 (LWP 33587))] Thread 17 (Thread 0x7f92e640 (LWP 33604)): #0 0x7f933d5fe6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f9331b32cfc in ?? () from /usr/lib/dri/radeonsi_dri.so #2 0x7f9331b316f8 in ?? () from /usr/lib/dri/radeonsi_dri.so #3 0x7f933d5f83e9 in start_thread () from /usr/lib/libpthread.so.0 #4 0x7f933dc66293 in clone () from /usr/lib/libc.so.6 Thread 16 (Thread 0x7f931cff9640 (LWP 33603)): #0 0x7f933d5fe6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f9331b32cfc in ?? () from /usr/lib/dri/radeonsi_dri.so #2 0x7f9331b316f8 in ?? () from /usr/lib/dri/radeonsi_dri.so #3 0x7f933d5f83e9 in start_thread () from /usr/lib/libpthread.so.0 #4 0x7f933dc66293 in clone () from /usr/lib/libc.so.6 Thread 15 (Thread 0x7f931d7fa640 (LWP 33602)): #0 0x7f933d5fe6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f9331b32cfc in ?? () from /usr/lib/dri/radeonsi_dri.so #2 0x7f9331b316f8 in ?? () from /usr/lib/dri/radeonsi_dri.so #3 0x7f933d5f83e9 in start_thread () from /usr/lib/libpthread.so.0 #4 0x7f933dc66293 in clone () from /usr/lib/libc.so.6 Thread 14 (Thread 0x7f931dffb640 (LWP 33601)): #0 0x7f933d5fe6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f9331b32cfc in ?? () from /usr/lib/dri/radeonsi_dri.so #2 0x7f9331b316f8 in ?? () from /usr/lib/dri/radeonsi_dri.so #3 0x7f933d5f83e9 in start_thread () from /usr/lib/libpthread.so.0 #4 0x7f933dc66293 in clone () from /usr/lib/libc.so.6 Thread 13 (Thread 0x7f931e7fc640 (LWP 33600)): #0 0x7f933d5fe6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f9331b32cfc in ?? () from /usr/lib/dri/radeonsi_dri.so #2 0x7f9331b316f8 in ?? () from /usr/lib/dri/radeonsi_dri.so #3 0x7f933d5f83e9 in start_thread () from /usr/lib/libpthread.so.0 #4 0x7f933dc66293 in clone () from /usr/lib/libc.so.6 Thread 12 (Thread 0x7f931effd640 (LWP 33599)): #0 0x7f933d5fe6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f9331b32cfc in ?? () from /usr/lib/dri/radeonsi_dri.so #2 0x7f9331b316f8 in ?? () from /usr/lib/dri/radeonsi_dri.so #3 0x7f933d5f83e9 in start_thread () from /usr/lib/libpthread.so.0 #4 0x7f933dc66293 in clone () from /usr/lib/libc.so.6 Thread 11 (Thread 0x7f931f7fe640 (LWP 33598)): #0 0x7f933d5fe6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f9331b32cfc in ?? () from /usr/lib/dri/radeonsi_dri.so #2 0x7f9331b316f8 in ?? () from /usr/lib/dri/radeonsi_dri.so #3 0x7f933d5f83e9 in start_thread () from /usr/lib/libpthread.so.0 #4 0x7f933dc66293 in clone () from /usr/lib/libc.so.6 Thread 10 (Thread 0x7f931640 (LWP 33597)): #0 0x7f933d5fe6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f9331b32cfc in ?? () from /usr/lib/dri/radeonsi_dri.so #2 0x7f9331b316f8 in ?? () from /usr/lib/dri/radeonsi_dri.so #3 0x7f933d5f83e9 in start_thread () from /usr/lib/libpthread.so.0 #4 0x7f933dc66293 in clone () from /usr/lib/libc.so.6 Thread 9 (Thread 0x7f9324be0640 (LWP 33596)): #0 0x7f933d5fe6a2 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f9331b32cfc in ?? () from /usr/lib/dri/radeonsi_dri.so #2 0x7f9331b316f8 in ?? () from /usr/lib/
[kmenuedit] [Bug 426822] New: KDE menu system crashes at "save"
https://bugs.kde.org/show_bug.cgi?id=426822 Bug ID: 426822 Summary: KDE menu system crashes at "save" Product: kmenuedit Version: 5.18.5 Platform: Fedora RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: wwaus...@gmail.com Target Milestone: --- Application: kmenuedit (5.18.5) Qt Version: 5.14.2 Frameworks Version: 5.70.0 Operating System: Linux 5.8.8-200.fc32.x86_64 x86_64 Windowing system: X11 Distribution: Fedora 32 (KDE Plasma) -- Information about the crash: - What I was doing when the application crashed: I was doing *extensive* edits to the menu system. Upgrading fro FC31 to FC32, to get rid of serious "stuck focus" problem I finally blew my entire .kde directory away and started fresh. My from menu was complex and is FAR more useful for me than the stock menu, so I was editing the menu (adding and deleting entries) and then saving and testing after each group. I had (IIRC) between 6 and 9 of the menu-editor over roughly 2 hours of work. EVERY CRASH HAPPENED AS SOON AS I HIT THE - no exceptions. FWIW, no, the saves did not take place, so I lost a good deal of work. (The former copy of menu under ${HOME}/.kde/share/applnk is still ignored as it has been for a dozen or so releases, so it doesn't help but serves as a guide when I have to rebuild the menu system from scratch. This did not occur evey time I hit save - only occasionally, usually after a larger number of changes had been made (20 or more). Only once did it crash after making only one or two changes. It has happened a couple of times previously, but not with the high frequency of occurrences I had today. The crash can be reproduced sometimes. -- Backtrace: Application: KDE Menu Editor (kmenuedit), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f76b60d4900 (LWP 166370))] Thread 7 (Thread 0x7f768f7fe700 (LWP 166376)): #0 0x7f76b90cde92 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7f769ae3885b in util_queue_thread_func () from /usr/lib64/dri/nouveau_dri.so #2 0x7f769ae3832b in impl_thrd_routine () from /usr/lib64/dri/nouveau_dri.so #3 0x7f76b90c7432 in start_thread () from /lib64/libpthread.so.0 #4 0x7f76bb3ea913 in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7f768700 (LWP 166375)): #0 0x7f76b90cde92 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7f769ae3885b in util_queue_thread_func () from /usr/lib64/dri/nouveau_dri.so #2 0x7f769ae3832b in impl_thrd_routine () from /usr/lib64/dri/nouveau_dri.so #3 0x7f76b90c7432 in start_thread () from /lib64/libpthread.so.0 #4 0x7f76bb3ea913 in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7f7694b2e700 (LWP 166374)): #0 0x7f76b90cde92 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7f769ae3885b in util_queue_thread_func () from /usr/lib64/dri/nouveau_dri.so #2 0x7f769ae3832b in impl_thrd_routine () from /usr/lib64/dri/nouveau_dri.so #3 0x7f76b90c7432 in start_thread () from /lib64/libpthread.so.0 #4 0x7f76bb3ea913 in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f769532f700 (LWP 166373)): #0 0x7f76b90cde92 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7f769ae3885b in util_queue_thread_func () from /usr/lib64/dri/nouveau_dri.so #2 0x7f769ae3832b in impl_thrd_routine () from /usr/lib64/dri/nouveau_dri.so #3 0x7f76b90c7432 in start_thread () from /lib64/libpthread.so.0 #4 0x7f76bb3ea913 in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f76a34a8700 (LWP 166372)): #0 0x7f76b8778bed in g_source_unref_internal () from /lib64/libglib-2.0.so.0 #1 0x7f76b877a945 in g_source_iter_next () from /lib64/libglib-2.0.so.0 #2 0x7f76b877bee3 in g_main_context_prepare () from /lib64/libglib-2.0.so.0 #3 0x7f76b877c9db in g_main_context_iterate.constprop () from /lib64/libglib-2.0.so.0 #4 0x7f76b877cbe3 in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #5 0x7f76b9c6bb8b in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #6 0x7f76b9c1e91b in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #7 0x7f76b9a8a427 in QThread::exec() () from /lib64/libQt5Core.so.5 #8 0x7f76b9f9251b in QDBusConnectionManager::run() () from /lib64/libQt5DBus.so.5 #9 0x7f76b9a8b690 in QThreadPrivate::start(void*) () from /lib64/libQt5Core.so.5 #10 0x7f76b90c7432 in start_thread () from /lib64/libpthread.so.0 #11 0x7f76bb3ea913 in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f76a8e03700 (LWP 166371)): #0 0x7f76bb3dfaaf in poll () from /lib64/libc.so.6 #1 0x7f76b81d038a in _xcb_conn_wait () from /lib64/libxcb
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #30 from Austin English --- Created attachment 128946 --> https://bugs.kde.org/attachment.cgi?id=128946&action=edit compiled test/pdb (In reply to Jefferson Carpenter from comment #29) > (In reply to Austin English from comment #28) > > Created attachment 128170 [details] > > the impossible happened > > > > Upon manual review, it didn't assert, but the impossible happened: > > > > PUTI(136:8xI8)[t1,0] = 0x0:I8 > > > > > > > > vex: the `impossible' happened: > > > >stmt_is_guardable: unhandled stmt > > > > vex storage: T total 9579053828 bytes allocated > > > > vex storage: P total 496 bytes allocated > > > > > > > > valgrind: the 'impossible' happened: > > > >LibVEX called failure_exit(). > > > > > > > > in dlls/atl/tests/registrar.c > > I ran the same test (valgrind --trace-children=yes > ../../../../wine-source/tools/runtest -q -P ../../../loader/wine -T ../../.. > -M atl.dll -p atl_test.exe.so registrar), and the impossible didn't happen > on my machine. (My configure command included --without-mingw because > that's what causes the .exe.so files to be generated). Can you confirm that > the bug happens with my patch applied and not on master? It seems like some > spooky action at a distance if my patch caused new problems generating IR. After some more testing, it only occurs if: ./configure --with-mingw CROSSDEBUG=pdb is used for the build. I'm not sure why the other log shows .exe.so. Maybe a dirty tree, or maybe wine's build system changed.. I've attached the exe and pdb file, it should be enough to reproduce without having to get llvm-mingw/rebuild wine. $ export VALGRIND_OPTS="-q --trace-children=yes --track-origins=yes --gen-suppressions=all --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-ignore --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-external --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-known-bugs --suppressions=/home/austin/wine-valgrind/tools/valgrind/valgrind-suppressions-gecko --leak-check=full --num-callers=20 --workaround-gcc296-bugs=yes --vex-iropt-register-updates=allregs-at-mem-access" # make sure to use the full path for wine: $ valgrind /usr/local/bin/wine avifil32_test.exe api preloader: Warning: failed to reserve range 0011-6800 preloader: Warning: failed to reserve range 7f00-8200 0140:err:heap:HEAP_GetPtr Invalid heap (nil)! size: 136926 ==31466== LOAD_PDB_DEBUGINFO: Find PDB file: /tmp/valgrind_petmp31466_1cb84028 is empty ==31466== Warning: Missing or un-stat-able /home/austin/.wine/drive_c/windows/system32/kernelbase.pdb size: 135558 ==31466== LOAD_PDB_DEBUGINFO: Find PDB file: /tmp/valgrind_petmp31466_1cb84028 is empty ==31466== Warning: Missing or un-stat-able /usr/local/lib64/wine/kernelbase.pdb symbol table size is 0. Not reading debug information for /tmp/tmp.emEgO3p387/bug-211031-avifil32-test/avifil32_test.exe valgrind: m_debuginfo/debuginfo.c:1672 (vgPlain_di_notify_pdb_debuginfo): Assertion 'di && !di->fsm.have_rx_map && !di->fsm.have_rw_map' failed. host stacktrace: ==31466==at 0x58041CF9: show_sched_status_wrk (m_libcassert.c:406) ==31466==by 0x58041E20: report_and_quit (m_libcassert.c:477) ==31466==by 0x58041F14: vgPlain_assert_fail (m_libcassert.c:543) ==31466==by 0x58076146: vgPlain_di_notify_pdb_debuginfo (debuginfo.c:1672) ==31466==by 0x580A252D: do_client_request (scheduler.c:2121) ==31466==by 0x580A252D: vgPlain_scheduler (scheduler.c:1516) ==31466==by 0x580F72C2: thread_wrapper (syswrap-linux.c:101) ==31466==by 0x580F72C2: run_a_thread_NORETURN (syswrap-linux.c:154) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 31466) ==31466==at 0x7BCD6494: map_image (virtual.c:1749) ==31466==by 0x7BCD6A71: virtual_map_section (virtual.c:1835) ==31466==by 0x7BC79293: open_dll_file (loader.c:2371) ==31466==by 0x7BC79D9E: find_dll_file (loader.c:3014) ==31466==by 0x7BC7FDAB: load_dll (loader.c:3044) ==31466==by 0x7BC84857: __wine_process_init (loader.c:4426) ==31466==by 0x7BC84F42: __wine_set_unix_funcs (loader.c:4488) ==31466==by 0x7C001341: main (main.c:285) client stack range: [0xFECB8000 0xFECBDFFF] client SP: 0xFECBA900 valgrind stack range: [0x881FD000 0x882FCFFF] top usage: 7372 of 1048576 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #28 from Austin English --- Created attachment 128170 --> https://bugs.kde.org/attachment.cgi?id=128170&action=edit the impossible happened Upon manual review, it didn't assert, but the impossible happened: PUTI(136:8xI8)[t1,0] = 0x0:I8 vex: the `impossible' happened: stmt_is_guardable: unhandled stmt vex storage: T total 9579053828 bytes allocated vex storage: P total 496 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). in dlls/atl/tests/registrar.c -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #27 from Austin English --- No assertions so far (running still, up to d3d8:visual). Stacktraces look good. Lots of (valid) warnings for missing symbols in wine: symbol table size is 0. Not reading debug information for /home/austin/.wine-valgrind/drive_c/windows/system32/winex11.drv ==14040== LOAD_PDB_DEBUGINFO: Find PDB file: /tmp/valgrind_petmp14040_6f021bc4 is empty ==14040== Warning: Missing or un-stat-able /home/austin/.wine-valgrind/drive_c/windows/system32/winex11.pdb The symbol table size warning should match current format, of course. I haven't checked, but it likely corresponds to the un-stat-able message, so is it really needed? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #24 from Austin English --- Getting a failed assertion in some tests: valgrind: m_debuginfo/debuginfo.c:694 (check_CFSI_related_invariants): Assertion '!ranges_overlap(map->avma, map->size, map2->avma, map2->size)' failed. valgrind: DiCfsi invariant (1) verification failed host stacktrace: ==6286==at 0x58041CF9: show_sched_status_wrk (m_libcassert.c:406) ==6286==by 0x58041E20: report_and_quit (m_libcassert.c:477) ==6286==by 0x58041F14: vgPlain_assert_fail (m_libcassert.c:543) ==6286==by 0x58075670: check_CFSI_related_invariants (debuginfo.c:692) ==6286==by 0x58075670: di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:992) ==6286==by 0x58075670: vgPlain_di_notify_mmap (debuginfo.c:1326) ==6286==by 0x580A8D51: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2400) ==6286==by 0x580B5F25: vgSysWrap_x86_linux_sys_mmap2_before (syswrap-x86-linux.c:987) ==6286==by 0x580A45BE: vgPlain_client_syscall (syswrap-main.c:1914) ==6286==by 0x580A090C: handle_syscall (scheduler.c:1208) ==6286==by 0x580A246F: vgPlain_scheduler (scheduler.c:1526) ==6286==by 0x580F7312: thread_wrapper (syswrap-linux.c:101) ==6286==by 0x580F7312: run_a_thread_NORETURN (syswrap-linux.c:154) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 192 (lwpid 6286) ==6286==at 0x435A253: mmap64 (mmap64.c:56) ==6286==by 0x7BCAAFFE: map_pe_header (virtual.c:1491) ==6286==by 0x7BCAC3E6: map_image (virtual.c:1569) ==6286==by 0x7BCADA02: virtual_map_section (virtual.c:1838) ==6286==by 0x7BC68BFC: open_dll_file (loader.c:2515) ==6286==by 0x7BC68DA8: search_dll_file (loader.c:3074) ==6286==by 0x7BC6923F: find_dll_file (loader.c:3154) ==6286==by 0x7BC6CBF9: load_dll (loader.c:3186) ==6286==by 0x7BC6C0F8: import_dll (loader.c:801) ==6286==by 0x7BC6C64B: fixup_imports (loader.c:1165) ==6286==by 0x7BC6C8AF: load_native_dll (loader.c:2570) ==6286==by 0x7BC6CB26: load_builtin_dll (loader.c:2930) ==6286==by 0x7BC6CE08: load_dll (loader.c:3231) ==6286==by 0x7BC6C0F8: import_dll (loader.c:801) ==6286==by 0x7BC6C64B: fixup_imports (loader.c:1165) ==6286==by 0x7BC6E372: LdrInitializeThunk (loader.c:3987) ==6286==by 0x7BC99953: attach_thread (signal_i386.c:3050) ==6286==by 0x7BC9634F: ??? (in /home/austin/wine-valgrind/dlls/ntdll/ntdll.dll.so) client stack range: [0x4A62000 0x4B5] client SP: 0x4B5D22C valgrind stack range: [0x881D3000 0x882D2FFF] top usage: 7092 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. e.g., avifil32/tests/api.c -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #23 from Austin English --- I usually use -p1, so not sure what was wrong..anyway, recently tried again, with a clean tree, and it applies fine, so yeah, it was something on my end. With the patch, I see an improvement using badfree.c from the original post: No patch: ==10542== Invalid free() / delete / delete[] / realloc() ==10542==at 0x7BC70261: notify_free (heap.c:268) ==10542==by 0x7BC70261: RtlFreeHeap.part.7 (???:0) ==10542==by 0x7BC72034: RtlFreeHeap (heap.c:1748) ==10542==by 0x516469D: msvcrt_heap_free (heap.c:114) ==10542==by 0x51651DF: MSVCRT_free (heap.c:414) ==10542==by 0x401599: ??? ==10542==by 0x401395: ??? ==10542==by 0x7B4504F1: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==10542==by 0x7B4508DF: start_process (process.c:153) ==10542==by 0x7B4504FD: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==10542== Address 0x87654321 is on thread 1's stack ==10542== Patch: ==8665== Invalid free() / delete / delete[] / realloc() ==8665==at 0x7BC70261: notify_free (heap.c:268) ==8665==by 0x7BC70261: RtlFreeHeap.part.7 (???:0) ==8665==by 0x7BC72034: RtlFreeHeap (heap.c:1748) ==8665==by 0x516469D: msvcrt_heap_free (heap.c:114) ==8665==by 0x51651DF: MSVCRT_free (heap.c:414) ==8665==by 0x401599: _main (badfree.c:12) ==8665==by 0x401395: ??? (crtexe.c:339) ==8665==by 0x7B4504F1: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==8665==by 0x7B4508DF: start_process (process.c:153) ==8665==by 0x7B4504FD: ??? (in /usr/local/lib64/wine/kernel32.dll.so) ==8665== Address 0x87654321 is on thread 1's stack ==8665== namely badfree.c:12 and crtexe.c:339. Note that there's some spurious output from the patch, e.g.,: size: 130284 @Julian, if feasible, it would be great to target this for valgrind-3.16.0. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #20 from Austin English --- (In reply to Jefferson Carpenter from comment #19) > Created attachment 126977 [details] > Hackish patch: Add read_pe_debug_info: v2 > > Fixed some of the most significant lies from my first patch. No longer > assumes .text is the first section. Instead of "main.exe" uses the basename > of the executable as the soname (I don't know whether this is even correct). > Uses correct-looking arenas for allocations. Correctly sorts symbols in > descending order and corrects addSym calls. Fails to build: make[3]: *** No rule to make target 'm_debuginfo/readpe.c', needed by 'm_debuginfo/libcoregrind_amd64_linux_a-readpe.o'. Stop. (try 1 compiles okay) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #16 from Austin English --- I recently tested llvm-mingw (from https://github.com/mstorsjo/llvm-mingw/), and built wine with llvm's pdb debug symbols. That gives similar results to gnu mingw: ==23786== Invalid read of size 2 ==23786==at 0x7B01F09E: ??? ==23786==by 0x60B93DA: ??? ==23786==by 0x60B89AC: ??? ==23786==by 0x507872F: ??? (in /home/austin/wine-valgrind-mingw/dlls/user32/user32.dll.so) ==23786==by 0x5078CFE: call_window_proc (winproc.c:249) ==23786==by 0x507A02C: WINPROC_CallProcAtoW (winproc.c:609) ==23786==by 0x507ABC4: WINPROC_call_window (winproc.c:956) ==23786==by 0x5043C8D: call_window_proc (message.c:2225) ==23786==by 0x5046E09: send_message (message.c:3294) ==23786==by 0x50498B9: SendMessageA (message.c:3517) ==23786==by 0x41C0A6: ??? ==23786==by 0x4143D1: ??? ==23786==by 0x49F862: ??? ==23786==by 0x49F71C: ??? ==23786==by 0x401394: ??? ==23786==by 0x7B449E31: ??? (in /home/austin/wine-valgrind-mingw/dlls/kernel32/kernel32.dll.so) ==23786==by 0x7B44A262: start_process (process.c:153) ==23786==by 0x7B449E3D: ??? (in /home/austin/wine-valgrind-mingw/dlls/kernel32/kernel32.dll.so) ==23786== Address 0x5ec1a08 is 744 bytes inside a block of size 1,024 free'd ==23786==at 0x7BC6255E: notify_free (heap.c:268) ==23786==by 0x7BC64B94: RtlFreeHeap (heap.c:1771) ==23786==by 0x52123C3: free_heap_bits (bitblt.c:168) ==23786==by 0x521CF08: nulldrv_StretchDIBits (dib.c:606) ==23786==by 0x521D285: StretchDIBits (dib.c:636) ==23786==by 0x500C450: create_icon_from_bmi (cursoricon.c:1265) ==23786==by 0x500D26B: CURSORICON_Load (cursoricon.c:1867) ==23786==by 0x500F153: LoadImageW (cursoricon.c:3065) ==23786==by 0x6111289: ??? ==23786==by 0x60B1CE7: ??? ==23786==by 0x61221E0: ??? ==23786==by 0x7BC667C9: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==23786==by 0x7BC6A582: MODULE_InitDLL (loader.c:1331) ==23786==by 0x7BC6A80A: process_attach (loader.c:1425) ==23786==by 0x7BC6CBD2: LdrLoadDll (loader.c:3094) ==23786==by 0x7B01436E: ??? ==23786==by 0x7B014279: ??? ==23786==by 0x7B01419B: ??? ==23786==by 0x7B01415E: ??? ==23786==by 0x4145B5: ??? ==23786== Block was alloc'd at ==23786==at 0x7BC62514: notify_alloc (heap.c:260) ==23786==by 0x7BC65377: RtlAllocateHeap (heap.c:1725) ==23786==by 0x5212AB4: convert_bits (bitblt.c:183) ==23786==by 0x521D045: nulldrv_StretchDIBits (dib.c:589) ==23786==by 0x521D285: StretchDIBits (dib.c:636) ==23786==by 0x500C450: create_icon_from_bmi (cursoricon.c:1265) ==23786==by 0x500D26B: CURSORICON_Load (cursoricon.c:1867) ==23786==by 0x500F153: LoadImageW (cursoricon.c:3065) ==23786==by 0x6111289: ??? ==23786==by 0x60B1CE7: ??? ==23786==by 0x61221E0: ??? ==23786==by 0x7BC667C9: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==23786==by 0x7BC6A582: MODULE_InitDLL (loader.c:1331) ==23786==by 0x7BC6A80A: process_attach (loader.c:1425) ==23786==by 0x7BC6CBD2: LdrLoadDll (loader.c:3094) ==23786==by 0x7B01436E: ??? ==23786==by 0x7B014279: ??? ==23786==by 0x7B01419B: ??? ==23786==by 0x7B01415E: ??? ==23786==by 0x4145B5: ??? ==23786== which is interesting, given that valgrind has some pdb support. LLVM uses the publicly documented pdb info from https://github.com/Microsoft/microsoft-pdb, fwiw. Note that I did run until other issues in some tests with this setup, see bug 416779. Tested with VALGRIND_3_15_0-193-gfe6805efc -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 416779] New: valgrind: m_debuginfo/debuginfo.c:454 (discard_or_archive_DebugInfo): Assertion '!di->have_dinfo || is_DebugInfo_active(di)' failed.
https://bugs.kde.org/show_bug.cgi?id=416779 Bug ID: 416779 Summary: valgrind: m_debuginfo/debuginfo.c:454 (discard_or_archive_DebugInfo): Assertion '!di->have_dinfo || is_DebugInfo_active(di)' failed. Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- Tested with VALGRIND_3_15_0-193-gfe6805efc STEPS TO REPRODUCE 1. build wine, with https://github.com/mstorsjo/llvm-mingw/ and enable pdb symbols 2. cd ./dlls/crypt32/tests 3. make cert.ok Result: ../../../tools/runtest -q -P wine -T ../../.. -M crypt32.dll -p crypt32_test.exe cert && touch cert.ok valgrind: m_debuginfo/debuginfo.c:454 (discard_or_archive_DebugInfo): Assertion '!di->have_dinfo || is_DebugInfo_active(di)' failed. host stacktrace: ==27633==at 0x58041809: show_sched_status_wrk (m_libcassert.c:406) ==27633==by 0x58041930: report_and_quit (m_libcassert.c:477) ==27633==by 0x58041A24: vgPlain_assert_fail (m_libcassert.c:543) ==27633==by 0x58072C1B: discard_or_archive_DebugInfo (debuginfo.c:454) ==27633==by 0x58072E24: discard_syms_in_range (debuginfo.c:526) ==27633==by 0x580751C8: vgPlain_di_notify_munmap (debuginfo.c:1336) ==27633==by 0x580AEE96: vgModuleLocal_notify_core_and_tool_of_munmap (syswrap-generic.c:246) ==27633==by 0x580AEE96: vgSysWrap_generic_sys_munmap_after (syswrap-generic.c:3949) ==27633==by 0x580A2829: vgPlain_post_syscall (syswrap-main.c:2172) ==27633==by 0x580A2E42: vgPlain_client_syscall (syswrap-main.c:2093) ==27633==by 0x5809EFFC: handle_syscall (scheduler.c:1208) ==27633==by 0x580A0B5F: vgPlain_scheduler (scheduler.c:1526) ==27633==by 0x580F58F2: thread_wrapper (syswrap-linux.c:101) ==27633==by 0x580F58F2: run_a_thread_NORETURN (syswrap-linux.c:154) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 91 (lwpid 27633) ==27633==at 0x437A2C6: munmap (syscall-template.S:78) ==27633==by 0x7BCA7BF1: unmap_area (virtual.c:799) ==27633==by 0x7BCA7C3F: delete_view (virtual.c:836) ==27633==by 0x7BCAC4F1: NtUnmapViewOfSection (virtual.c:3409) ==27633==by 0x7BC68D7C: free_modref (loader.c:3586) ==27633==by 0x7BC68E66: MODULE_FlushModrefs (loader.c:3613) ==27633==by 0x7BC6AB0B: LdrUnloadDll (loader.c:3687) ==27633==by 0x7B013D20: ??? ==27633==by 0x4BD0B9F: CryptFreeOIDFunctionAddress (oid.c:481) ==27633==by 0x4B9E51B: CertVerifyRevocation (cert.c:2024) ==27633==by 0x40AC79: ??? ==27633==by 0x4035BF: ??? ==27633==by 0x445332: ??? ==27633==by 0x4451EC: ??? ==27633==by 0x401394: ??? ==27633==by 0x7B449E31: ??? (in /home/austin/wine-valgrind-mingw/dlls/kernel32/kernel32.dll.so) ==27633==by 0x7B44A262: start_process (process.c:153) ==27633==by 0x7B449E3D: ??? (in /home/austin/wine-valgrind-mingw/dlls/kernel32/kernel32.dll.so) client stack range: [0x4A52000 0x4B4] client SP: 0x4B4FA58 valgrind stack range: [0x8815E000 0x8825DFFF] top usage: 16748 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. make[1]: *** [Makefile:234: cert.ok] Error 1 Expected result: Assertion doesn't fail austin@laptop ~/wine-valgrind/dlls/crypt32/tests (master) $ file *pdb crypt32_test.pdb: MSVC program database ver 7.00, 4096*194 bytes Note that this occurs for many, but not all, tests. Out of the first 176 tests (I had to stop for unrelated reasons), 41 tests showed this failure. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc
https://bugs.kde.org/show_bug.cgi?id=211031 --- Comment #15 from Austin English --- As of wine-4.6, wine now supports building its dlls with mingw: https://source.winehq.org/git/wine.git/commitdiff/a3cf86a18446e9d7df4e045b83d3aa3d9193512a the plan is to eventually make that the default (not sure if there's a timeline for that yet, but I would guess that before next stable release is likely). When compiling wine with mingw support, stacktraces are pretty poor. As a comparison, here's the same test with native gcc (8.3.0) versus mingw (i686-w64-mingw32-gcc (Gentoo 9.2.0-r2 p3) 9.2.0). With dlls/comctl32/tests/edit.c in wine-4.20-213-gddec23013e native: ==10945== Invalid read of size 2 ==10945==at 0x4F0C401: LocalLock (memory.c:661) ==10945==by 0x63FAE1A: EDIT_LockBuffer (edit.c:1195) ==10945==by 0x640216D: EDIT_WindowProc (edit.c:4608) ==10945==by 0x55FB4A7: ??? (in /home/austin/wine-valgrind-no-mingw/dlls/user32/user32.dll.so) ==10945==by 0x55FBA94: call_window_proc (winproc.c:249) ==10945==by 0x55FCEFE: WINPROC_CallProcAtoW (winproc.c:609) ==10945==by 0x55FDB4D: WINPROC_call_window (winproc.c:956) ==10945==by 0x55C38CE: call_window_proc (message.c:2225) ==10945==by 0x55C6EB6: send_message (message.c:3294) ==10945==by 0x55C9B02: SendMessageA (message.c:3517) ==10945==by 0x5016FDF: test_EM_GETHANDLE (edit.c:3041) ==10945==by 0x5018F22: func_edit (edit.c:3411) ==10945==by 0x50A0581: run_test (test.h:637) ==10945==by 0x50A0E08: main (test.h:721) ==10945== Address 0x4952a58 is 16 bytes after a recently re-allocated block of size 32 alloc'd ==10945==at 0x7BC6656F: notify_alloc (heap.c:260) ==10945==by 0x7BC695B5: RtlAllocateHeap (heap.c:1725) ==10945==by 0x59177B7: create_family (freetype.c:1594) ==10945==by 0x59278A4: load_font_list_from_cache (freetype.c:1768) ==10945==by 0x59283B9: WineEngInit (freetype.c:4458) ==10945==by 0x5928CCD: DllMain (gdiobj.c:693) ==10945==by 0x594011C: __wine_spec_dll_entry (dll_entry.c:44) ==10945==by 0x7BC6AA95: ??? (in /home/austin/wine-valgrind-no-mingw/dlls/ntdll/ntdll.dll.so) ==10945==by 0x7BC6EC1A: MODULE_InitDLL (loader.c:1331) ==10945==by 0x7BC6EEBB: process_attach (loader.c:1425) ==10945==by 0x7BC6EDFD: process_attach (loader.c:1411) ==10945==by 0x7BC6EDFD: process_attach (loader.c:1411) ==10945==by 0x7BC6EDFD: process_attach (loader.c:1411) ==10945==by 0x7BC715B9: LdrInitializeThunk (loader.c:3782) ==10945==by 0x7BC9C556: attach_thread (signal_i386.c:2746) ==10945==by 0x7BC991C3: ??? (in /home/austin/wine-valgrind-no-mingw/dlls/ntdll/ntdll.dll.so) mingw: ==15488== Invalid read of size 2 ==15488==at 0x7BC74A86: RtlInitNlsTables (locale.c:760) ==15488==by 0x7125EB11: ??? ==15488==by 0x7126254F: ??? ==15488==by 0x71262871: ??? ==15488==by 0x7BC6AAD5: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==15488==by 0x7BC6EC5A: MODULE_InitDLL (loader.c:1331) ==15488==by 0x7BC6EEFB: process_attach (loader.c:1425) ==15488==by 0x7BC6EE3D: process_attach (loader.c:1411) ==15488==by 0x7BC6EE3D: process_attach (loader.c:1411) ==15488==by 0x7BC715F9: LdrInitializeThunk (loader.c:3782) ==15488==by 0x7BC9D12A: attach_thread (signal_i386.c:2746) ==15488==by 0x7BC99D97: ??? (in /home/austin/wine-valgrind-mingw/dlls/ntdll/ntdll.dll.so) ==15488== Address 0x2 is not stack'd, malloc'd or (recently) free'd ==15488== interestingly, mingw shows RtlInitNlsTables while gcc doesn't (but that's likely it, since RtlInitNlsTables is in dlls/ntdll/locale.c at line 760 and that's the ??? in the gcc output. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 350228] Unhandled ioctl 0x6458 (i965/mesa)
https://bugs.kde.org/show_bug.cgi?id=350228 --- Comment #9 from Austin English --- Created attachment 119495 --> https://bugs.kde.org/attachment.cgi?id=119495&action=edit add DRM_IOCTL_I915_GEM_THROTTLE -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 350228] Unhandled ioctl 0x6458 (i965/mesa)
https://bugs.kde.org/show_bug.cgi?id=350228 --- Comment #8 from Austin English --- Created attachment 119494 --> https://bugs.kde.org/attachment.cgi?id=119494&action=edit Patch: mention strace as a data source for syscall/ioctl information -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 350228] Unhandled ioctl 0x6458 (i965/mesa)
https://bugs.kde.org/show_bug.cgi?id=350228 Austin English changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOT A BUG |--- Ever confirmed|0 |1 --- Comment #7 from Austin English --- Reopening, because I *finally* found something useful on github. strace has some info on this; apparently it can be: DRM_IOCTL_I915_GEM_THROTTLE, drm/i915_drm.h: https://github.com/strace/strace/blob/7cc6eb706ba7f67d1e84fe903e59ce824f799df5/linux/32/ioctls_inc_align16.h#L273 or: DRM_IOCTL_RADEON_CP_RESUME, drm/radeon_drm.h: https://github.com/strace/strace/blob/7cc6eb706ba7f67d1e84fe903e59ce824f799df5/linux/32/ioctls_inc_align16.h#L364 In my case it would be the intel definition (probably), as I've got a mixed intel/nvidia setup (but not radeon). note to self: check strace next time. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 350228] Unhandled ioctl 0x6458 (i965/mesa)
https://bugs.kde.org/show_bug.cgi?id=350228 --- Comment #6 from Austin English --- (In reply to Austin English from comment #5) > I asked in the intel-gfx and xorg IRC channels about these ioctls, and the > answers were basically "try newer Valgrind" and "look at the source..oh > they're not there, macros are a hell of a drug," so I don't expect upstream > to be very helpful. > > Given that I no longer have access to this hardware, I'm just going to close > this. I can reproduce this on my current hardware again; though I don't have any leads on actually fixing, so I'm not reopening (though it is reproducible again). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 400538] vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55
https://bugs.kde.org/show_bug.cgi?id=400538 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com --- Comment #7 from Austin English --- Okay, I can reproduce this, it needs a couple more valgrind arguments. # First, start a wine process (so that wineserver is running before valgrind starts): $ wine64 start /min winemine # Then, start notepad under valgrind: $ austin@laptop:~/src/valgrind$ valgrind --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access /opt/oldwow64/wine-4.5/bin/wine64 notepad ==2874== Memcheck, a memory error detector ==2874== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2874== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2874== Command: /opt/oldwow64/wine-4.5/bin/wine64 notepad ==2874== ==2874== Memcheck, a memory error detector ==2874== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2874== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2874== Command: /opt/oldwow64/wine-4.5/bin/wine64-preloader /opt/oldwow64/wine-4.5/bin/wine64 notepad ==2874== preloader: Warning: failed to reserve range 0011-6800 ==2874== vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 vex amd64->IR: unhandled instruction bytes: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==2874== valgrind: Unrecognised instruction at address 0x7bc9bff3. ==2874==at 0x7BC9BFF3: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874==by 0x7BC9C0CA: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874== Your program just tried to execute an instruction that Valgrind ==2874== did not recognise. There are two possible reasons for this. ==2874== 1. Your program has a bug and erroneously jumped to a non-code ==2874==location. If you are running Memcheck and you just saw a ==2874==warning about a bad jump, it's probably your program's fault. ==2874== 2. The instruction is legitimate but Valgrind doesn't handle it, ==2874==i.e. it's Valgrind's fault. If you think this is the case or ==2874==you are not sure, please let us know and we'll try to fix it. ==2874== Either way, Valgrind will now raise a SIGILL signal which will ==2874== probably kill your program. 005d:err:seh:segv_handler Got unexpected trap 0 ==2874== Invalid write of size 8 ==2874==at 0x7BC9BFF8: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874==by 0x7BC9BFF2: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874==by 0x7BC9C0CA: ??? (in /opt/oldwow64/wine-4.5/lib64/wine/ntdll.dll.so) ==2874== Address 0x7e20f4b8 is in a rw- anonymous segment ==2874== 005d:err:seh:NtRaiseException Unhandled exception code c01d flags 0 addr 0x7bc9bff3 ==2874== ==2874== HEAP SUMMARY: ==2874== in use at exit: 731,905 bytes in 6,501 blocks ==2874== total heap usage: 13,837 allocs, 7,336 frees, 2,963,926 bytes allocated ==2874== ==2874== LEAK SUMMARY: ==2874==definitely lost: 318 bytes in 2 blocks ==2874==indirectly lost: 0 bytes in 0 blocks ==2874== possibly lost: 0 bytes in 0 blocks ==2874==still reachable: 731,587 bytes in 6,499 blocks ==2874== suppressed: 0 bytes in 0 blocks ==2874== Rerun with --leak-check=full to see details of leaked memory ==2874== ==2874== For counts of detected and suppressed errors, rerun with: -v ==2874== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Tested with 3.15-rc1 / wine-4.5 -- You are receiving this mail because: You are watching all bug changes.
[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 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657 --- Comment #24 from Austin English --- (In reply to Daniel Lehman from comment #23) > > 0030:err:seh:NtRaiseException Unhandled exception code c01d flags 0 > > addr 0x7bc95b63 > > that's probably the iretq instruction from set_cpu_context > > > What VALGRIND_OPTS are you using? > > -v --trace-children=yes --error-limit=no --log-file=output.txt > --leak-check=full --leak-resolution=high --show-leak-kinds=all > > > did I miss a step? > > no, sorry, i forgot that i had to create a symlink to find the pdb: > ln -s $HOME $WINEPREFIX/drive_Y > because the baked-in path is Y:/stuff/leakage That's weird..when first trying this, I missed your 'drive_Y' bit and was symlinking to dosdevices/y:, which failed. With drive_Y, it works (not valgrind's problem, of course). I can verify that works for me: + /home/austin/src/valgrind/vg-in-place wine64 leakage.exe preloader: Warning: failed to reserve range 0011-6800 ==32694== Conditional jump or move depends on uninitialised value(s) ==32694==at 0x14005F7DE: __strncnt (strncnt.cpp:21) ==32694==by 0x7B9D4E0A8F2C: ??? ==32694== Uninitialised value was created by a stack allocation ==32694==at 0x14004BB17: setSBUpLow (in /tmp/tmp.sYSJGwj3qz/stuff/leakage/leakage.exe) ==32694== 7E018520 setframe: 7E20FCD0 7E01C6D0 006e:fixme:kernelbase:AppPolicyGetProcessTerminationMethod 0xfffa, 0x7e20fd10 ==32694== 12,345 bytes in 1 blocks are definitely lost in loss record 92 of 93 ==32694==at 0x7BC5BB35: initialize_block (heap.c:238) ==32694==by 0x7BC5BB35: RtlAllocateHeap (???:0) ==32694==by 0x140006BDA: a (leakage.c:9) ==32694==by 0x140006BF8: b (leakage.c:14) ==32694==by 0x140006C18: c (leakage.c:19) ==32694==by 0x140006CF8: main (leakage.c:43) ==32694== ==32694== 23,456 bytes in 1 blocks are definitely lost in loss record 93 of 93 ==32694==at 0x7BC5BB35: initialize_block (heap.c:238) ==32694==by 0x7BC5BB35: RtlAllocateHeap (???:0) ==32694==by 0x140006C8C: setframe (leakage.c:28) ==32694==by 0x140006CB8: d (leakage.c:33) ==32694==by 0x140006CD8: e (leakage.c:38) ==32694==by 0x140006D0C: main (leakage.c:44) ==32694== == For our valgrind friends, if you'd like to test Daniel's patch, here's a short script to do so. Get wine64 from your package manager (4.0 stable should work, or probably any version), then run the script, no special wine knowledge needed :) #!/bin/bash # Requires wine64 (nothing special needed, get it from your package manager) # and valgrind, of course export VALGRIND="${VALGRIND:-valgrind}" export VALGRIND_OPTS="-q --trace-children=yes --track-origins=yes --leak-check=full --num-callers=20 --vex-iropt-register-updates=allregs-at-mem-access" export WINEPREFIX="${WINEPREFIX:-$HOME/.wine}" tmpdir="$(mktemp -d)" cd "$tmpdir" mkdir -p stuff/leakage cd stuff/leakage wget -O stuff.tar.bz2 "https://bugs.kde.org/attachment.cgi?id=118764"; tar xjf stuff.tar.bz2 ln -sf "$tmpdir" "$WINEPREFIX/drive_Y" # Here we go: "$VALGRIND" wine64 leakage.exe cd rm -rf "$tmpdir" -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657 --- Comment #22 from Austin English --- That said, it's still an improvement. Without the patchset, I get: austin@laptop:~$ /opt/valgrind/bin/valgrind /opt/oldwow64/wine-4.0-rc1/bin/wine leakage.exe ; echo $? preloader: Warning: failed to reserve range 0011-6800 preloader: Warning: failed to reserve range 7f00-8200 preloader: Warning: failed to reserve range 0011-6800 0030:err:seh:segv_handler Got unexpected trap 0 ==6737== Invalid write of size 8 ==6737==at 0x7BC95B68: ??? (in /opt/oldwow64/wine-4.0-rc1/lib64/wine/ntdll.dll.so) ==6737==by 0x7BC95B62: ??? (in /opt/oldwow64/wine-4.0-rc1/lib64/wine/ntdll.dll.so) ==6737==by 0x7BC95C3A: ??? (in /opt/oldwow64/wine-4.0-rc1/lib64/wine/ntdll.dll.so) ==6737== Address 0x7e20f4b8 is in a rw- anonymous segment ==6737== 0030:err:seh:NtRaiseException Unhandled exception code c01d flags 0 addr 0x7bc95b63 29 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657 --- Comment #21 from Austin English --- (In reply to Daniel Lehman from comment #20) > Created attachment 118764 [details] > leakage.exe and pdb > > attached tested with: > - Visual Studio 2017 (15.9.8) > - wine 4.3 > - valgrind-3.15.0.GIT (4816357b5c7ee5284cdf72800a81d2dd1845388f) Thanks. I wasn't able to reproduce, with same valgrind git commit (+ your patches) and wine-4.0-rc1 (last wow64 build I have handy, but given that you used 3.15 before I don't think it matters). What VALGRIND_OPTS are you using? I tried with: austin@laptop:~$ export VALGRIND_OPTS="-q --trace-children=yes --track-origins=yes --leak-check=full --num-callers=20 --vex-iropt-register-updates=allregs-at-mem-access" and got: austin@laptop:~$ ~/src/valgrind/vg-in-place /opt/oldwow64/wine-4.0-rc1/bin/wine leakage.exe ; echo $? preloader: Warning: failed to reserve range 0011-6800 preloader: Warning: failed to reserve range 7f00-8200 preloader: Warning: failed to reserve range 0011-6800 ==6365== Conditional jump or move depends on uninitialised value(s) ==6365==at 0x14005F7DE: ??? ==6365==by 0x51B686B7C272: ??? ==6365== Uninitialised value was created by a stack allocation ==6365==at 0x14004BB17: ??? ==6365== 7E01B5F0 setframe: 7E20FCD0 7E01F7A0 ==6365== 12,345 bytes in 1 blocks are definitely lost in loss record 86 of 88 ==6365==at 0x7BC5B385: initialize_block (heap.c:238) ==6365==by 0x7BC5B385: RtlAllocateHeap (???:0) ==6365==by 0x140006BDA: ??? ==6365== ==6365== 23,456 bytes in 1 blocks are definitely lost in loss record 88 of 88 ==6365==at 0x7BC5B385: initialize_block (heap.c:238) ==6365==by 0x7BC5B385: RtlAllocateHeap (???:0) ==6365==by 0x140006C8C: ??? ==6365==by 0x51B686B7CD62: ??? ==6365== 0 did I miss a step? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657 --- Comment #19 from Austin English --- (In reply to Daniel Lehman from comment #18) > Created attachment 114891 [details] > simple test case for wine64 pdb Hi Daniel, Would you mind attaching a pre-built binary? I'd like to test this, but I don't currently have Visual Studio set up (and won't be able to for a week or so at the earliest). Thanks! -Austin -- You are receiving this mail because: You are watching all bug changes.
[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 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991 --- Comment #9 from Austin English --- (In reply to Julian Seward from comment #8) > (In reply to Austin English from comment #7) > > > Austin, can you show me the source of the signal handler involved? > > > > Yeah, it's here: > > https://source.winehq.org/git/wine.git/blob/ > > bfad5527acacbdbac623da57413a60c532218423:/dlls/kernel32/heap.c#l741 > > Hmm. While that is probably related, it is not a signal handler, > and it also isn't the source of the messages you showed in comment 6. > > The signal handling magic bits will somehow be hidden in the macros > __TRY (line 747), __EXCEPT_PAGE_FAULT (line 785) and __ENDTRY (line 791). > Can you show the definitions of those, so we can find the actual handler? > > A signal handler will have signature "void handler(int signo)" or > (more likely) "void handler(int signo, siginfo_t* siginfo, void* context)". Thanks for the pointer / sorry for the mixup. I believe what you're looking for is in: https://source.winehq.org/git/wine.git/blob/bfad5527acacbdbac623da57413a60c532218423:/include/wine/exception.h#l101 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991 --- Comment #7 from Austin English --- (In reply to Julian Seward from comment #6) > (In reply to Austin English from comment #5) > > While the situation has changed, it still differs from what I see on amd64. > > Log attached. > > Hmm. If I had to guess, I'd say that the signal frame that V creates > doesn't have enough details in it to keep the Wine signal handler happy. > > Austin, can you show me the source of the signal handler involved? Yeah, it's here: https://source.winehq.org/git/wine.git/blob/bfad5527acacbdbac623da57413a60c532218423:/dlls/kernel32/heap.c#l741 FYI wine's development IRC channel is #winehackers if you want to get more info (I think you already knew that, but just in case). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991 --- Comment #5 from Austin English --- Created attachment 115058 --> https://bugs.kde.org/attachment.cgi?id=115058&action=edit valgrind output While the situation has changed, it still differs from what I see on amd64. Log attached. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991 --- Comment #2 from Austin English --- 4:49:22 AM austin_laptop if someone with decent understanding of kernel32/heap.c has a few minutes, I'd appreciate if someone could help me answer Julian's questions from https://bugs.kde.org/show_bug.cgi?id=395991 (I'm happy to forward your answers if you don't have a KDE bz account) 5:01:50 AM _Marcus_ austin_laptop: so if we take a segfault, the handler would run into the expcetion chain 5:02:02 AM _Marcus_ austin_laptop: but in general, globalalloc should not fault in my opinion 5:02:54 AM _Marcus_ SetLastError(MAGIC_DEAD); 5:02:54 AM _Marcus_ hsecond = GlobalFree(LongToHandle(0xdeadbeef)); /* bogus handle */ 5:03:01 AM _Marcus_ hmm, but this code does 5:03:07 AM austin_laptop thanks _Marcus_. Yeah, from a quick read of the code, I didn't see why it would segfault, but wasn't completely sure 5:03:29 AM _Marcus_ so basically we are running into the TRY / __EXCEPT_PAGE_FAULT block in GlobalFree 5:03:37 AM _Marcus_ the testcase causes it to fault 5:03:47 AM _Marcus_ but this is our generic exceptipon handling 5:04:10 AM austin_laptop ok 5:06:40 AM _Marcus_ something in the arm signal handling is not fully correct I would think :/ 5:07:11 AM austin_laptop yeah, that's likely 5:07:36 AM austin_laptop this is armv7l rather than arm64 (and at least on VG side, is not as complete) 5:07:37 AM _Marcus_ winedebug +heap should print the ERR("invalid handle %p\n", hmem); 5:07:48 AM _Marcus_ from GlobalFree, if it does not ... we are not getting there for some reason Note: I ran with +heap, but do not get that message, so something may be broke in wine's armv7l exception handling as well. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 375644] Unable to pair kdeconnect when connecting via OpenVPN, even if specifying hostname or IP address
https://bugs.kde.org/show_bug.cgi?id=375644 Austin changed: What|Removed |Added CC||potatom...@gmail.com --- Comment #9 from Austin --- (In reply to Matthijs Tijink from comment #8) > Sorry for the late reaction, I've been busy. > > What the PC log message means: the PC received the UDP packet from the phone > and tries to connect to the phone (using TCP). That fails (maybe because of > the thing I mentioned, maybe not), so it tries the reverse: it sends out an > UDP message so the phone will instead connect to the PC. As your issue > indicates, that doesn't work either. > > Since the android log does not contain a message that it received an UDP > package, the direction UDP/TCP from PC to phone does not work. > > As I read your earlier messages, you can ping/ssh/etc. from your PC to your > phone correctly in the same network setup. Can you confirm this for me? If > so, we've pinpointed the issue somewhat (although hard to test for me). Not the OP but also the same problem here. Using a VPN on my android phone results in the same result with not being able to connect. I can confirm that I can ping my phone from my pc with no issue. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 332917] Valgrind should warn the user that SSE4 is not supported in the 32-bit mode
https://bugs.kde.org/show_bug.cgi?id=332917 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 344802] disInstr(arm): unhandled instruction: 0xEC510F1E
https://bugs.kde.org/show_bug.cgi?id=344802 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991 Austin English changed: What|Removed |Added Platform|Other |Compiled Sources --- Comment #1 from Austin English --- Using valgrind-3.14.0.GIT-90daa486e8-20180620 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395991] New: wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used
https://bugs.kde.org/show_bug.cgi?id=395991 Bug ID: 395991 Summary: wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used Product: valgrind Version: 3.14 SVN Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- This affects several tests on armv7l (arm64 and amd64 are NOT affected). The list of affected tests so far: dlls/comctl32/tests/imagelist.ok dlls/comctl32/tests/treeview.ok dlls/crypt32/tests/encode.ok dlls/d3d8/tests/visual.ok dlls/d3d9/tests/d3d9ex.ok dlls/d3d10core/tests/device.ok dlls/d3d11/tests/d3d11.ok dlls/imm32/tests/imm32.ok dlls/kernel32/tests/file.ok dlls/kernel32/tests/heap.ok dlls/kernel32/tests/thread.ok dlls/kernel32/tests/virtual.ok dlls/msacm32/tests/msacm.ok dlls/msvcp90/tests/misc.ok dlls/ntdll/tests/file.ok dlls/ntdll/tests/time.ok dlls/oleaut32/tests/safearray.ok dlls/oleaut32/tests/tmarshal.ok dlls/ws2_32/tests/sock.ok I ran with --trace-signals=yes, which showed an infinite loop. E.g., for dlls/kernel32/tests/heap, I got: --7171-- sync signal handler: signal=11, si_code=1, EIP=0x546a784, eip=0x687bbd4c, from kernel --7171-- SIGSEGV: si_code=1 faultaddr=0xdeadbeed tid=1 ESP=0x5affb00 seg=0xbebf7000-0xfffe --7171-- delivering signal 11 (SIGSEGV):1 to thread 1 --7171-- push_signal_frame (thread 1): signal 11 ==7171== at 0x546A784: GlobalFree (heap.c:762) ==7171== by 0x5854AA3: test_heap (heap.c:220) ==7171== by 0x58560F3: func_heap (heap.c:1233) ==7171== by 0x57EE75F: main (test.h:615) --7171-- VG_(sigframe_create): continuing in handler with PC=0x4fc627c --7171-- vg_pop_signal_frame (thread 1): isRT=1 valid magic; PC=0x546a784 endlessly. Speaking with Julian about it, armv7l may need some extra work that's already done for arm64. I need to track down some extra info for him, first: == So the program takes a segfault at 0x546A784 which is GlobalFree (heap.c:762), runs the handler, which returns (unusual for a segfault handler), and it then restarts the faulting insn 0x546A784, so it continues indefinitely. Can you dig into this a bit further, to verify what's going on? I'd prefer to be a bit more sure about it before hacking up a patch. In particular: (1) do you expect there to be a segfault raised at heap.c:762 ? (2) can you identify the fault handler being run? How is the program supposed to make forward progress after the handler returns? Does it modify the PC in the mcontext, or is there something else going on? If you can find the handler, can you give me a pointer to it? Number (2) is really the most important. == I'm travelling, so that will likely be next week. I wanted to a have a bug filed that I could share with wine guys in the meantime, though ;) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 266035] Support running Valgrind for Android on ARM
https://bugs.kde.org/show_bug.cgi?id=266035 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395777] disInstr(arm): unhandled instruction: 0xE7F000F0 (wine, dlls/msvcp90/tests/misc.c)
https://bugs.kde.org/show_bug.cgi?id=395777 --- Comment #1 from Austin English --- That seems to be #define FBT_BREAKPOINT 0xe7f000f0 according to https://github.com/F-Stack/f-stack/blob/master/freebsd/arm/include/trap.h There's only a few more in that header, so it may be worth implementing all at the same time: #define GDB_BREAKPOINT 0xe611 #define GDB5_BREAKPOINT 0xe7ffdefe #define PTRACE_BREAKPOINT 0xe7f0 #define KERNEL_BREAKPOINT 0xe7ff #define FBT_BREAKPOINT 0xe7f000f0 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395777] New: disInstr(arm): unhandled instruction: 0xE7F000F0 (wine, dlls/msvcp90/tests/misc.c)
https://bugs.kde.org/show_bug.cgi?id=395777 Bug ID: 395777 Summary: disInstr(arm): unhandled instruction: 0xE7F000F0 (wine, dlls/msvcp90/tests/misc.c) Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- As description states: disInstr(arm): unhandled instruction: 0xE7F000F0 cond=14(0xE) 27:20=127(0x7F) 4:4=1 3:0=0(0x0) found when running wine's unit tests, specifically dlls/msvcp90/tests/misc.c (stretch)austin@localhost:~/src/valgrind$ /opt/valgrind/bin/valgrind --version -v valgrind-3.14.0.GIT-90daa486e8-20180620 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 253657] missing some amd64 to let wine/amd64 run on valgrind/amd64
https://bugs.kde.org/show_bug.cgi?id=253657 Austin English changed: What|Removed |Added CC||austinengl...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[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 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.
[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.
[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 #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 #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] 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.
[valgrind] [Bug 387686] valgrind-3.13.0 tests on Gentoo fail with glibc-2.26 (work with glibc-2.25).
https://bugs.kde.org/show_bug.cgi?id=387686 Austin English changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Austin English --- Closing. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 387686] valgrind-3.13.0 tests on Gentoo fail with glibc-2.26 (work with glibc-2.25).
https://bugs.kde.org/show_bug.cgi?id=387686 Austin English changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Austin English --- My fault for not testing git first. This was already fixed, by: 2b5eab6a8db1b0487a3ad7fc4e7eeda6d3513626 Author: Mark Wielaard Date: Thu Jun 29 15:26:30 2017 + memcheck/tests: Use ucontext_t instead of struct ucontext -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 387686] New: valgrind-3.13.0 tests on Gentoo fail with glibc-2.26 (work with glibc-2.25).
https://bugs.kde.org/show_bug.cgi?id=387686 Bug ID: 387686 Summary: valgrind-3.13.0 tests on Gentoo fail with glibc-2.26 (work with glibc-2.25). Product: valgrind Version: 3.13.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- Created attachment 109247 --> https://bugs.kde.org/attachment.cgi?id=109247&action=edit test failures Originally reported here: https://bugs.gentoo.org/637488 the valgrind-3.13.0 unit tests fail on an unstable Gentoo machine. They work for me on my stable machine. Testing in a chroot, I was able to find that glibc is the source of the problem. The working machine has: sys-libs/glibc-2.25-r9, while sys-libs/glibc-2.26-r3 is broken. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #15 from Austin English --- (In reply to Julian Seward from comment #14) > Landed, c470e0c23c6c79deec943cb6a111b572fc86dbba. Thanks for the quick fix! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #13 from Austin English --- Created attachment 108909 --> https://bugs.kde.org/attachment.cgi?id=108909&action=edit output with patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #12 from Austin English --- Created attachment 108908 --> https://bugs.kde.org/attachment.cgi?id=108908&action=edit output without patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #11 from Austin English --- (In reply to Julian Seward from comment #10) > Created attachment 108896 [details] > TPIDRURW support for 32-bit arm > > This runs the test program shown in comment 6, correctly, both for > Thumb and ARM encodings. For 32 bit only. Austin, can you test this? Seems to work for me, thanks! I'm going to attach logs with/without the patch. I used --verbose instead of -q, which then showed the missing info: disInstr(arm): unhandled instruction: 0xEE0D4F50 cond=14(0xE) 27:20=224(0xE0) 4:4=1 3:0=0(0x0) ==4434== valgrind: Unrecognised instruction at address 0x4fc3bb4. ==4434==at 0x4FC3BB4: signal_init_thread (signal_arm.c:974) ==4434==by 0x4FCACF7: thread_init (thread.c:354) ==4434==by 0x4FA1433: __wine_process_init (loader.c:3341) ==4434==by 0x485FBC3: wine_init (loader.c:979) ==4434==by 0x108A27: main (main.c:258) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #7 from Austin English --- Re arm/thumb: so you said it's arm encoding. I noticed that configure.ac requires thumb? Do both get used? yes, most of wine should be arm what's thumb used for? Windows Apps are Thumb-2, and to call into such functions we need the command "blx" (branch and link while exchanging instruction set if necessary, or something like that), if the compiler targets non-thumb (e.g. arm-only) it doesn't like bx and blx so it targets both arm and thumb? the compiler, yes the instruction I'm checking this right now the instruction encoding seems to be exactly the same for both arm and thumb-2 it's definitely arm -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #6 from Austin English --- (In reply to Julian Seward from comment #4) > (In reply to Julian Seward from comment #3) > > IIUC, TPIDRURW is a 32 bit register that can be both read and > > written from user space. Yes? Does it require any special handling? > > To clarify .. what I mean to ask is: does TPIDRURW behave like a "normal" > integer register, in that each thread has its own copy and can read and > write it independently of other threads? Or does it have some other > behaviour? >From Andre: >> Sure, >> >> it should be ARM encoding. trpidrurw is rw from userspace and needs no >> permissions > Is it specific per thread or shared across? > per thread maybe https://github.com/AndreRH/tpidrurw-test can help to understand it -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #2 from Austin English --- Forgot to include, some background on why we're doing that: https://patchwork.kernel.org/patch/2536641/ -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 --- Comment #1 from Austin English --- (stretch)austin@localhost:~/src/valgrind$ uname -a Linux localhost 3.14.0 #1 SMP PREEMPT Wed Oct 25 21:59:24 PDT 2017 armv7l GNU/Linux (stretch)austin@localhost:~/src/valgrind$ /opt/valgrind/bin/valgrind -v --version valgrind-3.14.0.GIT (confused why that doesn't show the git hash..) (stretch)austin@localhost:~/src/valgrind$ tail -n 1 include/vgversion.h #define VGGIT "2f9cceafa3-20171028" -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386425] New: running valgrind + wine on armv7l gives illegal opcode
https://bugs.kde.org/show_bug.cgi?id=386425 Bug ID: 386425 Summary: running valgrind + wine on armv7l gives illegal opcode Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- Every test fails the same way: (stretch)austin@localhost:~/wine-git/dlls/advapi32/tests$ make service.ok ../../../tools/runtest -q -P wine -T ../../.. -M advapi32.dll -p advapi32_test.exe.so service && touch service.ok ==20504== ==20504== Process terminating with default action of signal 4 (SIGILL) ==20504== Illegal opcode at address 0x4FC2C54 ==20504==at 0x4FC2C54: signal_init_thread (signal_arm.c:974) ==20504==by 0x4FCA7CB: thread_init (thread.c:354) ==20504==by 0x4F9F303: __wine_process_init (loader.c:3341) ==20504==by 0x485FBC3: wine_init (loader.c:979) ==20504==by 0x108A27: main (main.c:258) Illegal instruction (core dumped) Makefile:374: recipe for target 'service.ok' failed make: *** [service.ok] Error 132 I reviewed this with the wine ARM maintainer, who pointed out it's likely a valgrind bug. The code in question: https://source.winehq.org/git/wine.git/blob/40b7831cd80607e42b9e1c910a62f022c45ac884:/dlls/ntdll/signal_arm.c#l959 Removing the TEB/TPIDRURW handling get's past this: diff --git a/dlls/ntdll/signal_arm.c b/dlls/ntdll/signal_arm.c index e5e314049e..df050a96ae 100644 --- a/dlls/ntdll/signal_arm.c +++ b/dlls/ntdll/signal_arm.c @@ -968,12 +968,6 @@ void signal_init_thread( TEB *teb ) pthread_key_create( &teb_key, NULL ); init_done = TRUE; } - -#if defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_8A__) -/* Win32/ARM applications expect the TEB pointer to be in the TPIDRURW register. */ -__asm__ __volatile__( "mcr p15, 0, %0, c13, c0, 2" : : "r" (teb) ); -#endif - pthread_setspecific( teb_key, teb ); } and now tests work. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382978] valgrind: LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format
https://bugs.kde.org/show_bug.cgi?id=382978 --- Comment #2 from Austin English --- Forgot to mention in first comment; the PDB format is now publicly documented, at https://github.com/Microsoft/microsoft-pdb -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382515] valgrind: "Assertion 'di->have_dinfo' failed." on wine's dlls/mscoree/tests/mscoree.c
https://bugs.kde.org/show_bug.cgi?id=382515 Austin English changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #14 from Austin English --- (In reply to Philippe Waroquiers from comment #13) > Thanks for the testing > Patch committed as revision 16465. > > As discussed in comment 12, really handling this kind of debug info > will be another bug (if needed) Fixed in r16465, thanks Philippe. Next bug is bug 382978. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382978] valgrind: LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format
https://bugs.kde.org/show_bug.cgi?id=382978 --- Comment #1 from Austin English --- Created attachment 106999 --> https://bugs.kde.org/attachment.cgi?id=106999&action=edit makecert.pdb I'm also attaching a small pdb file that may be easier to analyze. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382978] New: valgrind: LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format
https://bugs.kde.org/show_bug.cgi?id=382978 Bug ID: 382978 Summary: valgrind: LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: austinengl...@gmail.com Target Milestone: --- Created attachment 106998 --> https://bugs.kde.org/attachment.cgi?id=106998&action=edit mscorlib.pdb Microsoft's C# compiler (Rosylyn, also used by Mono, https://github.com/dotnet/roslyn/) generates PDBs that are of a different format than those generated by Visual Studio for C/C++. This revealed itself because wine-mono accidentally shipped .pdb files, and running wine's dlls/mscoree/tests/mscoree.c tests crashed valgrind (bug 382515). Now, it ignores those pdb files instead. It would be nice if these files were supported, but at least for Wine, it's probably not worth the effort, as only a tiny part of the code uses it. But if valgrind becomes popular for C#, it may be more important. ==1193== Warning: Missing or un-stat-able /home/austin/.wine/drive_c/windows/mono/mono-2.0/bin/libmono-2.0-x86.pdb ==1193== LOAD_PDB_DEBUGINFO: \032 header character not found. possible invalid/unsupported pdb file format? ==1193== LOAD_PDB_DEBUGINFO: find_pdb_header found no hdr. possible invalid/unsupported pdb file format? ==1193== LOAD_PDB_DEBUGINFO: failed loading info from /home/austin/.wine/drive_c/windows/mono/mono-2.0/lib/mono/4.5/mscorlib.pdb -- You are receiving this mail because: You are watching all bug changes.