I moved the looper.c program to the frysk-gui/frysk/gui/test/dogtail_scripts dir
and did a recompile of frysk. I activated the resulting executable and tried to
open a source window on it and get the following backtrace:
This repeats over and over for a hundred or more times.
I first thought maybe it was the different options that looper was compiled
with, but I made a separate test dir. copied looper.c to it and compiled it
with the same options as the frysk build system. I was able to successfully
attach to that executable, so I am not sure what is going on. Here are the
commands I used to compile the test case which I copied from the frysk build system:
gcc -DPACKAGE_NAME=\"frysk\" -DPACKAGE_TARNAME=\"frysk\"
0.0.1.2006.06.28\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"frysk\"
-DVERSION=\"0.0.1.2006.06.28\" -Werror -Wall -fPIC -g -O -MT looper.o -MD -MP
-MF "$depbase.Tpo" -c -o looper.o looper.c
gcc -I. -Werror -Wall -fPIC -g -O -o looper looper.o
This was caused by an unhandled FileNotFoundException in createDOM, which is now
handled and causes a warning dialog to be created.
As for why the source isn't being found, it appears that when the file is built
with the build system the path to the source file is stored as a relative path.
In my own tests I have seen the path to the file stored as an absolute path,
which is the preferred method. I'm not sure what in the frysk build system
caused the relative path to be set.