All,

I have seen a couple of threads on this in email archive, but so far I did
not find the exact answer. I think in couple of cases it was build
configuration, etc. It could be the same here, but I can't figure it out. So
here it goes.

Linux RH ES3
Mysql++ 1.7.32
Mysql Server mysql Ver 14.7 Distrib 4.1.10a, for pc-linux-gnu (i686)
Mysql Client 3.23.58. Could this be a problem? is that too old?

Samples are compiling and working fine. However my application does not. I
was working on ConnectionPooling for mysql++. It looks like the connection
are being connected to the db. As soon as I tried to execute a query (any
query i.e show tables, show table status, select * from table) and store it
in a result set, I get a core dump.

Back trace looks like this:

#0 0xb73abaaa in _int_malloc () from /lib/tls/libc.so.6
#1 0xb73aadfd in malloc () from /lib/tls/libc.so.6
#2 0xb75943fe in my_malloc () from /usr/lib/mysql/libmysqlclient_r.so.10
#3 0xb7592915 in my_net_init () from /usr/lib/mysql/libmysqlclient_r.so.10
#4 0xb7590228 in mysql_real_connect () from
/usr/lib/mysql/libmysqlclient_r.so.10
#5 0xb7590d55 in mysql_real_connect () from
/usr/lib/mysql/libmysqlclient_r.so.10
#6 0xb758f148 in simple_command () from
/usr/lib/mysql/libmysqlclient_r.so.10
#7 0xb7591450 in mysql_real_query () from
/usr/lib/mysql/libmysqlclient_r.so.10
#8 0xb75911e5 in mysql_query () from /usr/lib/mysql/libmysqlclient_r.so.10
#9 0xb7568586 in mysqlpp::Connection::store(std::string const&, bool)
(this=0xbfffc6c8, str=@0xbfffc280, throw_excptns=false)
at basic_string.h:781
#10 0xb756f816 in mysqlpp::Query::store(mysqlpp::SQLQueryParms&) (this=0x0,
p=@0xbfffc50c) at connection.h:142
#11 0x0804c208 in DnisCacheMgr::cacheData(mysqlpp::Connection*)
(this=0x8053300, con=0xbfffc6c8) at query.h:90
#12 0x08050159 in void CacheManager::bla<DnisCacheMgr>(DnisCacheMgr*)
(this=0xbfffc680, mgr=0x806bfd8) at CacheManager.h:48
#13 0x0804facf in main (argc=1, argv=0xbfffc964) at CacheManager.h:34

Ldd of my executable is

[root@voip examples]# ldd ConnectionPool
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb75cc000)
libz.so.1 => /usr/lib/libz.so.1 (0xb75be000)
libmysqlclient_r.so.10 => /usr/lib/mysql/libmysqlclient_r.so.10
(0xb7586000)
libmysqlpp.so.4 => ../lib/.libs/libmysqlpp.so.4 (0xb7551000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb749e000)
libm.so.6 => /lib/tls/libm.so.6 (0xb747c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7472000)
libc.so.6 => /lib/tls/libc.so.6 (0xb733b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb730e000)
libnsl.so.1 => /lib/libnsl.so.1 (0xb72f9000)
libmysqlclient.so.10 => /usr/lib/mysql/libmysqlclient.so.10
(0xb72c2000)

ldd of resetdb is

[root@voip examples]# ldd .libs/resetdb
libmysqlpp.so.4 => ../lib/.libs/libmysqlpp.so.4 (0xb75b5000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7599000)
libmysqlclient.so.10 => /usr/lib/mysql/libmysqlclient.so.10
(0xb7562000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb74af000)
libm.so.6 => /lib/tls/libm.so.6 (0xb748d000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7484000)
libc.so.6 => /lib/tls/libc.so.6 (0xb734c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb731f000)
libnsl.so.1 => /lib/libnsl.so.1 (0xb730a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)

Any Clues???? BTW, I turned off all exception handling when creating
connection.

Alex



--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris,

Thanks for a reply. I am not quite sure why "this" is showing as 0x0 in the
backtrace below. Query::store is being defined by this complicated macro
inside the query.h (query_define1 - I believe). In any case, in my example I
print the address of query object being constructed and connection object
reference inside query object and both are valid. Also, I don't believe that
if connection object is invalid or query object would be invalid, I would
get to the next step in the backtrace Connection::store which is being
displayed properly in the backtrace. Below are the debugs from my programs:

[root@voip examples]# ./ConnectionPool
connected success
connection object connected
Connection to debit success on connect 1
connected success
connection object connected
Connection to debit success on connect 2
connected success
connection object connected
Connection to debit success on connect 3
connected success
connection object connected
Connection to debit success on connect 4
connected success
connection object connected
Connection to debit success on connect 5
connected success
connection object connected
Connection to debit success on connect 6
connected success
connection object connected
Connection to debit success on connect 7
connected success
connection object connected
Connection to debit success on connect 8
connected success
connection object connected
Connection to debit success on connect 9
connected success
connection object connected
Connection to debit success on connect 10
Size of Connections 10
// all 10 pooled connection are now constructed and appended to a vector
Size of Connections 10
getConnection: got connected
Got Connected Pooled Connection
Connection from Pool 0xbfffe848 // Print the address of Connection of the
pool
db connected // check if connection object is connected()
MySQL version: 3.23.58 // connection->client_info() result
Connection 0xbfffe848 // debug line I inserted into Query
constructor to display Conection Address. It is the same as I extracted from
the pool
query object 0xbfffe600 // query object address as resulted from
con->query();
Query: show tables // query->preview() results after query <<
"show tables";
query object 0xbfffe600 // address of query right before store();
Segmentation fault (core dumped)

The program still core dumps in the same place.

-----Original Message-----
From: Chris Frey [mailto:cdfrey (AT) netdirect (DOT) ca]
Sent: Saturday, April 23, 2005 4:16 PM
To: plusplus (AT) lists (DOT) mysql.com
Subject: Re: Core dump with query->store()

On Fri, Apr 22, 2005 at 07:12:54PM -0400, Alex Vishnev wrote:
You might want to look here first. The 'this' pointer shouldn't be 0.
Perhaps your cache has a bug.


- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?unsu...line (DOT) net




--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Sun, Apr 24, 2005 at 11:54:34AM -0400, Alex Vishnev wrote:
Interesting... hard to say without seeing the code though. All I can
suggest is to step as deep as you can with the debugger and check variables
as you go.

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Alex Vishnev wrote:

Have you run valgrind or some other memory usage debugger on your program?

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw