[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