[asterisk-dev] [Code Review]: adding shared locks around usage of odbc handle in res_odbc

[wdoekes]

> On Dec. 14, 2011, 9:27 a.m., Tilghman Lesher wrote:
> > I'd be more comfortable with this change if you were able to get these crashes with Postgres, due to the number of problems over the years with the MySQL backend driver.  Forcing the connections to be unshared should have the same effect as this patch, do you agree?

(1) > I'd be more comfortable with this change if you were able to get these crashes with Postgres

res_odbc: Connected to asterisk [pgasterisk]
SQL Execute returned an error -1: 42P01: ERROR: relation "sippeer" does not exist;
Error while executing the query (73)
SQL Execute error -1! Verifying connection to asterisk [pgasterisk]...
Disconnected 0 from asterisk [pgasterisk]
Segmentation fault (core dumped)

The patch fixes it.

(2) > Forcing the connections to be unshared should have the same effect as this patch, do you agree?

Agreed, but see (1).


- wdoekes


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1622/#review5007
-----------------------------------------------------------


On Dec. 14, 2011, 3:01 a.m., wdoekes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1622/
> -----------------------------------------------------------
> 
> (Updated Dec. 14, 2011, 3:01 a.m.)
> 
> 
> Review request for Asterisk Developers and Tilghman Lesher.
> 
> 
> Summary
> -------
> 
> See bug report: under certain circumstances res_odbc can be made to crash.
> 
> Adding a shared lock around usage of the con odbc handle is a way to fix this. When a reconnect is attempted, an exclusive lock is held. Result: no usage attempts while reconnecting.
> 
> This is hacked up quickly, so could use a bit of review; it wouldn't surprise me if I double-lock something somewhere. (And the assertion I added fails too.) Also, this could be the wrong way to approach this altogether.
> 
> @tilghman: is there a reason why ->up is set to 0 after query failure? (See same question in bug report at Cause (1).)
> 
> 
> This addresses bug ASTERISK-19011.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19011
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/include/asterisk/res_odbc.h 348047 
>   /branches/1.8/res/res_odbc.c 348047 
> 
> Diff: https://reviewboard.asterisk.org/r/1622/diff
> 
> 
> Testing
> -------
> 
> With the patch, I'm not getting the easy crashes anymore.
> 
> 
> Thanks,
> 
> wdoekes
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111214/3a586042/attachment-0001.htm>