Re: ci: Improve OpenBSD core dump backtrace handling

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: ci: Improve OpenBSD core dump backtrace handling
Date: 2025-10-24 21:41:17
Message-ID: CA+hUKG+xe9x-A5mumWS2xiKT0m-CO-H8wBt3skhR+2hzLY8oRw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 25, 2025 at 2:20 AM Nazir Bilal Yavuz <byavuz81(at)gmail(dot)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"?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-10-24 22:25:02 Re: another autovacuum scheduling thread
Previous Message Tom Lane 2025-10-24 21:31:59 Re: Instability of phycodorus in pg_upgrade tests with JIT