Berteun Damman <berteun@gmail.com> writes:
> On Sat, 15 Jan 2005 13:15:36 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Would you attach to the process with a debugger and get a stack trace?
> I think it has a locking problem:
> #0 0x483bbb2e in pthread__lock_ras_end () from /usr/lib/libpthread.so.0
> Error accessing memory address 0x483bbb26: Operation not permitted.
> And the other time:
> #0 0x483bbb31 in pthread__lock_ras_end () from /usr/lib/libpthread.so.0
> And again an accessing error.
> Does this indicate an error in NetBSD's pthreading library?
Not necessarily --- it just means that gdb is confused and can't find
the stacked return addresses :-(. One thing to check is whether you
have the most up-to-date available version of gdb. Also, I'd suggest
trying it a dozen or two times in hopes of catching it when it's not
inside libpthread.
Another trick I've sometimes had success with is to kill the process in
such a way that it produces a core dump (kill -ABRT should do this),
and then gdb the core dump file instead of the live process. gdb seems
to handle that a bit differently and sometimes you can get a stack trace
one way when you couldn't get it the other way.
If none of that works, I'd suggest asking for help from the NetBSD
hackers; they may know some special way of finding out the call stack.
But we aren't going to be able to get far if we can't figure out what
it's doing.
regards, tom lane
