|
From: Andy G. <and...@co...> - 2009-06-10 22:32:09
|
Hi,
I have been using valgrind for the last couple of months and have
found it easy to track down issues reported buy valgrind (memcheck)
until hitting a new issue where valgrind is providing the following
stack trace:
==12240== Invalid read of size 8
==12240== at 0x1AF0F794: ???
==12240== by 0x168A0224:
DbsMySQLShardedConnection::mysql_fetch_lengths(st_mysql_res*)
(DbsMySQLShardedConnection.cpp:425)
==12240== by 0x16888FB0: mysql_fetch_lengths (DbsMySQLDriver.cpp:575)
==12240== by 0x177B6956: pdo_mysql_stmt_fetch (mysql_statement.c:425)
==12240== by 0x175A6A02: do_fetch_common (pdo_stmt.c:669)
==12240== by 0x175A6BEE: do_fetch (pdo_stmt.c:904)
==12240== by 0x175A876C: zim_PDOStatement_fetch (pdo_stmt.c:1361)
==12240== by 0xF496DB1: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==12240== by 0xF486BAB: execute (zend_vm_execute.h:92)
==12240== by 0xF496853: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==12240== by 0xF486BAB: execute (zend_vm_execute.h:92)
==12240== by 0xF496853: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==12240== Address 0x20 is not stack'd, malloc'd or (recently) free'd
The second entry in the stack trace is for my code
(DbsMySQLShardedConnection.cpp). Line 425, along with the lines
immediately before and after are:
log.debug(string("BEFORE call to ") + ptrConn + string("-
>mysql_fetch_lengths(") + ptrResult + string(")"));
unsigned long *ret = currentConn->mysql_fetch_lengths(result);
log.debug(string("AFTER call to ") + ptrConn + string("-
>mysql_fetch_lengths(") + ptrResult + string(")"));
The last entry in my application log file before the app dies with a
segmentation error is:
BEFORE call to 0x1ab4a690->mysql_fetch_lengths(0x1ddf0b80)
This does confirm that line 425 is indeed the problem, but the code is
supposed to be invoking mysql_fetch_lengths() on an instance of
another class in my C code (the object with address 0x1ab4a690, which
has been invoked many times prior to the failure) so I don't
understand why valgrind is reporting "at 0x1AF0F794: ???". Valgrind is
not detecting any errors prior to this point.
If anyone can give me any pointers on what might be going on here, I
would really appreciate it.
Thanks,
Andy.
---
Andy Grove
Chief Architect
CodeFutures Corporation
"Share Nothing. Shard Everything."
Web: http://www.codefutures.com/
Twitter: http://twitter.com/andygrove73
|
|
From: John R.
|
> ==12240== Invalid read of size 8 > ==12240== at 0x1AF0F794: ??? > ==12240== by 0x168A0224: > DbsMySQLShardedConnection::mysql_fetch_lengths(st_mysql_res*) > (DbsMySQLShardedConnection.cpp:425) > ==12240== by 0x16888FB0: mysql_fetch_lengths (DbsMySQLDriver.cpp:575) > ==12240== by 0x177B6956: pdo_mysql_stmt_fetch (mysql_statement.c:425) > ==12240== Address 0x20 is not stack'd, malloc'd or (recently) free'd > > The second entry in the stack trace is for my code > (DbsMySQLShardedConnection.cpp). Line 425, Notice that both the first and second 'by' lines mention a subroutine with the name 'mysql_fetch_lengths': by 0x168A0224: DbsMySQLShardedConnection::mysql_fetch_lengths(st_mysql_res*) (DbsMySQLShardedConnection.cpp:425) by 0x16888FB0: mysql_fetch_lengths (DbsMySQLDriver.cpp:575) Also notice [the coincidence ?] that line 425 appears on both the first and third 'by' lines. Are there two subroutines with the "same" name 'mysql_fetch_lengths' ? Assume not; so either the debug info generated by the compiler+linker is wrong, or the traceback constructed by memcheck from that data and the actual stack is wrong, or both. Which 'mysql_fetch_lengths' is called by the next outer subroutine pdo_mysql_stmt_fetch ? See if you can make sense by assuming that the first 'by' line is really some unnamed library routine that is called by mysql_fetch_lengths [or some similar "edit" of the reported traceback.] -- |