[asterisk-bugs] [Asterisk 0013109]: [patch] correct the use of errormsg according to the API and implementation of SQLite.

[noreply at bugs.digium.com]

The following issue has been SUBMITTED. 
====================================================================== 
http://bugs.digium.com/view.php?id=13109 
====================================================================== 
Reported By:                gknispel_proformatique
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13109
Category:                   Resources/res_config_sqlite
Reproducibility:            unable to reproduce
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 131914 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-18-2008 12:25 CDT
Last Modified:              07-18-2008 12:25 CDT
====================================================================== 
Summary:                    [patch] correct the use of errormsg according to the
API and implementation of SQLite.
Description: 
The attached patch corrects the use of errormsg according to the SQLite API
and implementation. It also removes the loop on SQLITE_LOCKED conditions
(looping on SQLITE_BUSY condition is OK).

errormsg is dynamically allocated both in some internal layers of the
SQLite library and reallocated just before the SQLite function exits.
SQLite can't give us any hard warranty that the allocation (first or
subsequent) of the errormsg will succeed, and if it fails errormsg will
remain NULL despite error being set.

Also, I'm not sure that errormsg will always remain NULL on success, so I
added / moved some sqlite_freemem() so that it is always called.
sqlite_freemem() is just a wrapper around free(), so sqlite_freemem(NULL)
is a noop, so this is always safe.

An other thing is that in RES_CONFIG_SQLITE_BEGIN / RES_CONFIG_SQLITE_END
loops, errormsg can be allocated on busy condition but it was never freed
in the loop.

Finally, there should be no retry after an SQLITE_LOCKED error as
http://www.sqlite.org/c_interface.html says that SQLITE_LOCKED is a busy
conditions caused by recursion of sqlite_exec calls in a callback of a
previous one, and this is only allowed for read only access - when one
tries to do that in a RW way he gets a SQLITE_LOCKED. So retrying the query
will just yield to the same result in that case.

====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-18-08 12:26  gknispel_proformatiqueSVN Branch (only for SVN checkou =>  trunk
         
07-18-08 12:26  gknispel_proformatiqueSVN Revision (number only!) => 131914     
    
======================================================================