Igor Korot | 5 Jun 19:27 2016
Picon

Problem connecting to the DSN

Hi, (Nick),

I am trying to see why my program fails to connect.

First some setup:

[code]
igor <at> IgorDellGentoo ~ $ cat /etc/unixODBC/odbcinst.ini
[ODBC]
Trace=No
TraceFile=/tmp/sql.log
Pooling=No

[myodbc-5.2]
Description=MySQL ODBC 5.2 Driver
Driver=/usr/lib/libmyodbc5a.so
UsageCount=1

[freetds]
Description=Microsoft SQL Server
Driver=libtdsodbc.so
UsageCount=1

igor <at> IgorDellGentoo ~ $ cat /etc/unixODBC/odbc.ini
[ODBC Data Sources]
myodbc-5.2-test=MySQL ODBC 5.2 Driver Testing DSN
freetds=Microsoft SQL Server

[myodbc-5.2-test]
Description=MySQL ODBC 5.2 Driver Testing DSN
(Continue reading)

Joshua Colp | 2 Jun 17:53 2016
Gravatar

_check_ini_cache Regression

Kia ora,

First time posting here so sorry if this is the incorrect place (since 
I'm discussing a regression and specific code I thought your dev list 
was most appropriate).

In the 2.3.3 release a change was made to the _check_ini_cache function 
in odbcinst/SQLGetPrivateProfileString.c to fix an issue.

The code before the change was:

         if ( nRetBuffer != ini_cache -> buffer_size )
             continue;

This was changed to:

         if ( nRetBuffer <= ini_cache -> buffer_size )
             continue;

Unfortunately this has caused a regression where cached entries are not 
actually being used, causing the linked list to grow. In my case 
nRetBuffer is 1024 and ini_cache->buffer_size is 1024 as expected. This 
results in them being evaluated as equal and therefore skipped. Since 
I'm testing an environment where many disconnect/connect attempts are 
occurring at the same time this spirals and the cache grows out of control.

Looking at the code I think the following is the right fix for it but 
I'm still looking to confirm:

         if ( nRetBuffer < ini_cache -> buffer_size )
(Continue reading)

Igor Korot | 26 Mar 16:10 2016
Picon

UNICODE support

Hi, (Nick),
Is it enough to do:

#define UNICODE

in order to use SQLW-types and functions?

Or I need to define something else?

Thank you.
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

Satheesh Subramanian | 22 Mar 17:00 2016
Picon

Re: unixODBC-dev Digest, Vol 104, Issue 6

Hey Nick, 
 Thanks a lot for looking into it.

 We are using the unicode driver. do_attr method of the version which I was using(2.3.1) was not setting the connect attribute to the unicode driver

static void do_attr( DMHDBC connection, int value,
        int value_set, int attr3, int attr2  )
{
    if ( value_set )
    {
        if (CHECK_SQLSETCONNECTATTR( connection ))
        {
            SQLSETCONNECTATTR(connection,
                        connection -> driver_dbc,
                        attr3,
                        value,
                        sizeof( value ));
        }
        else if (CHECK_SQLSETCONNECTOPTION(connection) && attr2 )
        {
            SQLSETCONNECTOPTION(connection,
                        connection -> driver_dbc,
                        attr2,
                        value );
        }
    }
}

But when I looked at the latest version of the code (2.3.4), it is indeed setting the value to the unicode driver

static void do_attr( DMHDBC connection, int value,
        int value_set, int attr3, int attr2  )
{
    if ( value_set )
    {
        if (CHECK_SQLSETCONNECTATTR( connection ))
        {
            SQLSETCONNECTATTR(connection,
                        connection -> driver_dbc,
                        attr3,
                        value,
                        sizeof( value ));
        }
        else if (CHECK_SQLSETCONNECTOPTION(connection) && attr2 )
        {
            SQLSETCONNECTOPTION(connection,
                        connection -> driver_dbc,
                        attr2,
                        value );
        }
        else if (CHECK_SQLSETCONNECTATTRW( connection ))     /* they are int values, so this should be safe */
        {
            SQLSETCONNECTATTRW(connection,
                        connection -> driver_dbc,
                        attr3,
                        value,
                        sizeof( value ));
        }
        else if (CHECK_SQLSETCONNECTOPTIONW(connection) && attr2 )
        {
            SQLSETCONNECTOPTIONW(connection,
                        connection -> driver_dbc,
                        attr2,
                        value );
        }
    }
}

I have built the new version of the driver and it worked. 

Thanks a lot for  your help

On Tue, Mar 22, 2016 at 5:00 AM, <unixodbc-dev-request <at> mailman.unixodbc.org> wrote:
Send unixODBC-dev mailing list submissions to
        unixodbc-dev <at> mailman.unixodbc.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
or, via email, send a message with subject or body 'help' to
        unixodbc-dev-request <at> mailman.unixodbc.org

You can reach the person managing the list at
        unixodbc-dev-owner <at> mailman.unixodbc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of unixODBC-dev digest..."


Today's Topics:

   1. SQL_ATTR_LOGIN_TIMEOUT behaviour (Satheesh Subramanian)
   2. Re: SQL_ATTR_LOGIN_TIMEOUT behaviour (Satheesh Subramanian)
   3. Re: SQL_ATTR_LOGIN_TIMEOUT behaviour (Nick Gorham)


----------------------------------------------------------------------

Message: 1
Date: Tue, 22 Mar 2016 00:34:09 -0700
From: Satheesh Subramanian <satheesh101 <at> gmail.com>
Subject: [unixODBC-dev] SQL_ATTR_LOGIN_TIMEOUT behaviour
To: unixodbc-dev <at> mailman.unixodbc.org
Message-ID:
        <CALSGBWW4VmhY+8OA_TcHdnnKWWQDGdE9eeQ9qu6wajNtwNn9tQ <at> mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,
 We ran into a problem where connection to mysql database is not timing out
within specified SQL_ATTR_LOGIN_TIMEOUT value even when the database is not
reachable.

 We use UNixODBC driver manager and mysql odbc driver to connect to the
mysql database. In order to make a connection to the database we do the
following
1) Allocate Handle
2) Set SQL_ATTR_LOGIN_TIMEOUT to 5 seconds by calling SQLSetConnectAttr
3) Call SQLDriverConnect to make the connection.

To debug the issue, I first enabled the trace logs and then started to look
at the source code of unix odbc driver manager.

By looking at the SQLDriverConnectW.c code, looks like the
attribute SQL_ATTR_LOGIN_TIMEOUT is only saved to an internal variable as
long as the connection state is C2.

And SQLDriverConnectW.c is trying to load the driver as part pf
"part_one_connection" and then trying to make SQLDriverConnectW call to the
mysql odbc driver. So, looks like SQL_ATTR_LOGIN_TIMEOUT is being ignored
and will never be passed on to mysql driver unless the connection state is
something other than C2. Looking at the code connection state would be
moved out of S2 state only after a successful connect request to the driver

I believe this is the reason why login timeout is not getting honoured.

So, to confirm that, I made a change in SQLDriverConnectW to call the mysql
driver to set the login timeout(which was saved to internal variable in  an
earlier call) after loading the driver but before making the actual
connection. Afer this change, value set for SQL_ATTR_LOGIN_TIMEOUT started
to work.

I am not convinced driver manager would ignore the timeout and I suspect I
am doing something wrong. I could not find the reason after going through
the code multiple times over last few days.

Can someone please point me to the right direction? How does the driver
manager set the connection timeout to mysql driver? Any help is much
appreciated!.

Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-dev/attachments/20160322/0b6b7e28/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 22 Mar 2016 01:12:21 -0700
From: Satheesh Subramanian <satheesh101 <at> gmail.com>
Subject: Re: [unixODBC-dev] SQL_ATTR_LOGIN_TIMEOUT behaviour
To: unixodbc-dev <at> mailman.unixodbc.org
Message-ID:
        <CALSGBWXwrbEkYfoDQDURFvYu3S1pKK6YkdGWAW5mSHCpNispsw <at> mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Please note we are using
unixODBC version : 2.3.1
mysql odbc driver version : 5.3.4

On Tue, Mar 22, 2016 at 12:34 AM, Satheesh Subramanian <
satheesh101 <at> gmail.com> wrote:

> Hi,
>  We ran into a problem where connection to mysql database is not timing
> out within specified SQL_ATTR_LOGIN_TIMEOUT value even when the database is
> not reachable.
>
>  We use UNixODBC driver manager and mysql odbc driver to connect to the
> mysql database. In order to make a connection to the database we do the
> following
> 1) Allocate Handle
> 2) Set SQL_ATTR_LOGIN_TIMEOUT to 5 seconds by calling SQLSetConnectAttr
> 3) Call SQLDriverConnect to make the connection.
>
> To debug the issue, I first enabled the trace logs and then started to
> look at the source code of unix odbc driver manager.
>
> By looking at the SQLDriverConnectW.c code, looks like the
> attribute SQL_ATTR_LOGIN_TIMEOUT is only saved to an internal variable as
> long as the connection state is C2.
>
> And SQLDriverConnectW.c is trying to load the driver as part pf
> "part_one_connection" and then trying to make SQLDriverConnectW call to the
> mysql odbc driver. So, looks like SQL_ATTR_LOGIN_TIMEOUT is being ignored
> and will never be passed on to mysql driver unless the connection state is
> something other than C2. Looking at the code connection state would be
> moved out of S2 state only after a successful connect request to the driver
>
> I believe this is the reason why login timeout is not getting honoured.
>
> So, to confirm that, I made a change in SQLDriverConnectW to call the
> mysql driver to set the login timeout(which was saved to internal variable
> in  an earlier call) after loading the driver but before making the actual
> connection. Afer this change, value set for SQL_ATTR_LOGIN_TIMEOUT started
> to work.
>
> I am not convinced driver manager would ignore the timeout and I suspect I
> am doing something wrong. I could not find the reason after going through
> the code multiple times over last few days.
>
> Can someone please point me to the right direction? How does the driver
> manager set the connection timeout to mysql driver? Any help is much
> appreciated!.
>
> Thanks in advance
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-dev/attachments/20160322/94ebbdad/attachment-0001.html>

------------------------------

Message: 3
Date: Tue, 22 Mar 2016 10:01:24 +0000
From: Nick Gorham <nick <at> lurcher.org>
Subject: Re: [unixODBC-dev] SQL_ATTR_LOGIN_TIMEOUT behaviour
To: unixodbc-dev <at> mailman.unixodbc.org
Message-ID: <56F117F4.9070108 <at> lurcher.org>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 22/03/16 07:34, Satheesh Subramanian wrote:
> Hi,
>  We ran into a problem where connection to mysql database is not
> timing out within specified SQL_ATTR_LOGIN_TIMEOUT value even when the
> database is not reachable.
>
>  We use UNixODBC driver manager and mysql odbc driver to connect to
> the mysql database. In order to make a connection to the database we
> do the following
> 1) Allocate Handle
> 2) Set SQL_ATTR_LOGIN_TIMEOUT to 5 seconds by calling SQLSetConnectAttr
> 3) Call SQLDriverConnect to make the connection.
>
> To debug the issue, I first enabled the trace logs and then started to
> look at the source code of unix odbc driver manager.

Well, checking here with the current build (and I dont see any changes
that would affect this) __connect_part_one() contains

     /*
      * set any connection atributes
      */

     DO_ATTR( connection, access_mode, SQL_ATTR_ACCESS_MODE,
SQL_ACCESS_MODE );
*    DO_ATTR( connection, login_timeout, SQL_ATTR_LOGIN_TIMEOUT,
SQL_LOGIN_TIMEOUT );*
     DO_ATTR( connection, auto_commit, SQL_ATTR_AUTOCOMMIT,
SQL_AUTOCOMMIT );
     DO_ATTR( connection, async_enable, SQL_ATTR_ASYNC_ENABLE,
SQL_ASYNC_ENABLE );
     DO_ATTR( connection, auto_ipd, SQL_ATTR_AUTO_IPD, 0 );
     DO_ATTR( connection, connection_timeout,
SQL_ATTR_CONNECTION_TIMEOUT, 0 );
     DO_ATTR( connection, metadata_id, SQL_ATTR_METADATA_ID, 0 );
     DO_ATTR( connection, packet_size, SQL_ATTR_PACKET_SIZE,
SQL_PACKET_SIZE );
     DO_ATTR( connection, quite_mode, SQL_ATTR_QUIET_MODE, SQL_QUIET_MODE );
     DO_ATTR( connection, txn_isolation, SQL_ATTR_TXN_ISOLATION,
SQL_TXN_ISOLATION );

And SQLSetConnectAttr.c contains

     /*
      * we need to save this even if connected so we can use it for the
next connect
      */
     if ( attribute == SQL_ATTR_LOGIN_TIMEOUT )
     {
         connection -> login_timeout = ( SQLLEN ) value;
         connection -> login_timeout_set = 1;
     }

And the comment when this was changed

  * Revision 1.4  2002/01/10 11:17:20  lurcher
  *
  * Allow SQL_ATTR_LOGIN_TIMEOUT to be set when connected to mirror what the
  * MS DM does


2002 is release 2.2.0, so thats been there for some time.

I just tried with one of our (Easysoft) drivers to check, and it seems
to work as I would expect, calling SQLSetConnect in the driver between
the SQLAllocEnv( SQL_CONNECT ) and the SQLConnect/SQLDriverConnect

--
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-dev/attachments/20160322/7fd504f7/attachment-0001.html>

------------------------------

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


End of unixODBC-dev Digest, Vol 104, Issue 6
********************************************

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Satheesh Subramanian | 22 Mar 08:34 2016
Picon

SQL_ATTR_LOGIN_TIMEOUT behaviour

Hi,
 We ran into a problem where connection to mysql database is not timing out within specified SQL_ATTR_LOGIN_TIMEOUT value even when the database is not reachable.

 We use UNixODBC driver manager and mysql odbc driver to connect to the mysql database. In order to make a connection to the database we do the following
1) Allocate Handle
2) Set SQL_ATTR_LOGIN_TIMEOUT to 5 seconds by calling SQLSetConnectAttr
3) Call SQLDriverConnect to make the connection.

To debug the issue, I first enabled the trace logs and then started to look at the source code of unix odbc driver manager.

By looking at the SQLDriverConnectW.c code, looks like the attribute SQL_ATTR_LOGIN_TIMEOUT is only saved to an internal variable as long as the connection state is C2. 

And SQLDriverConnectW.c is trying to load the driver as part pf "part_one_connection" and then trying to make SQLDriverConnectW call to the mysql odbc driver. So, looks like SQL_ATTR_LOGIN_TIMEOUT is being ignored and will never be passed on to mysql driver unless the connection state is something other than C2. Looking at the code connection state would be moved out of S2 state only after a successful connect request to the driver

I believe this is the reason why login timeout is not getting honoured. 

So, to confirm that, I made a change in SQLDriverConnectW to call the mysql driver to set the login timeout(which was saved to internal variable in  an earlier call) after loading the driver but before making the actual connection. Afer this change, value set for SQL_ATTR_LOGIN_TIMEOUT started to work.

I am not convinced driver manager would ignore the timeout and I suspect I am doing something wrong. I could not find the reason after going through the code multiple times over last few days.

Can someone please point me to the right direction? How does the driver manager set the connection timeout to mysql driver? Any help is much appreciated!. 

Thanks in advance 
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Igor Korot | 19 Mar 06:33 2016
Picon

SQLInstallerErrorW

Hi, (Nick),
I installed unixodbc-2.3.2 the latest stable version for Gentoo).
I turned on the unicode support as well.

In my program I'm trying to use SQLConfigDataSource() call and my program
is being compiled with UNICODE support.

I did include odbcinst.h and I'm linking with -lodbcinst.
All this inside the .so library.

However, when running the application and trying to call dlopen(). I'm
getting an
error saying "undefined symbol SQLInstallerErrorW".
I even tried to add -lodbc to the link command, but the same error persist.

On Windows the code is executing without any issues.

Can someone shed some light on that?

Thank you.
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

Funny,Solomon | 10 Mar 20:06 2016

ODBC Connection Problem from Linux to SQL Server Daabase

Our Unix Admin installed the SQL Server ODBC Drivers for Linux on our Linux server, but when I attempt to connect to a SQL Server, I receive the following error message:

 

[IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed

[ISQL]ERROR: Could not SQLConnect

 

I did successfully test the SQL Server authenticated account and password, I am trying to connect to within SQL server

When I googled the error, it indicated either the ODBC drivers are not mentioned properly, or environment variable are not set ODBCSYSINI ODBCINI.

 

I performed the command env from the command line and the environment variables were set ODBCSYSINI ODBCINI:

 

ODBCINI=/etc/odbc.ini

ODBCSYSINI=/etc

 

I checked the data source and driver configurations set by the Unix Admin, and they looked correct:

 

/etc/odbc.ini

[TITAN]

Description=SQL Server ODBC Driver

Driver=SQL Server Native Client 11.0

Server=nts-entdbd1

Port=1433

Database=prod01

 

/etc/odbcinst.ini

[SQL Server Native Client 11.0]

Description=Microsoft SQL Server ODBC Driver V1.0 for Linux

Driver=/usr/lib64/libodbc.so.1.0.0

Threading=1

UsageCount=1

Trace=Yes

 

This is my companies first experience with Linux ODBC, so we are not sure what the issue is.  I executed a trace for the connect string and found that several files/directories could not be found:

 

/etc/ld.so.preload                                           ===> Does not exist

/usr/lib64/tls/x86_64                                     ===> No files in /usr/lib64/tls

/usr/lib64/tls/x86_64/libodbc.so.1           ===> No files in /usr/lib64/tls

/usr/lib64/tls/libodbc.so.1                           ===> No files in /usr/lib64/tls

 

                                                                                            When I execute the find command for file libodbc.so.1, it is located in /lib64/tls/libnss_files.so.1  or /lib/libnss_files.so.1   

 

/var/run/nscd/socket                                    ===> No files in /var/run/nscd

 

/usr/lib64/tls/libnss_files.so.2                    ===> No files in /usr/lib64/tls

 

                                                                                            When I execute the find command for file libodbc.so.1, it is located in /lib64/tls/libnss_files.so.2  or /lib/libnss_files.so.2   

 

I am not sure how to point the system to these directories, as I have modified my profile to include them in the PATH, but after re-executing the profile, the connection test fails.

                                                                                               

The following is the output from executing the env command:

 

_=*29835*/bin/env

CVS_RSH=ssh

G_BROKEN_FILENAMES=1

HISTCONTROL=ignoredups

HISTSIZE=1000

HOME=/home/funnys

HOSTNAME=lx-had12

KRB5CCNAME=FILE:/tmp/krb5cc_2072_ocjbfp

LANG=en_US.UTF-8

LESSOPEN=||/usr/bin/lesspipe.sh %s

LOGNAME=funnys

MAIL=/var/spool/mail/funnys

ODBCINI=/etc/odbc.ini

ODBCSYSINI=/etc

PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/etc:/lib:/lib64

PS1=lx-had12:${LOGNAME}:${PWD}>

PWD=/home/funnys

QTDIR=/usr/lib64/qt-3.3

QTINC=/usr/lib64/qt-3.3/include

QTLIB=/usr/lib64/qt-3.3/lib

SELINUX_LEVEL_REQUESTED=

SELINUX_ROLE_REQUESTED=

SELINUX_USE_CURRENT_RANGE=

SHELL=/bin/ksh

SHLVL=1

SSH_CLIENT=10.2.202.206 52940 22

SSH_CONNECTION=10.2.202.206 52940 10.2.201.191 22

SSH_TTY=/dev/pts/0

TERM=xterm

USER=funnys

_AST_FEATURES=UNIVERSE - ucb

A__z="*SHLVL

 

Is the environment missing any variables?

 

Any assistance anyone rendered will be greatly appreciated!

 

Thank You

 

Solomon Funny

Database Services

Federal Home Loan Bank of New York

30 Montgomery Street

Jersey City, NJ 07322

(201) 356-1235

solomon.funny <at> fhlbny.com

 

Confidentiality Notice: The information contained in this e-mail and any attachments (including, but not limited to, any attached e-mails) may be legally privileged and confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person.
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Igor Korot | 21 Feb 03:38 2016
Picon

User Manual

Hi, Peter,
It look like http://www.unixodbc.org/doc/UserManual/ still references
GUI tools.
They are not in the main distribution anymore and it looks like they fail
to build.

I guess someone needs to write a new UG about how to do
everything by hand.

Thank you.
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

Igor Korot | 16 Jan 03:35 2016
Picon

unixodbc gui split

Hi, Nick,
Sorry to write on the private email. I just don't know which unixODBC
mailing list is still good...

Have a quick question: what was the reasoning behind the GUI part split?
I am running Gentoo and trying to compile the unixODBC GUI part it
gives an error.

It is very helpful to have the GUI part put back and ship it as one project.

Thank you.
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

Andrew Punch | 12 Nov 00:38 2015

Re: Buffer overflow in extract_diag_error_w()

Hi,

I tested 2.3.4 and it does not segfault. The netezza driver is a bit 
buggy, so I wouldn't be surprised if it is doing something wrong.

Thanks for your help.

-Andrew

On 11/11/15 23:00, unixodbc-dev-request <at> mailman.unixodbc.org wrote:
> Send unixODBC-dev mailing list submissions to
> 	unixodbc-dev <at> mailman.unixodbc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
> or, via email, send a message with subject or body 'help' to
> 	unixodbc-dev-request <at> mailman.unixodbc.org
>
> You can reach the person managing the list at
> 	unixodbc-dev-owner <at> mailman.unixodbc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of unixODBC-dev digest..."
>
>
> Today's Topics:
>
>     1. Buffer overflow in extract_diag_error_w() (Andrew Punch)
>     2. Re: Buffer overflow in extract_diag_error_w() (Nick Gorham)
>     3. Re: Buffer overflow in extract_diag_error_w() (Andrew Punch)
>     4. Re: Buffer overflow in extract_diag_error_w() (Nick Gorham)
>     5. Re: Buffer overflow in extract_diag_error_w() (Nick Gorham)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 11 Nov 2015 17:32:03 +1100
> From: Andrew Punch <andrew.punch <at> smart-associates.biz>
> Subject: [unixODBC-dev] Buffer overflow in extract_diag_error_w()
> To: unixodbc-dev <at> mailman.unixodbc.org
> Message-ID: <5642E0E3.3020608 <at> smart-associates.biz>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
> I am working with Netezza in Perl. The script was crashing with a
> segfault. When I used gdb to investigate the problem was isolated to the
> wide_strcpy() call in extract_diag_error_w() due to a larger than
> expected error message from the Netezza driver. The error message from
> the Netezza driver was not corrupt and was in the correct format.
>
> I solved this problem in the short term by increasing
> SQL_MAX_MESSAGE_LENGTH from 512 to 1024. Ideally something like
> wcscpy_s() should be used.
>
> Thanks
> -Andrew
>
> diff -ur unixODBC-2.3.1/include/sql.h unixodbc-2.3.1-patched/include/sql.h
> --- unixODBC-2.3.1/include/sql.h    2011-07-04 18:54:09.000000000 +1000
> +++ unixodbc-2.3.1-patched/include/sql.h    2015-11-11
> 16:13:26.709201111 +1100
>  <at>  <at>  -46,7 +46,7  <at>  <at> 
>    #define SQL_NTSL                  (-3L)
>
>    /* maximum message length */
> -#define SQL_MAX_MESSAGE_LENGTH   512
> +#define SQL_MAX_MESSAGE_LENGTH   1024
>
>    /* date/time length constants */
>    #if (ODBCVER >= 0x0300)
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 11 Nov 2015 09:50:42 +0000
> From: Nick Gorham <nick <at> lurcher.org>
> Subject: Re: [unixODBC-dev] Buffer overflow in extract_diag_error_w()
> To: unixodbc-dev <at> mailman.unixodbc.org
> Message-ID: <56430F72.7060803 <at> lurcher.org>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 11/11/15 06:32, Andrew Punch wrote:
>> Hi,
>>
>> I am working with Netezza in Perl. The script was crashing with a
>> segfault. When I used gdb to investigate the problem was isolated to
>> the wide_strcpy() call in extract_diag_error_w() due to a larger than
>> expected error message from the Netezza driver. The error message from
>> the Netezza driver was not corrupt and was in the correct format.
>>
>> I solved this problem in the short term by increasing
>> SQL_MAX_MESSAGE_LENGTH from 512 to 1024. Ideally something like
>> wcscpy_s() should be used.
>>
>> Thanks
>> -Andrew
>>
>> diff -ur unixODBC-2.3.1/include/sql.h
>> unixodbc-2.3.1-patched/include/sql.h
>> --- unixODBC-2.3.1/include/sql.h    2011-07-04 18:54:09.000000000 +1000
>> +++ unixodbc-2.3.1-patched/include/sql.h    2015-11-11
>> 16:13:26.709201111 +1100
>>  <at>  <at>  -46,7 +46,7  <at>  <at> 
>>   #define SQL_NTSL                  (-3L)
>>
>>   /* maximum message length */
>> -#define SQL_MAX_MESSAGE_LENGTH   512
>> +#define SQL_MAX_MESSAGE_LENGTH   1024
>>
>>   /* date/time length constants */
>>   #if (ODBCVER >= 0x0300)
>> _______________________________________________
>> unixODBC-dev mailing list
>> unixODBC-dev <at> mailman.unixodbc.org
>> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
> Hi, SQL_MAX_MESSAGE_LENGTH is defined by the MS headers so we don't want
> to alter that, but have you tried a current build of unixODBC, as 2.3.1
> was from 26th November 2011. I think the problem is fixed in 2.3.3, the
> changes contain "Fix buffer overrun returning long diagnostic from driver".
>
> Try the current, 2.3.5-pre and if the problem is still there, provide
> details and we will sort it out. How long is the message that comes from
> the driver?
>

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

Andrew Punch | 11 Nov 07:32 2015

Buffer overflow in extract_diag_error_w()

Hi,

I am working with Netezza in Perl. The script was crashing with a 
segfault. When I used gdb to investigate the problem was isolated to the 
wide_strcpy() call in extract_diag_error_w() due to a larger than 
expected error message from the Netezza driver. The error message from 
the Netezza driver was not corrupt and was in the correct format.

I solved this problem in the short term by increasing 
SQL_MAX_MESSAGE_LENGTH from 512 to 1024. Ideally something like 
wcscpy_s() should be used.

Thanks
-Andrew

diff -ur unixODBC-2.3.1/include/sql.h unixodbc-2.3.1-patched/include/sql.h
--- unixODBC-2.3.1/include/sql.h    2011-07-04 18:54:09.000000000 +1000
+++ unixodbc-2.3.1-patched/include/sql.h    2015-11-11 
16:13:26.709201111 +1100
 <at>  <at>  -46,7 +46,7  <at>  <at> 
  #define SQL_NTSL                  (-3L)

  /* maximum message length */
-#define SQL_MAX_MESSAGE_LENGTH   512
+#define SQL_MAX_MESSAGE_LENGTH   1024

  /* date/time length constants */
  #if (ODBCVER >= 0x0300)
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev


Gmane