Björn Persson wrote:
> might then think the bug is in GCC or some system library in Fedora 4, but no
> other programs are crashing, only these that use MySQL++.
MySQL++ pushes the standard libraries harder, in more places, than most
programs. In particular, "most programs" on Linux systems are C-only,
so they don't stress STL and such at all.
> I'd rather think
> it's some change that has exposed a previously hidden bug.
If the situation is that drastic, I'd think more people would be
reporting this problem. The oldest version you've tried, 1.7.35, is
over three months old, yet you're the first to report this problem.
Seems specious to blame MySQL++ based on such thin evidence.
Is your program multi-threaded?
> Query data_query = con.query();
> Query product_query = con.query();
> Query company_query = con.query();
Since you can't have multiple queries running at the same time on a
single connection, there's never a need to have multiple query objects.
Just keep one generic one, and .reset() it between uses.
> Result data_result;
> Result product_result;
> Result company_result;
Similarly, you might also be able to use just one Result object.
> for(Result::iterator rowp = product_result.begin();
> rowp != product_result.end();
Use ++rowp here. Postincrementing is more efficient; it's a moot point
for primitive types like ints, where the compiler can optimize away the
difference in cases like this, but not in the case of classes.
> And on one of the calls to store(): bang! Is there anything in this code that
> can cause that?
It looks sane to me.
When you get a crash, load up the core file in gdb and get a backtrace.