AMBER Archive (2008)

Subject: Re: AMBER: xleap fails to savemol2

From: taufik.alsarraj_at_utoronto.ca
Date: Wed Oct 08 2008 - 16:57:30 CDT

Thank you Mark and Sasha,
It is taking me a long time to learn using gdb to find out the origin
of the problem. I decided to switch to fedora. The good news is xleap
is working great and savemol2 is working.

Bad news is Sirius is still not working as it should. After some
testing i noticed that i can load both the surface and SMCC and the
program is stable. However is i load SMCCchrg.mol2 the program is
unstable

unstable = i cannot see both molecules (surface and linker) and i
cannot select one of them to move around.

The purpose of using Sirius is to load two different molecules and
create a bond between them and then save them as one file and transfer
that to xleap.

Best,
Taufik

Quoting Mark Williamson <mjw_at_sdsc.edu>:

> 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




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