1.1.1: Backtrace of non-responding server

[Alan DeKok]

Stefan Winter <stefan.winter at 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.