|
From: Diego T. <dtg...@te...> - 2003-07-13 23:27:28
|
ehlo!
i've got the following issue when using valgrind. Maybe i'm doing something
wrong or i don't know how to use valgrind. Another point is that maybe this
isn't the correct place to ask about my problem... i'll see :)
the following function:
>----
MYSQL_ROW db_read(const char *q, ...) {
MYSQL_ROW row;
MYSQL_RES * res;
[...]
if ((res = mysql_store_result(&g.mysql_dbh)) != NULL) {
row = mysql_fetch_row(res);
mysql_free_result(res);
return row;
}
[...]
>----
and when debugging with valgrind, i got the following:
==23479== Invalid read of size 1
==23479== at 0x4028AD24: __strtol_internal (in /lib/libc-2.3.1.so)
==23479== by 0x40288848: atoi (in /lib/libc-2.3.1.so)
==23479== by 0x412F874D: mod_load (in
/home/dtorres/prog/develop/rb/mod/db.so)
==23479== by 0x804CC32: module_init (src/modules.c:43)
==23479== Address 0x410C8294 is 32 bytes inside a block of size 8164
free'd
==23479== at 0x4015D6A4: free (vg_clientfuncs.c:185)
==23479== by 0x40213838: my_no_flags_free (in
/usr/lib/libmysqlclient.so.10.0.0)
==23479== by 0x402165F4: free_root (in /usr/lib/libmysqlclient.so.10.0.0)
==23479== by 0x4020F5E8: mysql_free_result (in
/usr/lib/libmysqlclient.so.10.0.0)
==23479==
the atoi is performed over the returned row: atoi(row[0]). So i understand
that when i'm releasing with mysql_free_result, row is contained inside the
res pointer. Checking the documentation from the mysql api doesn't clarify
this situation, it doesn't state if its safe to access rows returned from
mysql_fetch_row. So lets fix it:
MYSQL_ROW db_read(const char *q, ...) {
MYSQL_ROW row;
MYSQL_ROW row2;
MYSQL_RES * res;
[...]
if ((res = mysql_store_result(&g.mysql_dbh)) != NULL) {
row = mysql_fetch_row(res);
memcpy(&row2, &row, sizeof(MYSQL_ROW));
mysql_free_result(res);
return row2;
}
[...]
now i'm copying the row content to another variable, but got the same
result.
==24120== Invalid read of size 1
==24120== at 0x4028AA6E: __strtol_internal (in /lib/libc-2.3.1.so)
==24120== by 0x40288848: atoi (in /lib/libc-2.3.1.so)
==24120== by 0x412F86F9: mod_load (in
/home/dtorres/prog/develop/rb/mod/db.so)
==24120== by 0x804CC32: module_init (src/modules.c:43)
==24120== Address 0x410C18FC is 32 bytes inside a block of size 8164
free'd
==24120== at 0x4015D6A4: free (vg_clientfuncs.c:185)
==24120== by 0x40213838: my_no_flags_free (in
/usr/lib/libmysqlclient.so.10.0.0)
==24120== by 0x402165F4: free_root (in /usr/lib/libmysqlclient.so.10.0.0)
==24120== by 0x4020F5E8: mysql_free_result (in
/usr/lib/libmysqlclient.so.10.0.0)
The strange thing is that the program is working without problems, and data
from the returned row is always valid. coincidence? If someone has any
idea... please, help! :)
|
|
From: <pa...@pa...> - 2003-07-14 15:21:09
|
>>>>> On Mon, 14 Jul 2003 01:27:34 +0200, "Diego Torres" <dtg...@te...> said:
> the atoi is performed over the returned row: atoi(row[0]).
Which means that "row" is a pointer ...
> now i'm copying the row content to another variable, but got the same
> result.
You are copying a *pointer* to data to another pointer. It's the *data*
that you want to copy. What you've done is (apparently) equivalent to:
char *p = strdup("hello");
char *q;
memcpy(&q, &p, sizeof(q));
free(p);
return q;
> The strange thing is that the program is working without problems, and data
> from the returned row is always valid. coincidence?
Yes. That's what makes "dangling" bugs so hard to find.
Cheers,
--
Paul Pluzhnikov pa...@pa...
|
|
From: Diego T. <dtg...@te...> - 2003-07-17 17:18:25
|
Thanks for the hint :) now everything is working fine (once i've reimplemented the functions that were causing me some troubles). So my program ends with exit without problems (?) but then: --3557-- Caught __NR_exit; running __libc_freeres() SYSCALL[3557,1]( 91): munmap ( 0x0, 0 ) ==3557== Invalid read of size 1 ==3557== at 0x4034B45B: _dl_close (in /lib/libc-2.3.1.so) ==3557== by 0x4034BE6E: (within /lib/libc-2.3.1.so) ==3557== by 0x400095BD: _dl_catch_error_internal (in /lib/ld-2.3.1.so) ==3557== by 0x4034BDB4: (within /lib/libc-2.3.1.so) ==3557== Address 0x1E7 is not stack'd, malloc'd or free'd And yes, i'm using some dynamic loaded libraries and closing them without errors. So, is there a bug on valgrind 1.9.6 (from debian) and libc-2.3.1? Because valgrind also exits with a segmentation fault. So, who is munmaping 0x0?. any idea? |