[Heaptrack] [Bug 475982] pass signals to debugee

2023-10-28 Thread Hamish Moffatt
https://bugs.kde.org/show_bug.cgi?id=475982

--- Comment #2 from Hamish Moffatt  ---
(In reply to Milian Wolff from comment #1)
> then I pressed `Ctrl+C` which stops the process then and opens up the UI.
> Sleep isn't running anymore at that point, only the heaptrack UI:

But then your signal went straight to sleep. If you send it to heaptrack,
heaptrack will exit leaving the debuggee running. This is what happens if you
run it in a container or from systemd. Not only is the child still running, the
analysis is wrong because the child didn't get to run a clean shutdown.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Heaptrack] [Bug 475982] New: pass signals to debugee

2023-10-22 Thread Hamish Moffatt
https://bugs.kde.org/show_bug.cgi?id=475982

Bug ID: 475982
   Summary: pass signals to debugee
Classification: Applications
   Product: Heaptrack
   Version: 1.5.0
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: m...@milianw.de
  Reporter: hamish+...@risingsoftware.com
  Target Milestone: ---

tl;dr: could heaptrack pass signals along to the debugee?

SUMMARY
I'm trying to debug a program which runs in a container. This program normally
runs as the entrypoint of the container, but now I run it inside heaptrack. To
stop the container, the runtime sends SIGINT or SIGTERM to the primary process,
which would cleanly shut down my program but does not get passed through the
heaptrack shell script.

Eventually the container runtime kills all the processes. As a result it looks
like all the memory got leaked because the program did not go through a clean
shutdown.

The same would apply if running heaptrack from a systemd unit.

STEPS TO REPRODUCE
1.  Run `heaptrack /usr/bin/sleep 60`
2.  Send SIGINT or SIGTERM to heaptrack

OBSERVED RESULT
heaptrack exits on SIGTERM but sleep is still running
SIGINT seems to be ignored completely

EXPECTED RESULT
SIGTERM is sent to debugee

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian bookworm + heaptrack 1.4.0 from package, or heaptrack
1.5.0 compiled from source

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 457061] crash opening any folder on macOS 10.14

2022-07-24 Thread Hamish Moffatt
https://bugs.kde.org/show_bug.cgi?id=457061

--- Comment #2 from Hamish Moffatt  ---
So it was only crashing on specific folders and I found that one of them had
some zero byte JPEG files. Once I removed those, it has stopped crashing. There
are zero byte JPEGs in other folders too though which don't seem to be causing
a problem.

All the zero byte files also have the com.apple.quarantine xattr set.

Now that it's working there's probably not much else to go on unfortunately.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 457061] New: crash opening any folder on macOS 10.14

2022-07-24 Thread Hamish Moffatt
https://bugs.kde.org/show_bug.cgi?id=457061

Bug ID: 457061
   Summary: crash opening any folder on macOS 10.14
   Product: digikam
   Version: 7.7.0
  Platform: macOS (DMG)
OS: macOS
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: digikam-bugs-n...@kde.org
  Reporter: hamish+...@risingsoftware.com
  Target Milestone: ---

Created attachment 150861
  --> https://bugs.kde.org/attachment.cgi?id=150861=edit
macOS crash report

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. Open DigiKam 7.7.0 on macOS 10.14
2. Wait until all pictures imported
3. Restart DigiKam
4. Select any folder -> crash


OBSERVED RESULT
Application crashes every time.

EXPECTED RESULT
Application works.

SOFTWARE/OS VERSIONS
macOS: 10.14

ADDITIONAL INFORMATION
Apple format crash report attached.

-- 
You are receiving this mail because:
You are watching all bug changes.

[clazy] [Bug 444469] New: clazy missing link to libstdc++fs

2021-10-26 Thread Hamish Moffatt
https://bugs.kde.org/show_bug.cgi?id=69

Bug ID: 69
   Summary: clazy missing link to libstdc++fs
   Product: clazy
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: hamish-...@risingsoftware.com
CC: smart...@kde.org
  Target Milestone: ---

SUMMARY

clazy 1.10 fails to build on Debian 10 because it needs to link against
libstdc++fs.


STEPS TO REPRODUCE
1. Install llvm-11, llvm-11-dev, libclang-11-dev, libclang-cpp11-dev from
buster backports
2. Configure with PATH=/usr/lib/llvm-11/bin:$PATH cmake ..
3. make


OBSERVED RESULT

clazy-standalone fails to link with the error:

/usr/bin/ld: lib/ClazyPlugin.so: undefined reference to
`std::filesystem::__cxx11::path::_M_find_extension() const'
/usr/bin/ld: lib/ClazyPlugin.so: undefined reference to
`std::filesystem::__cxx11::path::_M_split_cmpts()'

Adding stdc++fs to the link libraries in CMakeLists.txt fixes it.

libstdc++ is from gcc 8. It works on Debian 11 (bullseye) which has libstdc++
from gcc 10.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 376870] New: The impossible happened on Mavericks 10.9

2017-02-23 Thread Hamish Moffatt
https://bugs.kde.org/show_bug.cgi?id=376870

Bug ID: 376870
   Summary: The impossible happened on Mavericks 10.9
   Product: valgrind
   Version: 3.12.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: memcheck
  Assignee: jsew...@acm.org
  Reporter: hamish-...@risingsoftware.com
  Target Milestone: ---

I am trying to run my app in memcheck on Mavericks/10.9. (It is actually
running in a 10.9 virtual machine in Parallels 11, because the host is running
Sierra/10.12 which is not supported yet.)

I got quite a few messages about an unhandled syscall:

--10283-- WARNING: unhandled amd64-darwin syscall: unix:446
--10283-- You may be able to write your own handler.
--10283-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--10283-- Nevertheless we consider this a bug.  Please report
--10283-- it at http://valgrind.org/support/bug_reports.html.

At the point when I expected my program to crash, I got:

eq_SyscallStatus:
  {78 0 43}
  {78 0 40}

valgrind: m_syswrap/syswrap-main.c:438 (Bool eq_SyscallStatus(UInt,
SyscallStatus *, SyscallStatus *)): the 'impossible' happened.

host stacktrace:
==10283==at 0x238042521: ???
==10283==by 0x238042932: ???
==10283==by 0x238042915: ???
==10283==by 0x2380C13FE: ???
==10283==by 0x2380C0989: ???
==10283==by 0x2380BEDDB: ???
==10283==by 0x2380BCCCD: ???
==10283==by 0x2380CE1CC: ???

sched status:
  running_tid=1


and a stack trace.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 372779] valgrind will hang

2017-02-23 Thread Hamish Moffatt
https://bugs.kde.org/show_bug.cgi?id=372779

Hamish Moffatt <hamish-...@risingsoftware.com> changed:

   What|Removed |Added

 CC||hamish-kde@risingsoftware.c
   ||om

--- Comment #2 from Hamish Moffatt <hamish-...@risingsoftware.com> ---
I am also seeing this when trying to run a large application in valgrind 3.12
on OS X 10.11. I got a few UNKNOWN mach_msg messages on startup, and then my
program hung with valgrind using 100% CPU. I waited over 1 hour and it never
launched.

-- 
You are receiving this mail because:
You are watching all bug changes.