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
___
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
