Warren Young wrote:
> Björn Persson wrote:
> > One
> > 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.
Well, QT is C++ so I would think most KDE programs are in C++, but I suppose
it's possible that MySQL++ uses something unusual.
> Is your program multi-threaded?
No. It's a set of fairly simple CGI programs. They do a few queries and then
terminate. (So they don't have a lot of time to corrupt the memory either.)
> 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.
>
> Similarly, you might also be able to use just one Result object.
I had problems earlier that seemed to be caused by dangling pointers, and the
documentation wasn't very clear on which methods return copies of data and
which return pointers, so I decided to play it safe and keep everything
around until I'm done. That worked fine until now.
So a Result object has no pointers into the Query object then? But I have to
keep the Result until I'm done with all Row and ColData objects, don't I?
> When you get a crash, load up the core file in gdb and get a backtrace.
Okay, I've got a few. It appears that it crashes on the assignment to the
Result object and not in store() itself. Investigating further, I've also
discovered that it sometimes crashes in other places too.
The first two are from crashes on "result = query.store();":
#0 0x004c4da6 in __gnu_cxx::__mt_alloc<mysqlpp::mysql_type_info,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate
(this=0x9c4c660, __n=2)
at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ext/mt_allocator.h:719
#1 0x004c9626 in mysqlpp::ResUse::copy (this=0xbfc2ad50, other=@0xbfc2ae28)
at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_vector.h:117
#2 0x0804efc0 in mysqlpp::ResUse::operator= (this=0xbfc2ad50,
other=@0xbfc2ae28) at /usr/local/include/mysql++/result.h:619
#3 0x0804effc in mysqlpp::Result::operator= (this=0xbfc2ad4c)
at /usr/local/include/mysql++/result.h:348
#4 0x0804db3e in edit_contact (con=@0xbfc2af08, CGI_object=@0xbfc2b130,
user=@0xbfc2b1c0) at edit_contact.cpp:46
#5 0x080594ff in wrap (worker=0x804d4ba <edit_contact(mysqlpp::Connection&,
cgicc::Cgicc&, user_data const&)>, want_to_add_data=false,
want_to_edit_companies=false, want_to_be_admin=false) at common.cpp:425
#6 0x0804d212 in main (argc=1, argv=0xbfc2b2d4) at edit_contact.cpp:73
#0 0x00f56da6 in __gnu_cxx::__mt_alloc<mysqlpp::mysql_type_info,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate
(this=0x9338318, __n=2)
at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ext/mt_allocator.h:719
#1 0x00f5b626 in mysqlpp::ResUse::copy (this=0xbfd41308, other=@0xbfd41334)
at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_vector.h:117
#2 0x080550c0 in mysqlpp::ResUse::operator= (this=0xbfd41308,
other=@0xbfd41334) at /usr/local/include/mysql++/result.h:619
#3 0x080550fc in mysqlpp::Result::operator= (this=0xbfd41304)
at /usr/local/include/mysql++/result.h:348
#4 0x0806704c in fetch_list (con=@0xbfd423d8, table=@0xbfd41f04,
list=@0xbfd41c3c, sorting_key=@0xbfd41efc, condition=@0xbfd41ef8) at
forms.cpp:20
#5 0x0804f4f8 in enter_event (con=@0xbfd423d8, CGI_object=@0xbfd42600,
user=@0xbfd42690) at enter_event.cpp:208
#6 0x0805fc03 in wrap (worker=0x804dc4a <enter_event(mysqlpp::Connection&,
cgicc::Cgicc&, user_data const&)>, want_to_add_data=false,
want_to_edit_companies=false, want_to_be_admin=false) at common.cpp:425
#7 0x0804d28c in main (argc=1, argv=0xbfd427a4) at enter_event.cpp:332
Here's one that seems to crash while copying a vector of strings, when I take
the first (and only) row from a result set with the statement "tender_data =
tender_result[0];":
#0 0x0804fc40 in __gnu_cxx::__mt_alloc<std::string,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate
(this=0xbf8ce54c, __n=15)
at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ext/mt_allocator.h:719
#1 0x0804fcad in std::_Vector_base<std::string, std::allocator<std::string>
>::_M_allocate (this=0xbf8ce54c, __n=15)
at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_vector.h:117
#2 0x08051e8c in std::vector<std::string, std::allocator<std::string>
>::_M_allocate_and_copy<__gnu_cxx::__normal_iterator<std::string const*,
std::vector<std::string, std::allocator<std::string> > > >
(this=0xbf8ce54c,
__n=15, __first={_M_current = 0x8d966a0}, __last={_M_current = 0x8d966dc})
at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_vector.h:763
#3 0x08051fb8 in std::vector<std::string, std::allocator<std::string>
>::operator= (this=0xbf8ce54c, __x=@0xbf8ce624)
at /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/vector.tcc:141
#4 0x0805232a in mysqlpp::Row::operator= (this=0xbf8ce544)
at /usr/local/include/mysql++/row.h:484
#5 0x0804d51f in show_tender (con=@0xbf8ce778, CGI_object=@0xbf8ce9a0,
user=@0xbf8cea30) at show_tender.cpp:39
#6 0x0805881f in wrap (worker=0x804d154 <show_tender(mysqlpp::Connection&,
cgicc::Cgicc&, user_data const&)>, want_to_add_data=false,
want_to_edit_companies=false, want_to_be_admin=false) at common.cpp:425
#7 0x0804d14a in main (argc=1, argv=0xbf8ceb44) at show_tender.cpp:71
And this one makes it past the point that stack trace number two above came
from, but crashes a moment later while extracting a field from a row with
"(*rowp)[1]":
#0 0x0805106c in __gnu_cxx::__mt_alloc<std::string,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate
(this=0xbffba8d8, __n=2)
at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ext/mt_allocator.h:719
#1 0x080510d9 in std::_Vector_base<std::string, std::allocator<std::string>
>::_M_allocate (this=0xbffba8d8, __n=2)
at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_vector.h:117
#2 0x08053bba in std::vector<std::string, std::allocator<std::string>
>::_M_insert_aux (this=0xbffba8d8, __position={_M_current = 0x88ba31c},
__x=@0xbffba638)
at /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/vector.tcc:275
#3 0x08053f77 in std::vector<std::string, std::allocator<std::string>
>::insert (this=0xbffba8d8, __position={_M_current = 0x88ba31c},
__x=@0xbffba638)
at /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/vector.tcc:103
#4 0x0805427f in Row (this=0xbffba8d0, d=0x88be7a0, r=0xbffba858,
jj=0x88bd640, te=false) at /usr/local/include/mysql++/row.h:520
#5 0x080546a5 in mysqlpp::Result::fetch_row (this=0xbffba854)
at /usr/local/include/mysql++/result.h:399
#6 0x080546d8 in mysqlpp::Result::operator[] (this=0xbffba854, i=0)
at /usr/local/include/mysql++/result.h:431
#7 0x0804f9f2 in
mysqlpp::subscript_iterator<mysqlpp::const_subscript_container<mysqlpp::Result,
mysqlpp::Row, mysqlpp::Row const, unsigned int, int> const, mysqlpp::Row
const, unsigned int, int>::operator* (this=0xbffba878)
at /usr/local/include/mysql++/resiter.h:186
#8 0x0806124c in fetch_list (con=@0xbffbaee8, table=@0xbffba9e4,
list=@0xbffbad14, sorting_key=@0xbffba9dc, condition=@0xbffba9d4) at
forms.cpp:23
#9 0x080622b5 in fetch_menus_for_company (con=@0xbffbaee8,
trades=@0xbffbad2c, turnover_ranges=@0xbffbad24,
employees_ranges=@0xbffbad1c, contact_data_types=@0xbffbad14) at
company_menus.cpp:14
#10 0x0804d70c in edit_company (con=@0xbffbaee8, CGI_object=@0xbffbb110,
user=@0xbffbb1a0) at edit_company.cpp:41
#11 0x08059d3b in wrap (worker=0x804d4ba <edit_company(mysqlpp::Connection&,
cgicc::Cgicc&, user_data const&)>, want_to_add_data=false,
want_to_edit_companies=false, want_to_be_admin=false) at common.cpp:425
#12 0x0804d212 in main (argc=1, argv=0xbffbb2b4) at edit_company.cpp:92
Björn Persson
