headers
Duncan Kerr | 7 Mar 2012 17:44
Favicon

MS SQLServer drivers / Linux ODBC Driver Manager

Im connecting to SQLServer using the above, using unixODBC-2.3.1.  My test program works fine, my main application fails after successfully connecting to the database when it calls SQLGETDIAGRECW on line 4447 of __info.c.  mky stack looks is below, and the arguments to SQLGETDIAGRECW are

 

SQLGETDIAGRECW(connection=0x00000000006c19c0,

           head->handle_type = 2,

           handle=0x000000000070e650,

rec_number=1,

sqlstate={31152,65535,2,0,94,0},

&native (native=0),

msg1=0x0000fffffff74c0 (byte 0 = NULL)

sizeof(msg1),

&len (len=260545));

 

My test program has similar arguments, except sqlState={31856,99,0,0,75,0} and works fine.  Any ideas folks?

 

Program received signal SIGSEGV, Segmentation fault.

0x00007ffff78390e9 in ?? () from /opt/microsoft/sqlncli/lib64/libsqlncli-11.0.so.1720.0

Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6.x86_64 keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.8.2-3.el6.x86_64 libcom_err-1.41.12-3.el6.x86_64 libgcc-4.4.4-13.el6.x86_64 libselinux-2.0.94-2.el6.x86_64 libstdc++-4.4.4-13.el6.x86_64 libuuid-2.17.2-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64

(gdb) bt

#0  0x00007ffff78390e9 in ?? () from /opt/microsoft/sqlncli/lib64/libsqlncli-11.0.so.1720.0

#1  0x00007ffff786cc80 in ?? () from /opt/microsoft/sqlncli/lib64/libsqlncli-11.0.so.1720.0

#2  0x00007ffff78d0bd4 in ?? () from /opt/microsoft/sqlncli/lib64/libsqlncli-11.0.so.1720.0

#3  0x00007ffff78d0f6d in SQLGetDiagRecW () from /opt/microsoft/sqlncli/lib64/libsqlncli-11.0.so.1720.0

#4  0x0000003d1ca44bc5 in extract_diag_error_w (htype=<value optimized out>, handle=0x70e650, connection=0x6c19c0, head=0x6c1f98, return_code=1, save_to_diag=0) at __info.c:4447

#5  0x0000003d1ca456eb in function_return_ex (level=2, handle=0x6c19c0, ret_code=1, save_to_diag=<value optimized out>) at __info.c:4794

#6  0x0000003d1ca0f9e3 in SQLConnect (connection_handle=0x6c19c0, server_name=<value optimized out>, name_length1=<value optimized out>, user_name=<value optimized out>, name_length2=<value optimized out>,

    authentication=0x7fff00000004 <Address 0x7fff00000004 out of bounds>, name_length3=-3) at SQLConnect.c:4284

#7  0x000000000046cd8c in CDbConnection::AttemptConnectDatabase (this=0x6bb000, szDSN=0x7fffffffb068 "SQLSERVER_49", szUSR=0x7fffffffb0e8 "DEAL_HUB_READER", szPWD=0x7fffffff9450 "read") at ../DbConnection.cpp:321

#8  0x000000000046c96b in CDbConnection::ConnectDatabase (this=0x6bb000, szDSN=0x7fffffffb068 "SQLSERVER_49", szUSR=0x7fffffffb0e8 "DEAL_HUB_READER", szInPWD=0x7fffffffb168 "read", szApp=0x0, iQueryTimeout=900)

    at ../DbConnection.cpp:195

#9  0x000000000046c7aa in CDbConnection::ConnectDatabase (this=0x6bb000, szDSN=0x7fffffffb068 "SQLSERVER_49", szUSR=0x7fffffffb0e8 "DEAL_HUB_READER", szPWD=0x7fffffffb168 "read", iQueryTimeout=900) at ../DbConnection.cpp:168

#10 0x000000000043c6ab in CSCBCacheTbl::LoadDbInfo (pDSN=0x7fffffffb068 "SQLSERVER_49", pUser=0x7fffffffb0e8 "DEAL_HUB_READER", pPWD=0x7fffffffb168 "read", pDBNames=0x0, pError= <at> 0x7fffffff9ed8) at ../scbcachetbl.cpp:261

#11 0x0000000000411108 in CDTS0Serv::Serv_Init (this=0x7fffffffa6a0, hKey=0x2, rootkey=0x7fffffff9fb0 "Software\\Option Computers\\DealHub\\Services\\MLM1") at ../DTS0Serv.cpp:3261

#12 0x0000000000451377 in DHService::OnInit (this=0x7fffffffa6a0) at ../dhservic.cxx:683

#13 0x00000000004551dd in DHService::Serv_RunMain (this=0x7fffffffa6a0) at ../dhservic.cxx:2280

#14 0x0000000000455196 in DHService::Serv_Main (this=0x7fffffffa6a0, argc=3, argv=0x7fffffffe378) at ../dhservic.cxx:2263

#15 0x0000000000418397 in main (argc=3, argv=0x7fffffffe378) at ../DTS0Serv.cpp:10880

(gdb) q

A debugging session is active.

 

Duncan Kerr

Software Engineer

Option Computers Ltd.  (DealHub)

53 New Broad Street, London,  EC2M 1JJ, UK

(Desk: + 44 207 382 5857                              (Fax:   + 44 207 382 4155 

*email: duncan.kerr <at> dealhub.com                    Web:    www.dealhub.com

 

 


________________________________________________________________________
This message may contain privileged and confidential information
intended only for the use of the addressee named above. If you are not
the intended recipient of this message you are hereby notified that any
use, dissemination, distribution or reproduction of this message is
prohibited. If you have received this message in error please notify
the sender immediately. Any views expressed in this message are those of
the individual sender and may not necessarily reflect the views of
the company for whom they represent.
________________________________________________________________________
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply |
headers
Nick Gorham | 9 Mar 2012 10:53
Favicon

Re: MS SQLServer drivers / Linux ODBC Driver Manager

On 07/03/12 16:44, Duncan Kerr wrote:
> Im connecting to SQLServer using the above, using unixODBC-2.3.1.  My test program works fine, my main
application fails after successfully connecting to the database when it calls SQLGETDIAGRECW on line
4447 of __info.c.  mky stack looks is below, and the arguments to SQLGETDIAGRECW are
>
> SQLGETDIAGRECW(connection=0x00000000006c19c0,
>             head->handle_type = 2,
>             handle=0x000000000070e650,
> rec_number=1,
> sqlstate={31152,65535,2,0,94,0},
> &native (native=0),
> msg1=0x0000fffffff74c0 (byte 0 = NULL)
> sizeof(msg1),
> &len (len=260545));
>
> My test program has similar arguments, except sqlState={31856,99,0,0,75,0} and works fine.  Any ideas folks?
Hi,

At that point the driver manager is reading error messages from the 
driver, either after a connection error, or the "changed database to" 
info messages after the connect. I can't see any obvious place the 
problem could occur, the code in question is called everytime the drive 
manager needs to extract a error from the driver.

Looking at the args to function_return_ex with ret_code=1 makes me think 
the connect has been ok, and its just trying to get the info messages 
back after the connection.

Maybe worth trying with valgrind to see if there is any memory 
overwriting issues going on.

--

-- 
Nick
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Permalink | Reply |

Gmane