AMBER Archive (2006)

Subject: Re: AMBER: General Coding Problem

From: Bill Ross (ross_at_cgl.ucsf.edu)
Date: Mon Oct 16 2006 - 19:56:37 CDT

> > (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_at_scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo_at_scripps.edu