BrainVISA

The following code produces Segmentation Fault

PythonHeader* test = new PythonHeader();
test->writeMinf( "test.minf" );

with sources of aimsdata updated and compiled from perforce on 04/07/2006


Has PythonHeader been replaced by something else ?

JD

Hi,
No PythonHeader hasn't been removed.
It looks like a bug...
I will check.
Denis

I have just made a test program and it doesn't crash for me.
Are you sure you don't have any linker or library problem, and that you have write permission on the output directory ?

Yo !

I guess you tried the same test as I did ?

i tried again and again with intermediate versions but it crashed

I have writing permissions

Wouldn't I need extra DEFINES for compilation of the test program ( like NEWAIMSDATA ) or stuff like that ?

Do you use build-config for compilation ?
If no, can you post your Makefile (with your command source if it is not too long) ?

My code is

#include <aims/data/pheader.h>
using namespace aims;

int main()
{
PythonHeader* test = new PythonHeader();
test->writeMinf( "test.minf" );

return 1;
}





I am using the following lines for compilation of test.o :


g++ -c -Wall -W -D_REENTRANT -fPIC -DCARTO_DEBUGMODE=\"default\" -DAIMS -DAIMS -DQT_CLEAN_NAMESPACE -DQT_THREAD_SUPPORT -DHAS_GLEXT -I/pclxserver/data/users/schwartz/perforce/aimsdata-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/graph-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/cartobase-main-linux-default/include -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/sigc++-2.0 -I/usr/include/libxml2 -I/pclxserver/data/users/schwartz/perforce/cartodata-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/ecat+-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/ecat-main-linux-default/include -I/pclxserver/data/users/schwartz/perforce/vidaIO-main-linux-default/include -o test.o test.cpp




and for linking :

g++ -o test test.o -L/pclxserver/data/users/schwartz/perforce/aimsdata-main-linux-default/lib -L/pclxserver/data/users/schwartz/perforce/cartobase-main-linux-default/lib -L/pclxserver/data/users/schwartz/perforce/cartodata-main-linux-default/lib -L/pclxserver/data/users/schwartz/perforce/graph-main-linux-default/lib -laimsdata -lcartobase -lcartodata -lgraph





and ./test produces a Segmentation Fault

This code executes well:


int main()
{
PythonHeader* test = new PythonHeader();
return 1;
}


but this one causes Segmentation Fault :

int main()
{
PythonHeader* test = new PythonHeader();
test->setProperty( "toto", "tata" );
return 1;
}

Do you think the problem could come from the fact that aims library and the test program are not compiled on the same machine ?

Would it be a problem for functions such as dynamic_cast ( the same object has different representation, depending on compilation machine or compilation options ) ?

Is it possible that the PythonHeader object I create in my program is not "recognized" by aims library and causes an error in dyncamic_cast ?

If it is not on the same machine but the two systems are the same, it is ok. But if the sytems differ, it can lead to problems according to gcc and libstdc++ versions. For example, in Orsay we slowly passed from Fedora Core 2 to Fedora Core 4. It was not possible to make one compilation distributed on the two systems. During the transition, we had to compile only on one system.

I am not sure about compilation options. It should not be a problem as long as you use the same -D options because of #if / #endif that may compile different code.

There is no dynamic_cast in your program, the problem is in the library or in the way is is compiled or linked.

And what are -D options I need ?

The -D options seem OK to me (compared to what I have using build-config), except that you have -DAIMS twice, but this is not a problem.
I would rather suspect a system compiler/libaries incompatibility if you have compiled on two different machines, as Yann suggested.
You can check some basic problems using ldd:
ldd test
if you see several libstdc++ (with different version numbers), don't look further: that's the problem.
Denis