Re: Segmentation Fault in error handler
"James K. Lowden" <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 11 May 2011 16:12:42 -0400 Raymond R Rankins <[email protected]> wrote: > I'm testing out fisql to run some queries and when there's an error > with severity > 10 which invokes the error handler, it's causing a > segmentation fault and dumping the core. > This is happening if I connect to SQL Server or to Sybase. > > Below are examples of what's happening: > > Error raised in SQL Server > ---------------------------------------------- > Msg 2812, Level 16, State 62: > Server 'CHPLUSSQL01', Line 1: > Could not find stored procedure 'sp_modifystats'. > DB-LIBRARY error: > General SQL Server error: Check messages from the SQL Server > Segmentation Fault - core dumped This turns out to be a deep and interesting bug, hard to find but easy to fix. Thanks for finding it. The fisql error handler has this code: if (oserr != DBNOERR) { fprintf(stdout, "Operating-system error:\n\t%s\n", oserrstr); } and DBNOERR should be -1 $ grep DBNOERR include/sybdb.h #define DBNOERR -1 but if oserr is anything else, and oserrstr == NULL, you'll get a segmentation fault. And, indeed, oserr is zero. But why? I wanted to blame Microsoft and Sybase for not agreeing on the value, when I realized this is the *error* handler provoked by receiving a *message*. In other words, db-lib code, the obscure _dblib_handle_info_message() function invokes the error handler for messages with severity > 10. (*_dblib_err_handler)(dbproc, msg->severity, msg->msgno, 0, (char *) message, NULL); Changing that to (*_dblib_err_handler)(dbproc, msg->severity, msg->msgno, DBNOERR, (char *) message, NULL); fixes the problem. Committed to HEAD and 0.91RC branches. --jkl