SQL Server Driver for Linux causes Segmentation Fault

Hello,

I'm using the SQL Server Driver 11.0.1790 on Linux with mod_perl and Apache. While running fine with all my CLI Perl apps I occasionally get Segmentation Faults when using it from within mod_perl applications. Sometimes every other connect to the database segfaults. I've created a core dump and did a stack backtrace:

Loaded symbols for /usr/lib/../lib64/libxml2.so.2
Core was generated by `/usr/sbin/httpd2 -X'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f8a8aeda803 in __connect_part_two (connection=0x7f8a99c885e0) at SQLConnect.c:1891
#2  0x00007f8a8aedffd6 in SQLDriverConnect (hdbc=0x7f8a99c885e0, hwnd=0x0, conn_str_in=0x7fff1e7369ee "", 
    len_conn_str_in=<value optimized="" out="">, 
    conn_str_out=0x7fff1e736a80 "DSN=XXXXX;UID=XXX;PWD=XXXXXXXX;WSID=XXXXXXXX;DATABASE=XXXXX;MARS_Connection=Yes;", 
    conn_str_out_max=512, ptr_conn_str_out=0x7fff1e736a7e, driver_completion=0) at SQLDriverConnect.c:1530
#3  0x00007f8a8b1458ee in odbc_db_login6 (dbh=0x7f8a99938ca0, imp_dbh=0x7f8a99c8acd0, 
    dbname=0x7fff1e736c80 "DSN=XXXXX;MARS_Connection=Yes;UID=XXX;PWD=XXXXXXXX", uid=0x7f8a9996e8b0 "XXX", 
    pwd=0x7f8a9996e8d0 "XXXXXXXX", attr=0x7f8a99938c40) at dbdimp.c:942
#4  0x00007f8a8b141822 in XS_DBD__ODBC__db__login (my_perl=<value optimized="" out="">, cv=<value optimized="" out="">) at ./ODBC.xsi:98
#5  0x00007f8a9125b091 in Perl_pp_entersub (my_perl=0x7f8a96274f50) at pp_hot.c:3046
#6  0x00007f8a912595f6 in Perl_runops_standard (my_perl=0x7f8a96274f50) at run.c:41
#7  0x00007f8a911eb755 in Perl_call_sv (my_perl=0x7f8a96274f50, sv=0x7f8a99938bc8, flags=2) at perl.c:2632
#8  0x00007f8a8b791d02 in XS_DBI_dispatch (my_perl=0x7f8a96274f50, cv=0x7f8a98cbbe60) at DBI.xs:3473
#9  0x00007f8a9125b091 in Perl_pp_entersub (my_perl=0x7f8a96274f50) at pp_hot.c:3046
#10 0x00007f8a912595f6 in Perl_runops_standard (my_perl=0x7f8a96274f50) at run.c:41
#11 0x00007f8a911ebab0 in Perl_call_sv (my_perl=0x7f8a96274f50, sv=0x7f8a97db4f68, flags=10) at perl.c:2647
#12 0x00007f8a9154ba31 in modperl_callback (my_perl=0x7f8a96274f50, handler=0x7f8a96230c90, p=0x7f8a96334838, r=0x7f8a963348b0, 
    s=0x7f8a962303b0, args=0x7f8a998376a8) at modperl_callback.c:101
#13 0x00007f8a9154c79c in modperl_callback_run_handlers (idx=6, type=4, r=0x7f8a963348b0, c=<value optimized="" out="">, s=0x7f8a962303b0, 
    pconf=<value optimized="" out="">, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:262
#14 0x00007f8a9154cb6f in modperl_callback_per_dir (idx=-1714610816, r=<value optimized="" out="">, run_mode=<value optimized="" out="">)
    at modperl_callback.c:369
#15 0x00007f8a91546b93 in modperl_response_handler_run (r=0x7f8a963348b0) at mod_perl.c:1000
#16 modperl_response_handler (r=0x7f8a963348b0) at mod_perl.c:1039
#17 0x00007f8a95f01e08 in ap_run_handler ()
#18 0x00007f8a95f0226c in ap_invoke_handler ()
#19 0x00007f8a95f0ff00 in ap_process_request ()
#20 0x00007f8a95f0ce98 in ?? ()
#21 0x00007f8a95f08b28 in ap_run_process_connection ()
#22 0x00007f8a95f14e5a in ?? ()
#23 0x00007f8a95f15126 in ?? ()
#24 0x00007f8a95f15903 in ap_mpm_run ()
#25 0x00007f8a95eec9be in main ()
</value></value></value></value></value></value></value>

Calling something at NULL obviously doesn't look right

Can onebody help fixing this issue?

Best regards,

Stephan

June 14th, 2012 12:28pm

Looks like the driver doesn't like two active connections at the same time in the same thread or process. I was able to track down the problem:

#!/usr/bin/perl -w

use warnings;
use strict;
use utf8;

use DBI;

my $dsn = "DBI:ODBC:DSN=XXX;MARS_Connection=Yes";
my $uid = 'XXX';
my $pwd = 'XXX';

# First connect...
my $dbh1 = DBI->connect($dsn, $uid, $pwd) || die("Cannot connect to the database");

# Second connect causes Segmentation Fault...
my $dbh2 = DBI->connect($dsn, $uid, $pwd) || die("Cannot connect to the database");

I guess I need somebody with source code access to solve this

Free Windows Admin Tool Kit Click here and download it now
June 14th, 2012 12:53pm

Hi Stephan,

This is a bug in the unixODBC Driver Manager 2.3.0.  Essentially, you can only have one HDBC per HENV.  The mod_perl must be creating the connections upon the same HENV.

The bug appears to be fixed in version 2.3.1 but we have not yet certified that out driver can work with 2.3.1.  See the 2.3.1 release notes at http://www.unixodbc.org/ where the last item says:

"Driver version was not being held when a second connection was made to the driver"

The Driver Manager would "forget" that we are an ODBC V3 driver and try intereacting with us as an ODBC V2 driver for the second connection (which fails).

The workaround is to create a new HENV for each connection but I'm not sure if this is possible in mod_perl.

June 29th, 2012 4:34pm

Hi Randy,

thanks for your update. I've tested SQL driver 1.0 with unixODBC 2.3.1 but it still crashes. By the way, my example given above reproduces the error without mod_perl.

Stephan

Free Windows Admin Tool Kit Click here and download it now
July 4th, 2012 1:25pm

Was really hopeful Microsoft would've provided some sort of solution for this in the last 6 months.  Sadly, this does not appear to be true.
  • Edited by Tom Witt2 Sunday, January 12, 2014 9:27 PM
January 12th, 2014 9:26pm

The latest version of the Microsoft ODBC driver 11 for linux (http://www.microsoft.com/en-us/download/details.aspx?id=36437) and unixODBC 2.3.2 appears to resolve this segfault issue.

This page (while slightly outdated), has excellent information for setting up ODBC on Debian, with Unicode support, and MARS support.
https://blog.afoolishmanifesto.com/posts/install-and-configure-the-ms-odbc-driver-on-debian/

Free Windows Admin Tool Kit Click here and download it now
December 30th, 2014 2:28pm

>> The latest version of the Microsoft ODBC driver 11 for linux (http://www.microsoft.com/en-us/download/details.aspx?id=36437) and unixODBC 2.3.2 appears to resolve this segfault issue.

We can confirm the same with this composite set -  Pyramid 1.5.4, SQLAlchemy 0.9.7, egenix mxODBC 3.3.1, unixODBC 2.3.2 and MS ODBC SQLNCli 11.  Things were good. With unixODBC 2.3.0 we got a segfault. Seems the reason why Microsoft doesn't certify that with higher versions of unixODBC is that unixODBC 2.3.2 doesn't build libodbcinst.so.1, which is a dependency listed by MS ODBC SQLNCli 11 binary. Things could be made to work by just creating a softlink named 'libodbcinst.so.1' pointed to libodbcinst.so. Am not sure if there's any other reason/bug (in either unixODBC 2.3.2 or MS ODBC SQLNCli 11) that's stalling Microsoft from certifying that set.


June 11th, 2015 8:16am

Here we are 1.5 years after this post, and Microsoft's docs still say to use unixODBC 2.3.0. This appears to be a major issue. Has anyone heard anything from Microsoft about this?
Free Windows Admin Tool Kit Click here and download it now
June 11th, 2015 4:44pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics