On Jan 26, 2009, at 3:29 PM, Matthew Leotta wrote:
On Jan 26, 2009, at 3:04 PM, Brad King wrote:
Matthew Leotta wrote:
Brad,
Thanks, but I'm not sure if I completely understand your suggestion.
Let me clarify. If I run the test executable
./bvxm_test_all
I get no errors and no segfault. I know how to debug this, but
there is
nothing to debug. If in the same directory I run
ctest
then the test will segfault. Even stranger, on some platforms the
test
passes, but when I run in ctest it fails (produces the wrong
values) but
does not segfault. On some other platforms everything seems to work
both with and without ctest.
I'm actually running only the specific test that fails (the 5th
one) with
./bvxm_test_all test_amp_processors
or
ctest -V -I 5,5
but the results are the same. When I try to debug ctest I never hit
breakpoints in bvxm_test_all because ctest spawns off a separate
process
for bvxm_test_all, and gdb is attached to ctest. I'm not much of an
expert on using gdb from the command line, I usually debug with an
IDE
front end (XCode or KDevelop).
add_test(run_xterm xterm)
$ ctest -R run_xterm
Then run gdb and the test inside the xterm to see if it fails. It
could
be an environment difference.
-Brad
It runs fine from within xterm when xterm is launched as a test by
ctest. I suppose this means that the environment setup by ctest is
not the culprit. Any other suggestions?
Matt
Does the test that fails take a long while to run? I asked because I
have had to attach to a process using gdb on the command line (some
IDE's allow you to do it also) while the test was running.
Basically open a terminal and have 'top' running.
Open another terminal and start up gdb
in the gdb session type "attach" but NOTHING else, not even the
return key.
Now open a third xterm and start the testing with Ctest.
Watch in the first xterm for the pid to appear.
Quickly type the pid into the gdb xterm and hit return. If you did it
fast enough then you are now attached to the actual test.
Dig out your favorite gdb tutorial about stepping, stack traces and
all that and have fun debugging.
http://www.cs.princeton.edu/~benjasik/gdb/gdbtut.html is a short
tutorial.
---
Mike Jackson www.bluequartz.net
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
