Segmentation violation in extract_diag_error_w

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Segmentation violation in extract_diag_error_w

Zachary Roadhouse
We are using unixODBC 2.3.2 along with Python 2.7.3, pyodbc 3.0.7, Vertica ODBC 6.1.3, on a Debian 6 server.  We have a handful of processes a day that are failing with a segmentation violation.  From the core dump, I have the following information:

#0 0x00007fae2772a88c in extract_diag_error_w (htype=<value optimized out>, handle=<value optimized out>, 
connection=<value optimized out>, head=<value optimized out>, return_code=<value optimized out>, 
save_to_diag=<value optimized out>) at __info.c:4688

I saw a recent similar error posted here relating to a possible buffer overrun in this function for longer error messages (and we definitely have those) but didn’t see any message posting that the problem was resolved with the pre-release version of unixodbc.  Is there any update on this thread?



This e-mail, including attachments, contains confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. The reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation violation in extract_diag_error_w

Nick Gorham-2
On 12/06/14 23:31, Zachary Roadhouse wrote:
We are using unixODBC 2.3.2 along with Python 2.7.3, pyodbc 3.0.7, Vertica ODBC 6.1.3, on a Debian 6 server.  We have a handful of processes a day that are failing with a segmentation violation.  From the core dump, I have the following information:

#0 0x00007fae2772a88c in extract_diag_error_w (htype=<value optimized out>, handle=<value optimized out>, 
connection=<value optimized out>, head=<value optimized out>, return_code=<value optimized out>, 
save_to_diag=<value optimized out>) at __info.c:4688

I saw a recent similar error posted here relating to a possible buffer overrun in this function for longer error messages (and we definitely have those) but didn’t see any message posting that the problem was resolved with the pre-release version of unixodbc.  Is there any update on this thread?

Hi,

There are a couple of changes in the current development  sources that may affect this. Would it be possibe you try the current 2.3.3pre source from the ftp site (or svn), and if you still see the problem, let me know as much as possible about the problem and how to make it happen and I will see if it can be found and fixed.

--
Nick

_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation violation in extract_diag_error_w

Zachary Roadhouse
Nick,

Thank you!  The 2.3.3pre version did indeed fix our problems and allowed us to see the underlying long error message.  Do you have a plan for releasing 2.3.3?  I know we would much prefer to be on a released version.

-Zack

On Jun 13, 2014, at 2:11 AM, Nick Gorham <[hidden email]> wrote:

On 12/06/14 23:31, Zachary Roadhouse wrote:
We are using unixODBC 2.3.2 along with Python 2.7.3, pyodbc 3.0.7, Vertica ODBC 6.1.3, on a Debian 6 server.  We have a handful of processes a day that are failing with a segmentation violation.  From the core dump, I have the following information:

#0 0x00007fae2772a88c in extract_diag_error_w (htype=<value optimized out>, handle=<value optimized out>, 
connection=<value optimized out>, head=<value optimized out>, return_code=<value optimized out>, 
save_to_diag=<value optimized out>) at __info.c:4688

I saw a recent similar error posted here relating to a possible buffer overrun in this function for longer error messages (and we definitely have those) but didn’t see any message posting that the problem was resolved with the pre-release version of unixodbc.  Is there any update on this thread?

Hi,

There are a couple of changes in the current development  sources that may affect this. Would it be possibe you try the current 2.3.3pre source from the ftp site (or svn), and if you still see the problem, let me know as much as possible about the problem and how to make it happen and I will see if it can be found and fixed.

--
Nick
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support



This e-mail, including attachments, contains confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. The reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Segmentation violation in extract_diag_error_w

Nick Gorham-2
On 16/06/14 16:58, Zachary Roadhouse wrote:
Nick,

Thank you!  The 2.3.3pre version did indeed fix our problems and allowed us to see the underlying long error message.  Do you have a plan for releasing 2.3.3?  I know we would much prefer to be on a released version.


Should be soon. Just waiting on some unicode<->ascii questions to be checked.

--
Nick

_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Loading...