Bugs item #1577808, was opened at 2006-10-15 23:44
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=512945&aid=1577808&group_id=65979
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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter MacDonald (pcmacdon)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlite error messages being discarded
Initial Comment:
Rather than just letting sqlite error messages be
discarded, this patch copies them into error_message
so that we get more than just a blank string .
NOTE: Copy of patch submitted to libdbi core.
----------------------------------------------------------------------
>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-16 22:28
Message:
Logged In: YES
user_id=85809
I've analyzed the situation again, and I still maintain
there is no need to fix dbi_main.c. The situation where new
value == old value, resulting in a NULL assignment, can only
arise if a driver abuses the error message system. This has
unfortunately been the case for the sqlite and sqlite3
drivers. See the discussion for bug #1577808 (reassigned to
libdbi-drivers from #1577323).
This bug turned out to be quite complex, although the fix is
rather simple. The error message system works well for pgsql
and mysql which have functions that return the most recent
SQL query error message. Thess functions are called from
dbi_main.c:_error_handler() via the driver-specific
dbd_geterror() function, i.e. after libdbi knows that an
error occurred.
The SQLite 2.x API lacks such a function. All we have is the
error message, if any, returned by the sqlite_exec()
function. As the most recent SQL query error needs to be
stored per connection, we cannot use a global variable to
buffer this value. Instead, the sqlite driver has to abuse
the conn->error_number and conn->error_message variables to
store the return code and message, respectively. Two bugs
prevented this scheme from working properly. First, the
driver called _error_handler() instead of
_dbd_internal_error_handler() whenever a query failed. The
former function does not store the error message, hence it
was lost. Second, the dbd_geterror() function did return the
stored error message instead of a copy. This led to the
situation where dbi_main.c:_error_handler() would reassign
the free'd buffer to conn->error_message, thus causing
mayhem. The attached patch fixes these problems.
The SQLite 3.x API does have a function that returns the
most recent SQL query error message. Instead of using the
same workaround as SQLite, the sqlite3 driver should be
brought in line with the pgsql and mysql drivers where the
error message related core dumps never occurred. The
attached patch addresses this as well.
I've also added a test for the error message facility to the
test_dbi.c program, see the latest cvs version.
Please test the provided patch and let me know whether it
fixes the problems you reported.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=512945&aid=1577808&group_id=65979
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
|
