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