Re: ci: Improve OpenBSD core dump backtrace handling - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: ci: Improve OpenBSD core dump backtrace handling
Date
Msg-id CA+hUKG+xe9x-A5mumWS2xiKT0m-CO-H8wBt3skhR+2hzLY8oRw@mail.gmail.com
Whole thread Raw
In response to ci: Improve OpenBSD core dump backtrace handling  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
List pgsql-hackers
On Sat, Oct 25, 2025 at 2:20 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
> Any feedback would be appreciated.

+        filename=$(basename "$corefile")
+        base=$(echo "$filename" | sed 's/\.core.*$//')
+        binary=$(find "$executable_directory" -type f -name "$base"
2>/dev/null | head -n 1)
+
+        if [ -z "$binary" ]; then
+            echo "${base} executable can not be found in
${executable_directory}"
+            continue
+        fi
+
+        lldb "$binary" -c "$corefile" --batch -o 'thread backtrace
all' -o 'quit'

s/can not/cannot/, I don't make the rules...

Maybe if not found it should just run it the old way without the
executable?  We don't really expect other programs to be dumped (well,
sometimes we abort cp etc, something I plan to fix...), and they're
probably stripped anyway, but I guess we might as well try to show as
much information as we can if it happens?  Would it be better to set
PATH to $executable_directory:$PATH and use "which"?



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Instability of phycodorus in pg_upgrade tests with JIT
Next
From: David Rowley
Date:
Subject: Re: another autovacuum scheduling thread