On Mon, December 5, 2005 16:45, Camille Chafer wrote:
>
> I'm trying to read a set of data from a psql table, then create a new
> object for each row.
> bool loadSpells( pqxx::transaction_base& t ){
> CSpell* pSpell = NULL;
> std::string sqlQuery = "SELECT spell_id FROM tbl_game_spell";
> pqxx::result R = t.exec( sqlQuery );
> for (pqxx::result::const_iterator it = R.begin(); it != R.end(); it++) {
> pSpell = new CSpell(); // memory leak, I know. This pointer
> will be stored somewhere later.
> }
> return true;
> }
Of course anything is possible with bugs, but this looks to me like the
result class is not the most likely suspect--unless it's a problem in the
reference counting code (there has been one once), I would look for a
problem in the SQL execution logic. After all, you're not even accessing
the data in the result--only its number of rows is determined.
So does the problem go away if you loop those 48 times but don't actually
execute the query? Does it go away if you do execute the query but don't
store the result in a variable? Does it go away if you execute this
function once at the very start of your program, but never again?
Next, are you absolutely sure that no exception is being thrown? That's
where things often go wrong: sometimes because unexpected code paths are
executed, sometimes because of incorrect throw specifications, or because
of exception object slicing, and even because of compiler bugs. What kind
of transaction are you actually using, and in which version of libpqxx,
and using what compiler with what optimization options? And if you're
using robusttransaction, then the database backend version is also
relevant.
> When compiling and running this, the loadSpells function executes fine
> and returns true.
> But a few seconds after, I get a Segmentation Fault signal.
> If I don't call this function in my code, everything's fine (I can let
> the software run for hours, without a single problem).
This sounds like memory, probably the heap, is being accidentally
overwritten. When that happens, cause and effect are sometimes very hard
to connect. Small changes may unexpectedly change memory layout in such a
way that the bug happens to become invisible.
In a case like this I would recommend trying tools like Valgrind, Electric
Fence, mudflap etc. to pinpoint the real cause of the problem. Otherwise,
the entire function we're looking at here may be only incidental to how
the bug manifests itself--the real bug may be in another part of the
program altogether.
> At this time, I don't know anymore where to look.
> Can it be a namespace problem ? A heap size problem ? A libpqxx problem ?
Unless you're using a standard C++ library other than the one that came
with your compiler (and with the exact version you're using), it's almost
unthinkable that this is a namespace problem. You'd see those at compile
time, not at runtime. In fact libpqxx is designed to bring out problems
at compile time where feasible. A heap size problem would normally
manifest itself as a bad_alloc exception--but if it isn't being handled
correctly then that's a bug.
Can it be bug in libpqxx? Well, like I said, it's happened once and it
can happen again. Unless Don E. Knuth is involved, no program is perfect.
Best way to find out involves (1) reducing the program to an *absolute
minimum* that will reproduce the problem; (2) running the program against
checker tools that can detect the bug when it happens; and (3) running the
program in a debugger to check for unexpected circumstances such as
out-of-memory errors and unspecified exceptions.
Jeroen
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
