> > (gdb) bt
> #0 0xffffe405 in __kernel_vsyscall ()
> #1 0x555e37a5 in raise () from /lib/tls/libc.so.6
> #2 0x555e5209 in abort () from /lib/tls/libc.so.6
> #3 0x5561771a in __libc_message () from /lib/tls/libc.so.6
> #4 0x5561dfbf in _int_free () from /lib/tls/libc.so.6
> #5 0x5561e33a in free () from /lib/tls/libc.so.6
> #6 0x0805fee5 in safe_free (pointer=0x80cb790) at utility.c:222
> #7 0x08073dd7 in ptrajClearState (stateinp=0xffffcab0) at ptraj.c:1860
> #8 0x0807b55b in ptraj (filenamep=0x0) at ptraj.c:5163
> #9 0x0806a139 in interface (mode=INTERFACE_PTRAJ, filename=0x0) at
> interface.c:86
> #10 0x0804935f in main (argCount=1, argPointer=0xffffd494) at main.c:173
>
>
> I am just curious whether anyone knows what role __kernel_vsyscall()
> plays? It is a subroutine in libc.so and hopefully by knowing it's
> role I can decipher what the error is trying to tell me.
The better clue is the fact that the last user-side call is free() -
probably a bad pointer is being passed to this routine. If you have
access to Purify or a solaris sparc system ('man bcheck') or some other
memory debugger, this might turn up some clues.
Here's more on bcheck:
http://docs.sun.com/source/819-3683/RunTCheck.html#24560
Bill
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Wed Oct 18 2006 - 06:07:21 PDT
