[OpenSIPS-Devel] [ opensips-Bugs-2860109 ] segfault caused by usrloc:db_timer_udomain when db goes away

[SourceForge.net]

Bugs item #2860109, was opened at 2009-09-16 12:28
Message generated for change (Comment added) made by ptdamore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2860109&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Phil D'Amore (ptdamore)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: segfault caused by usrloc:db_timer_udomain when db goes away

Initial Comment:
db_timer_udomain only initializes the keys for the delete query if there isn't an existing prepared statement  (my_ps == NULL).  This works as long as the connection doesn't go away for a long period of time.  If the db goes away for 2*timer_interval, the stored statement context is no longer valid, and the underlying db_delete function needs to re-create it from the original query.  However, since the keys aren't populated, you get a segfault when there is an attempt to read them.

The patch attached removes the conditional setup of the keys in db_timer_udomain.

This was with the mysql driver, but it seems like good practice for any driver.

----------------------------------------------------------------------

Comment By: Phil D'Amore (ptdamore)
Date: 2009-09-17 15:01

Message:
Hi Bogdan...

I was getting this error in 1.5.3.  Sorry, I should have been explicit
with this before, but I was in a bit too much of a hurry.  1.5.3 has
dbase.c from r5886 which seems to include all changes on the 1.5 branch to
date.

I see some of the changes you might have been referring to and I believe
this is a different problem.  I see that the prep_stmt struct from db_mysql
does in fact cache the statement, which also puzzled me as I looked at this
problem.  Now that I've thought about it, my fix is probably not optimal,
and db_mysql could be doing more to use that cached statement.  The problem
I saw came up in the db_mysql_delete function, although all the db_mysql_OP
functions seem to be structured the same way.

Here's how I'm seeing it:

When the connection goes away, the re_init_statement function removes the
offending statement from the prep_stmt->stmts linked list.  Since, at least
in the case of the usrloc timer task, there is only one statement, the
result is that prep_stmt->stmts is now NULL.  As a result, the next call to
db_mysql_delete calls has_stmt_ctx, which now returns a false value.  This
triggers a call to db_do_delete, which expects the keys to be populated.  I
believe that since the keys are not populated (after all, as far as the
timer function is concerned my_ps is not NULL, so it didn't bother to
populate the keys), db_do_delete winds up exploding.

All of my test servers are now running my patch, but I'll back one out and
reproduce this and get a stack trace you can look at.

Thanks,
Phil

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-09-16 13:52

Message:
That is rather strange as the prepare statements (in mysql module) do catch
the original string query that created the statement and re-use it each
time the statement needs to be re-init. So, the keys are not actually
needed any more (after the original init).

Indeed, there was a problem , but not related to keys, but to the table -
actually this bug was fixed on SVN 1.5 branch last week, so if you update
it should work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2860109&group_id=232389