Debugging Rosetta under XCode

[Anonymous]

Hi all,

I am new in Rosetta. I am planning to add a new empirical force field to rosetta, but I have no idea what is the best cutting point in order to be able to debug it. Here is my question…..
1. What’s the size of the memory typically required for debugging Rosetta under Xcode?

The configuration of my machine:

Processor 2.8 GHz Intel Core 2 Duo
Memory 8 GB 1067 MHz DDR3
Software Mac OS X Lion 10.7.2 (11C74)

I have successfully compiled Rosetta using “-j 2 mode=debug bin –“. The default compiler is GCC 4.2.
However, every time I try to debug FlexPepDock and set a breakpoint somewhere in the code, it takes up almost all memory and goes into a long run. No variables are able to be displayed. Apart from that, if I set the breakpoints off, the calculation seems pretty fast overall.

2. What’s the typical developer’s configuration for debugging rosetta? Do you do code tracing using IDE?

Thanks in advance.

[Anonymous]

I use GDB inside emacs for debugging; this computer originally had 2 GB (now 4GB) of RAM and that was enough to debug. I think 8 GB ought to be plenty.

Different developers use different things. Some use Eclipse, some use emacs, some use Xcode. Nobody in my lab is using Xcode, but we have a vague impression that it doesn’t work out of the box – perhaps there is some library paths that have to be set? I would suggest trying GDB. I’ll forward this along to someone who might be using Xcode, as well.

[Anonymous]

A number of people I’ve spoken with swear by using “printf debugging” with Rosetta (or rather, since it’s C++ it’s more “std::cerr <<" or tracer debugging). I don't know if it's better under Xcode, but I've frequently had problems debugging Rosetta under GDB. There's something about it that confuses the debugger. Often it's just better to litter the code with potentially helpful output statements, and then look at what's being printed when. Frequently there's an operator<< defined for key classes to help with that. As a side benefit, you can do the run in release mode, which speeds things up considerably, especially if your debugging happens late in the run. On the drawback side, you have to recompile each time you add in output statements, which certainly may take a while, although is mitigated somewhat if you’re aggressive about adding output statements the first time around.

[Anonymous]

I have used Xcode to debug rosetta projects in the past. It requires a little setup, but it works pretty well. Your system resources are identical to the MacBook Pro that I have used in the past, so it should work. What version of Xcode are you trying to use and how did you set up the executable to debug?

[Anonymous]

Hi weitzner,

Initially there was a little problem. I successfully compiled rosetta library and apps before I upgraded to Lion using GCC 4.01 and GCC 4.2. I think the IDE version is not an issue but I will check later if I do any modification to the code. The problem was on some functions in the boost library that are not actually used by rosetta but created faults. I then traced the error to the problematic code and commented out the part that’s actually creating the error.

I am brand new to rosetta. Just found out that just to run an FlexPepDocking example is a very tedious trial-and-error procedure. Would be better if there are ways to help improve the code commenting and updating.

I am running Lion with the latest version of XCode 4.2. I have also run the FlexPepDocking example 2b1z under CentOS Linux and got some output. I will see if I can debug flexPepDocking in Xcode 4.2…

[Anonymous]

Here is how I configured rosetta on my linux box:

—-
gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure –prefix=/usr –mandir=/usr/share/man –infodir=/usr/share/info –enable-shared –enable-threads=posix –enable-checking=release –with-system-zlib –enable-__cxa_atexit –disable-libunwind-exceptions –enable-libgcj-multifile –enable-languages=c,c++,objc,obj-c++,java,fortran,ada –enable-java-awt=gtk –disable-dssi –disable-plugin –with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre –with-cpu=generic –host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)

—-
mpicc -v
mpicc for MPICH2 version 1.4.1p1

remember to set LD_LIBRARY_PATH and PATH for these compilers

—-

Modify basic.settings in tools/build

"gcc, mpi" : {
"appends" : {
"include_path" : [ "$YOUR_MPI_DIR/include" ],
"library_path" : [ "$YOUR_MPI_DIR/lib" ],
"defines" : [ "USEMPI" ],
"libraries" : [ "mpl" ],
"flags" : {
"compile" : [ "fPIC", "Wno-long-long" ],
"link" : [ "fPIC", "Wno-long-long" ],
},
},
"overrides" : {
"cc" : "mpicc",
"cxx" : "mpicxx",
},
},

—-
cat /proc/cpuinfo
get how many cores you have on hands~
—-

write the error into a log file while compiling

./scons.py -j 8 mode=release extras=mpi bin — > mpi_comp.log 2>&1 &

this will use 8 cores to compile rosetta

[Anonymous]

I can now debug rosetta using Xcode 4.2.
Compiler clang 3.0
Thanks to you all.

[Anonymous]

Thank you both for the suggestions. I will try Eclipse first.

[Anonymous]

There is definitely some manual library path finessing that has to happen for Eclipse’s debugger, FYI. No, I don’t know how to do it – the Eclipse guy in my lab uses GDB instead.

[Author]

Posts