Thread: psql -c tends to core dump if interrupted

In current sources, try the following:

while true; do
psql -c "checkpoint" yourdb
done

(any SQL command will do, it needn't be a checkpoint)

Press control-C while it's cycling.  A fair fraction of the time
I get a SEGV coredump from psql.

I've been able to replicate this on both HPUX and LinuxPPC, but I can't
get a useful traceback from either; apparently the stack is trashed.
For example HPUX just gives me

Core was generated by `psql'.
Program terminated with signal 11, Segmentation fault.

#0  0xc0149e14 in ?? () from /usr/lib/libc.1
(gdb) bt
#0  0xc0149e14 in ?? () from /usr/lib/libc.1
Cannot access memory at address 0xffffffac
(gdb)

Anyone else see this?  Can anyone else get a more helpful stack trace?

            regards, tom lane

I said:
> In current sources, try the following:
> while true; do
> psql -c "checkpoint" yourdb
> done

> (any SQL command will do, it needn't be a checkpoint)

> Press control-C while it's cycling.  A fair fraction of the time
> I get a SEGV coredump from psql.

Ah, I think I see the problem: if SIGINT is received before cancelConn
has been set, handle_sigint will do siglongjmp(main_loop_jmp, 1) ...
and the longjmp buffer is never set up in this control path.

Seems like there needs to be a main_loop_jmp_ready flag to prevent
an attempted siglongjmp before the buffer is set.  Or perhaps don't
establish the signal handler until main_loop_jmp is valid?

            regards, tom lane