[kwin] [Bug 484358] Automatic adaptive sync fails to deactivate on exit

[Austin Kauble]

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

[Austin Kauble]

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)

[Nick Austin]

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=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)

[Nick Austin]

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

[Austin English]

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?

[Austin Huang]

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?

[Austin Huang]

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

[Austin Huang]

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

[Austin Huang]

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

[Austin Huang]

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

[Austin Huang]

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

[Austin Huang]

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

[Austin Smith]

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  

[NeoChat] [Bug 476731] Room preview: username height affects room avatar height, breaking layout

[Austin Huang]

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=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

[Austin Huang]

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=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

[Austin Keeton]

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

[Austin Keeton]

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

[Austin Keeton]

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

[Austin Keeton]

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=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

[Austin]

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

[Austin]

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

[Austin]

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

[Austin]

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

[Austin]

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

[Austin]

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

[Austin English]

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

[Austin Keeton]

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=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

[Austin]

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=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

[Austin English]

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

[Austin English]

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

[Austin English]

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

[Austin English]

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

[Austin English]

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=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

[Austin Kilgore]

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

[Austin Kilgore]

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

[Austin Kilgore]

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

[Austin English]

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

[Austin English]

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=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

[Austin English]

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

[Austin English]

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=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

[Austin English]

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

[Austin Kilgore]

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 

[kmenuedit] [Bug 426822] New: KDE menu system crashes at "save"

[William Austin]

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 

[valgrind] [Bug 211031] valgrind doesn't show symbols for programs compiled with mingw's gcc

[Austin English]

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=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

[Austin English]

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=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

[Austin English]

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

[Austin English]

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

[Austin English]

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

[Austin English]

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

[Austin English]

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.

[Austin English]

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

[Austin English]

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)

[Austin English]

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=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)

[Austin English]

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=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)

[Austin English]

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)

[Austin English]

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

[Austin English]

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

[Austin Kilgore]

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

[Austin English]

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

[Austin English]

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

[Austin English]

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

[Austin English]

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

[Austin Butler]

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

[Austin Kilgore]

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

[valgrind] [Bug 395991] wine's unit tests enter a signal delivery loop under valgrind on armv7l when SIGSEGV is used

[Austin English]

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

[Austin English]

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

[Austin English]

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=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

[Austin English]

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

[Austin]

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

[Austin English]

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

[Austin English]

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

[Austin English]

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

[Austin English]

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

[Austin English]

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)

[Austin English]

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)

[Austin English]

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

[Austin English]

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.

[William Austin]

https://bugs.kde.org/show_bug.cgi?id=329918

--- Comment #5 from William Austin <wwaus...@gmail.com> ---
On 2018-01-26 19:08, Daniel Nicoletti wrote:
> https://bugs.kde.org/show_bug.cgi?id=329918
>
> --- Comment #4 from Daniel Nicoletti <dantt...@gmail.com> ---
> 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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=338252

Austin English <austinengl...@gmail.com> changed:

   What|Removed |Added

 CC||austinengl...@gmail.com

--- Comment #11 from Austin English <austinengl...@gmail.com> ---
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

[Austin Howard]

https://bugs.kde.org/show_bug.cgi?id=389642

--- Comment #4 from Austin Howard <stevenaustinhow...@gmail.com> ---
Created attachment 110222
  --> https://bugs.kde.org/attachment.cgi?id=110222=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

[Austin Howard]

https://bugs.kde.org/show_bug.cgi?id=389642

--- Comment #3 from Austin Howard <stevenaustinhow...@gmail.com> ---
Created attachment 110221
  --> https://bugs.kde.org/attachment.cgi?id=110221=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

[Austin Howard]

https://bugs.kde.org/show_bug.cgi?id=389642

--- Comment #2 from Austin Howard <stevenaustinhow...@gmail.com> ---
Created attachment 110220
  --> https://bugs.kde.org/attachment.cgi?id=110220=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

[Austin Howard]

https://bugs.kde.org/show_bug.cgi?id=389642

--- Comment #1 from Austin Howard <stevenaustinhow...@gmail.com> ---
Created attachment 110219
  --> https://bugs.kde.org/attachment.cgi?id=110219=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

[Austin Howard]

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=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).

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=387686

Austin English <austinengl...@gmail.com> changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #2 from Austin English <austinengl...@gmail.com> ---
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).

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=387686

Austin English <austinengl...@gmail.com> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Austin English <austinengl...@gmail.com> ---
My fault for not testing git first. This was already fixed, by:
2b5eab6a8db1b0487a3ad7fc4e7eeda6d3513626
Author: Mark Wielaard <m...@klomp.org>
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).

[Austin English]

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=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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=386425

--- Comment #15 from Austin English <austinengl...@gmail.com> ---
(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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=386425

--- Comment #13 from Austin English <austinengl...@gmail.com> ---
Created attachment 108909
  --> https://bugs.kde.org/attachment.cgi?id=108909=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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=386425

--- Comment #12 from Austin English <austinengl...@gmail.com> ---
Created attachment 108908
  --> https://bugs.kde.org/attachment.cgi?id=108908=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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=386425

--- Comment #11 from Austin English <austinengl...@gmail.com> ---
(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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=386425

--- Comment #7 from Austin English <austinengl...@gmail.com> ---
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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=386425

--- Comment #6 from Austin English <austinengl...@gmail.com> ---
(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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=386425

--- Comment #2 from Austin English <austinengl...@gmail.com> ---
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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=386425

--- Comment #1 from Austin English <austinengl...@gmail.com> ---
(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

[Austin English]

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( _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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=382978

--- Comment #2 from Austin English <austinengl...@gmail.com> ---
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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=382515

Austin English <austinengl...@gmail.com> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Austin English <austinengl...@gmail.com> ---
(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

[Austin English]

https://bugs.kde.org/show_bug.cgi?id=382978

--- Comment #1 from Austin English <austinengl...@gmail.com> ---
Created attachment 106999
  --> https://bugs.kde.org/attachment.cgi?id=106999=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

[Austin English]

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=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.