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/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
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 amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Wed Oct 18 2006 - 06:07:21 PDT
