FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Wed, 11 May 2011 16:12:42 -0400
Raymond R Rankins <rrr03 AT health.state.ny.us> 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