AMBER Archive (2006)

Subject: Re: AMBER: General Coding Problem

From: David A. Case (
Date: Mon Oct 16 2006 - 19:27:56 CDT

On Mon, Oct 16, 2006, Elijah Gregory wrote:
> Program received signal SIGABRT, Aborted.
> 0xffffe405 in __kernel_vsyscall ()
> (gdb) bt
> #0 0xffffe405 in __kernel_vsyscall ()
> #1 0x555e37a5 in raise () from /lib/tls/
> #2 0x555e5209 in abort () from /lib/tls/
> #3 0x5561771a in __libc_message () from /lib/tls/
> #4 0x5561dfbf in _int_free () from /lib/tls/
> #5 0x5561e33a in free () from /lib/tls/
> #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

Looks offhand like you are trying to free a pointer that was never allocated,
or has already been freed somewhere else. What does line 222 of utility.c
indicate? (I'm not sure if you've modified the code, and/or exactly which
version you have, so I can't check myself.) If things are simple, that line
will be calling safe_free() in some bad way. [Note that safe_free() is
a fair misnomer: it's not necessarily "safe" in any usual sense...]

(Items #0 to #5 in the above list are deep in system-land, and are unlikely
to be very helpful. Item #6 and below can show where the program was in your
code when it decided to go south.)

...good luck...dac

The AMBER Mail Reflector
To post, send mail to
To unsubscribe, send "unsubscribe amber" to