[OpenSER-Devel] publish crash
Juha Heinanen
jh at tutpro.com
Mon Mar 31 15:32:02 CEST 2008
Anca Vamanu writes:
> unfortunately it does not help that much. the only sure thing is that
> something messes up database structures. the segmetation fault is due to
> memory corruption. hope to figure out who does this and how :(.
> thanks a lot for your help.
anca, henning,
when i examined the latest publish crash using gdb, i found that after
db query in presence/notify.c get_subs_db function first column of the
first row was of type int with value 1:
(gdb) print row_vals[0].type
$18 = DB_INT
(gdb) print row_vals[0].val.int_val
$19 = 1
i don't understand how that is possible, because first result_col is
"to_user", which is of type varchar(64):
(gdb) print result_cols[0].s
$21 = 0xb780e4d0 "to_user"
so no wonder that strlen on int value causes core dump:
s.to_user.s= (char*)row_vals[to_user_col].val.string_val;
s.to_user.len= strlen(s.to_user.s);
if i check what types the other result cols are, i get this:
(gdb) print row_vals[0].type
$22 = DB_INT
(gdb) print row_vals[1].type
$23 = DB_STRING
(gdb) print row_vals[2].type
$24 = 320
(gdb) print row_vals[3].type
$25 = 578057061
(gdb) print row_vals[4].type
$26 = 1868770927
...
i.e., something is badly wrong here.
henning, any other explanation on this except that memory in my pc is
broken and, as result, i get from database some random stuff? is it
possible somehow to turn on debug on what mysql module is actually
receiving from database?
-- juha
More information about the Devel
mailing list