> ==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.] -- ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
