Quoting taufik.alsarraj.utoronto.ca:
> 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.
Yes, thanks a lot to Mark Williamson for all the information he has
provided...
We are working on solving this problem... However, we do not have
Ubuntu installed...
I just hope this a problem in the "savemol2" command we have
introduced, and not a more general problem.
best regards, Francois
> Quoting Mark Williamson <mjw.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.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.scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
to majordomo.scripps.edu
Received on Sun Oct 12 2008 - 05:08:35 PDT
