AMBER Archive (2008)

Subject: Re: AMBER: xleap fails to savemol2

From: Mark Williamson (mjw_at_sdsc.edu)
Date: Mon Sep 22 2008 - 13:43:35 CDT

alsarraj wrote:
> Hi,
> I tried again -the two lines of loading and saving mol2, i am using
> Intel(R) Pentium(R) 4 CPU 3.00GHz, Ubuntu 8.04
>
> xleap crashes and the out put is below. i think i have to type 'sudo ln
> -s /usr/lib/libXt.so.6 /usr/lib/libXt.so' i hope i am close solving this
> problem
>
> taufik_at_taufik-desktop:~/Desktop$ -I: Adding
> /usr/local/Programs/amber10.08/dat/leap/prep to search path.
> -I: Adding /usr/local/Programs/amber10.08/dat/leap/lib to search path.
> -I: Adding /usr/local/Programs/amber10.08/dat/leap/parm to search path.
> -I: Adding /usr/local/Programs/amber10.08/dat/leap/cmd to search path.
> *** stack smashing detected ***:
> /usr/local/Programs/amber10.08/bin/xaLeap terminated
> ======= Backtrace: =========
> /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7ccd138]
> /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7ccd0f0]
> /usr/local/Programs/amber10.08/bin/xaLeap[0x8058c4a]
> /usr/local/Programs/amber10.08/bin/xaLeap[0x80adafd]
> /usr/local/Programs/amber10.08/bin/xaLeap[0x80adc70]

This looks very similar to the nature of the problem found in the second
part of this thread:

http://archive.ambermd.org/200806/0224.html

Basically, it is likely that something within xleap that is overwriting
an array boundary, and that your inputs are triggering this. Bugs like
this may not always cause any noticeable problems, hence the program
will appear to function as normal, however, Ubuntu has a version of gcc
with Stack Smashing Protection (SSP) enabled, which will detect issues
like this. Some basic information can be found at:

http://en.wikipedia.org/wiki/Stack-smashing_protection#GCC_Stack-Smashing_Protector_.28ProPolice.29

I have followed what you did in your email of 28th of August, but I
cannot reproduce the crash; I tried this on Ubuntu 8.04 which is the
same as yours, but I am running the x86_64 version, not the i386.

Seeing that I cannot reproduce it here, you will need to do some more
exploring; you have a few options:

i) Turn off SSP.
  There is a gcc flag ( -no-fstack-protector ) that you can pass when
compiling xleap. You will need to recompile xleap with this flag. This
may be the easiest route and you can follow the next section's guide to
editing the the config.h file and use -no-fstack-protector instead of
-g. On the down side, this route may mask an underlying issue that may
come back and bite you in a strange way later on. I've not tried this
and your mileage may vary.

ii) Locate the actual bug and fix it.
  This is perhaps a little advanced and you will need to be familiar
with C and the debugging tool, gdb. You will need to recompile
AmberTools in a slightly different way to enable debugging with gdb:

1) Run configure:
  cd $AMBERHOME/src
  ./configure_at -nobintraj gcc

2) Ensure that the build dir is clean
  make -f Makefile_at clean

3) Edit config.h and make the following changes to the listed variables
below. The "-g" flag adds debugging symbols to the compiled code and the
optimisation flag, "-O3", must be reduced down to "-O0" since without
this, the program will execute in a non-linear manner with respect to
the source code.

CC=gcc -g
CXX=g++ -g
CPLUSPLUS=g++ -g
CFLAGS= -m64 $(AMBERBUILDFLAGS)
OCFLAGS=-O0 -m64 $(AMBERBUILDFLAGS)
NABFLAGS=
LDFLAGS=

4) Compile it
  make -f Makefile_at

5) Install gdb
  sudo apt-get install gdb

6) Prepare gdb to run with xleap. This assumes that you're using ff99SB
and you have a list of commands within leap.bat that triggers the crash.
The line beginning with "set args" is actually executed within gdb itself.

  export XENVIRONMENT=$AMBERHOME/dat/XaLeap_wcl
  gdb $AMBERHOME/exe/xaLeap

  set args -I $AMBERHOME/dat/leap/prep \
        -I $AMBERHOME/dat/leap/lib \
        -I $AMBERHOME/dat/leap/parm \
        -I $AMBERHOME/dat/leap/cmd \
        -f $AMBERHOME/dat/leap/cmd/leaprc.ff99SB \
        -f leap.bat

7) Run the executable,
  run

8) It should crash and then use the backtrace (bt) command to follow
back the list of functions called that led to the crash.
  bt

9) Now that you know which function it crashed in, you can set a
breakpoint at that function and re-run the process. gdb will stop at
this function and you will be able to step the execution of the code
line by line until the crash happens. This will give more clues as to
the cause of the problem. One place you may find more information about
how gdb works is at:
http://www.cs.princeton.edu/~benjasik/gdb/gdbtut.html

regards,

Mark
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
      to majordomo_at_scripps.edu