AMBER Archive (2008)

Subject: Re: AMBER: xleap fails to savemol2

From: FyD (fyd_at_q4md-forcefieldtools.org)
Date: Tue Oct 14 2008 - 14:15:48 CDT

Dear Mark Williamson, dear Taufik Alsarraj,

First thanks a lot to Mark Williamson for all the information he has
provided about the "*** stack smashing detected ***" problem related
to the "savemol2" command in LEaP under Ubuntu 32 bit 8.04. This help
us a lot... For Ubuntu 8.04 32 bits a patch should be available soon
from the AMBER web site @ http://ambermd.org/bugfixesat.html

We have updated our web site @
http://q4md-forcefieldtools.org/Tutorial/Tutorial-1.php
     &
http://q4md-forcefieldtools.org/Tutorial/leap.php

A patch is available for the tleap version available from Antechamber,
but also for xleap/tleap versions of AMBER8 & AMBER9. See
http://q4md-forcefieldtools.org/Tutorial/leap.php
     &
http://q4md-forcefieldtools.org/Tutorial/patch.txt

This patch can also be used with the Ambertools 1.x.

It seems that only Ubuntu (8.04) - 32 bit get the "*** stack smashing
detected ***" problem related to the savemol2 command in LEaP.
However, this is safer all the users of LEaP interested in the
savemol2 command apply this patch.

Thanks to C. Cezard who has written this patch.

regards, Francois

>> 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