Asterisk and ODBC and long standing problem


For some months now I have been trying to get to the bottom of a often reported problem with Askerisk and ODBC, I got a report saying it could be repeated, but then all communication went dead again. I managed to make contact again via IRC but again it went away. But I was left with a comment that it had something to do with NULLs

I have had a look at the ODBC interface in 1.2.24 and can’t see anything obvious. Today I had a look at the 1.4.13 odbc code, and I noticed the following comment

/* We really should only have to do this once.  But for some
   strange reason if I don't it blows holes in memory like
   like a shotgun.  So we just do this so its safe. */

Now looking at the code, I suspect I can see why it would cause memory problems, a local variable is being bound, and if that statement is executed outside of the scope of that function, it will access code in the now unrelated stack, and as its lookign for a string, and there si no length passed when bound, it will read on looking for a ‘\0’ to end the string.

I am not suggesting that this is the cause of the problem I am trying to track down, but it might be related.

The problems I am seeing look as if something is corrupting the heap, and it eventually fails in the ODBC driver in a free(), I have seen the same problem in at least two different drivers, so I still believe the problem is in the application (in this case Asterisk, but I am more than happy to find its the driver, or driver manager, because then I can fix it).

Now I have seen reports in the forum, that the problem has been seen and described as a driver problem (and it may be), but it might also be down to a misuse of memory with a bound column or parameter.

The probles I have is I can’t get it to happen, I don’t have a working system to try this out on. I am more than willing to put the effort into this to resolve the problem, but without a way of making it happen, or at least some set of logs that shows it and what happened before it, I am dead in the water.

As it happens I have been asked to investigate a VOIP solution for Easysoft, so I will be looking at some hardware that might give me enough to reproduce the problem, but I am still in the dark about making it happen.

SO, the upshot of this long ramble. Are there any people reading the forum, who have had unexpeceted seg faults using asterisk and ODBC, if so, could you send me any details you have that might help me to track this down. And are there any people out there who know how to make this problem happen? If so can they also get in touch with me.


Nick Gorham
Easysoft Limited

Just to answer my own question.

I have finally (with the help of another asterisk user, managed to track down a problem using our (Easysoft) SQLServer driver, with very heavy use (> 20 calls a second, that sort of usage).

But in the process, I found a problem in 1.4 trunk, where calling “odbc show” with a TDS type driver can cause a conflict between the “select 1” test and any existing query.

I have some fixed code that sorts the problem, and I have do a bit of work to make the CDR and general ODBC interfaces a bit more efficient.

What should I do to submit those changes?