Stefan Winter <stefan.winter@restena.lu> wrote:
OTOH, I think it's rather bad news:
Thread 9 says:
#9 0x403a8dd2 in sql_query (sqlsocket=0xffffffe0, config=0xffffffe0, querystr=0x262 <Address 0x262 out of bounds>) at sql_mysql.c:161 #10 0x403a4ab0 in rlm_sql_query (sqlsocket=0x819f190, inst=0x81284e0, query=0xbebfe86c ...
That usually happens because of a buffer overflow or stack smash. GDB will print the arguments to sql_query *after* the stack was smashed, which explains why they're nonsense.
So maybe it's in the FR code after all. Maybe a race condition between two threads that mixes pointers up?
I don't see how that can happen when one function calls another. My suggestion is to run it using "valgrind --tool=memcheck". The server will be slow as heck, and may not even work in threaded mode due to valgrind issues. If you're using SSL, valgrind will spit our reams of errors. But it *should* print out any buffer overflows resulting from calling the sql_query function. Alan DeKok.