[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

strange problem

From: Antonio Coralles
Subject: strange problem
Date: Mon, 24 Jan 2005 02:47:35 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041223)

I'm writing on a program [C++] for about six month. Recently I tried to switch from my hand coded makefiles to autoconf/automake. I removed all my makefiles, replaced them with the according's and managed to build my program with ./configure; make after two days. So far, so good. Now the problem is, that the resulting executable contains lot's of bugs - bugs which didn't occur with my hand crafted make files. I tried to track them down for the last two days, without succes. To make that clear: I've made no modifications to my source code - I only changed the way my code gets compiled and linked.

Additionally, I've written tests for all nontrivial core-components of my programm. This tests work without problems - even when compiled with with the GNU-autotools. In particular I've a test for the internals responsible for loading/saving - and this test works. But when I try to load a file from the main program [this works well when built with my hand written makefiles] i get a strange segfault [gdb output]:

#0  0x409d13bb in mallopt () from /lib/
#1  0x409d0521 in malloc () from /lib/
#2 0x4091afaf in operator new(unsigned) () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/ #3 0x08250b89 in rule<boost::spirit::sequence<boost::spirit::action<boost::spirit::rule<boost::spirit::nil_t, boost::spirit::nil_t, boost::spirit::nil_t>, ruleParser::durToArgFunctor>, boost::spirit::kleene_star<boost::spirit::sequence<boost::spirit::sequence<boost::spirit::sequence<boost::spirit::kleene_star<boost::spirit::space_parser>, boost::spirit::chlit<char> >, boost::spirit::kleene_star<boost::spirit::space_parser> >, boost::spirit::action<boost::spirit::rule<boost::spirit::nil_t, boost::spirit::nil_t, boost::spirit::nil_t>, ruleParser::durToArgFunctor> > > > > (this=0xbfffcbb0, address@hidden)
   at rule.hpp:130
#4  0x0824c93c in ruleParser::parse(char const*) const (this=0xbfffccb0,
   str=0x8321fcc "10000: 47:00:00;\n20000: 14:00:00;\n") at
#5 0x082349c0 in dataStorage::loadTreaties(sqlite*, unsigned) (db=0x83238b8, context=0) at #6 0x0822fb4e in dataStorage::loadFileIntoContext(char const*, unsigned) (fileName=0x8321d14 "source.dpm", context=0)
#7  0x0818f600 in main (argc=2, argv=0xbffff204) at

"#4" is the last point in my source. At parsers.cc273 you find:
const rule<> timeDurationList = timeDuration[durFunc] >>
*space_p >> ch_p(',') >> <-------------..... *space_p >> timeDuration[durFunc] <-------------272 ); <------------ 273

which is part of a boost::spirit grammar specification. This statemant doesn't contain the dereferencing of a pointer explicitly [* is just overloaded in this context] or implicitly [durFunc is a simple functor - timeDuration a rule for parsing time durations]. Because my code works with my old makefiles and because of the fact that this SIGSEGV apears without any connection, my assumtion is that there is something wrong in the way my program gets built. Maybe i should mention the libraries I use (appart from the C++ standard library):
1.) boost::smart_ptr
4.)gtkmm-2.4.8 [I use PKG_CHECK_MODULES(...) in my, `pkg-config gtkmm-2.4 ....` in my old makefiles]

Now, one may ask if there is any significant difference between the building process with automake and the one with my old makefiles. Well, the only differenece I see [so far] is that with automake [i use the AC_PROG_RANLIB macro in my] for every subdirectory of my source, all the *.o files are merged into one static *.a archife file which is then used for linking, while my handwritten makefiles use the *.o files directly [for every *.cc one *.o].

As a user of gentoo-linux all the applications I'm using on my computer are built on this computer - so the change that there is something wrong with my environement is fairly low. By the way I'm using gcc-3.3.5, autoconf-2.59 automake-1.8.5 and make-3.80.

Maybe someone can give me a hint - or a location where this question is more likley to get a sensible answer. If somebody want's to have the full source tree just ask - the only reason the program is not yet published under the GPL is that I want to fix my automake problems first ....


reply via email to

[Prev in Thread] Current Thread [Next in Thread]