On 13/04/10 21:16, Ben Madin wrote:
I have checked console, and there are many psql entries - I have attached two
as they all appear fairly similar, some numbers changing in this section :
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000002 rcx: 0x00007fff5fbff448
rdx: 0x0000000000000000
rdi: 0x0000000000002efd rsi: 0x0000000000000006 rbp: 0x00007fff5fbff460
rsp: 0x00007fff5fbff448
r8: 0x0000000000000e03 r9: 0x0000000000000000 r10: 0x00007fff868cf8ca
r11: 0x0000000000000202
r12: 0x00000001000d5000 r13: 0x00000001000d2000 r14: 0x0000000000000000
r15: 0x0000000000000003
rip: 0x00007fff868d3886 rfl: 0x0000000000000202 cr2: 0x0000000100188bd5
The ones that vary most are rdi, rcx, rbp, cr2 and r15.
Darn. There's no more information, like a numbered list of functions
(stack trace), list of linked libraries, etc? Maybe OS X only generates
that for GUI app crashes.
The stack trace is really what's needed. While it's possible to figure
out where a program crashed based on the thread state dump as shown
above, it doesn't give you any information about how it got there - and
that can be rather helpful.
Is there any chance you can run psql under gdb from the developer tools
and reproduce the fault that way? Then, when it crashes, get a backtrace?
Since you're clearly pretty familiar with the shell, I'll just
illustrate how to do it:
$ gdb --quiet --args psql [any psql params here]
(gdb) run
[ do whatever you need to do to make psql crash ]
Program received signal SIGSEGV, Segmentation fault.
0x007ca422 in __kernel_vsyscall ()
(gdb) bt
#0 0x007ca422 in __kernel_vsyscall ()
#1 0x001cddd3 in __read_nocancel () at
../sysdeps/unix/syscall-template.S:82
#2 0x00de68c7 in rl_getc () from /lib/libreadline.so.6
#3 0x00de6ea3 in rl_read_key () from /lib/libreadline.so.6
#4 0x00dd109e in readline_internal_char () from /lib/libreadline.so.6
#5 0x00dd15ed in readline () from /lib/libreadline.so.6
#6 0x00730ff1 in ?? ()
#7 0x00733ebe in ?? ()
#8 0x00737964 in main ()
(gdb)
If you paste all the output after "run", that'd be really handy.
If for some reason you can't start psql under gdb, you can instead run
psql normally and then attach gdb to psql using "gdb -p pidofpsql" . Get
"pidofpsql" using the "ps" command - "ps -ef" or "ps aux" depending, I
don't remember which flavour Mac OS X understands - passed through "|
grep psql".
I have the developer tools installed - but I think only because I needed them
installed to install something ages ago.
Great.
--
Craig Ringer
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
