Thread

1. psql -c tends to core dump if interrupted

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-22T20:28:56Z

   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
   
   

2. Re: psql -c tends to core dump if interrupted

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-22T20:41:13Z

   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