Problem with compiler options ?
Hello, I, trying to use some phoenix functions inside of a big project. The problem is that, although everything runs well in my test cases, when I integrate the very same code inside of the huge project, it always fails in a segfault. Let's explain it further : I have a code in main(), directly, both for test case and program, which is the same : int main(int argc, char *argv[]) { State my_state; my_state.setPosition(new Point(1250,8907)); my_state.setName(new string("myname")); setRobotState(&my_state); if(areamanager(localhost, 888) == false) cerr << "Could not Connect to server." << endl; while(true) {}; return 0; } ... quite simple. It is not interesting, but at some point inside of the parsing, I call (within a grammar) the following line : [...] confix_p( str_p(Message::nameMark.c_str()) >> ch_p('='), strval[phoenix::bind(&Message::setName)(self.variable1,phoenix::new_std::string(arg1, arg2))], ch_p(';')) [...] Where str_p is a very simple parser for strings, nameMark is a string marker for the parsing, and I'm supposed to call the member function variable1::setName(new string(arg1,arg2)) ... this is basically what phoenix does. And it works, my function is called. But in only one case... First one : (on the same computer, Linux mpc182 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 i386 GNU/Linux ) g++ main.o -L./ -lboost_system-mt -lboost_thread-mt -lareacommunication -o demo : This works well, no segfault during parsing, member function is called. Second one: gcc -g -O3 main.o -odemo_main -lfacetracker `xml2-config --libs` `Magick-config --ldflags` `Magick-config --libs` -lmpisearch -L/usr/lib/mysql/ -lboost_system-mt -lboost_thread-mt -lareacommunication -lpthread -lstdc++ What should make it segfault ? I tried changing back gcc to g++, then remove the -O3 flag, the -g flag, the -lstdc++... I really don't know where is the problem. Any idea ? -- Victor
On Tue, Aug 25, 2009 at 2:49 AM, Victor Perron
Hello,
I, trying to use some phoenix functions inside of a big project.
The problem is that, although everything runs well in my test cases, when I integrate the very same code inside of the huge project, it always fails in a segfault.
Let's explain it further :
I have a code in main(), directly, both for test case and program, which is the same :
int main(int argc, char *argv[]) {
State my_state;
my_state.setPosition(new Point(1250,8907)); my_state.setName(new string("myname"));
setRobotState(&my_state);
if(areamanager(localhost, 888) == false) cerr << "Could not Connect to server." << endl;
while(true) {};
return 0; }
... quite simple. It is not interesting, but at some point inside of the parsing, I call (within a grammar) the following line :
[...] confix_p( str_p(Message::nameMark.c_str()) >> ch_p('='),
strval[phoenix::bind(&Message::setName)(self.variable1,phoenix::new_std::string(arg1, arg2))], ch_p(';')) [...]
Where str_p is a very simple parser for strings, nameMark is a string marker for the parsing, and I'm supposed to call the member function variable1::setName(new string(arg1,arg2))
... this is basically what phoenix does. And it works, my function is called. But in only one case...
First one : (on the same computer, Linux mpc182 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 i386 GNU/Linux ) g++ main.o -L./ -lboost_system-mt -lboost_thread-mt -lareacommunication -o demo : This works well, no segfault during parsing, member function is called.
Second one: gcc -g -O3 main.o -odemo_main -lfacetracker `xml2-config --libs` `Magick-config --ldflags` `Magick-config --libs` -lmpisearch -L/usr/lib/mysql/ -lboost_system-mt -lboost_thread-mt -lareacommunication -lpthread -lstdc++
What should make it segfault ? I tried changing back gcc to g++, then remove the -O3 flag, the -g flag, the -lstdc++... I really don't know where is the problem.
Any idea ?
Two things that would help. First, a minimized complete reproduction of the problem. Two, stop using Spirit.Classic, use Spirit.Qi in the Boost trunk (you can use it on top of Boost 1.38 or higher as I recall), it has a lot of bug fixed, is faster (both in execution and compile time), easier to use, and just all around more expected in its operation. Also, is your namemark already set and ready to use an grammar creation time? If not then that is the problem, and it is simple enough here to fix if not, but it is a *lot* easier to fix if using Spirit2.1 from the trunk.
participants (2)
-
OvermindDL1 -
Victor Perron