Re: Segmentation Fault in error handler

Raymond R Rankins <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <OFE3D9A617.3351EFA4-ON85257892.0054CA0F-85257892.0054D469@notes.health.state.ny.us>
Thanks for the quick fix.

Glad I could help track down this bug.

-Ray

===============================================
Ray Rankins
[email protected]
(518) 474-1094




From:	"James K. Lowden" <[email protected]>
To:	[email protected]
Date:	05/14/2011 09:07 AM
Subject:	Re: [freetds] Segmentation Fault in error handler
Sent by:	[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
_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds

IMPORTANT NOTICE: This e-mail and any attachments may contain confidential or sensitive information which is, or may be, legally privileged or otherwise protected by law from further disclosure. It is intended only for the addressee. If you received this in error or from someone who was not authorized to send it to you, please do not distribute, copy or use it or any attachments. Please notify the sender immediately by reply e-mail and delete this from your system. Thank you for your cooperation.

_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds
graycol.gif (image/gif, 105 B) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.