Bug 458708 - SQLGetDiagRec() segfaults on end of diagnostic data
SQLGetDiagRec() segfaults on end of diagnostic data
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: unixODBC (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-11 14:14 EDT by Patrick Monnerat
Modified: 2013-07-02 23:19 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-17 11:17:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
C program exhibiting the bug described (2.25 KB, text/x-csrc)
2008-08-12 11:50 EDT, Patrick Monnerat
no flags Details

  None (edit)
Description Patrick Monnerat 2008-08-11 14:14:48 EDT
Description of problem:
When requiring the last+1'th diagnostic record, SQLGetDiagRec() segfaults instead of returning SQL_NO_DATA

Version-Release number of selected component (if applicable):
unixODBC-2.2.12-5.fc8
postgresql-odbc-08.02.0500-1.fc8
postgresql-8.2.9-1.fc8

How reproductible:
Always.

Steps to Reproduce:
1. Write a program that performs an ODBC request (my case in on a postgresql db), no matter if successful or not.
2. Dump diagnostic records for the request handle in a loop using procedure SQLGetDiagRec(), varying RecNumber argument from 1 upwards.
3. When RecNumber reaches the Diagnostic Record Count + 1, SQLGetDiagRec() segfaults instead of returning SQL_NO_DATA
  
Actual results:
seg fault


Expected results:
Returns SQL_NO_DATA

Additional info:
Excerpts from http://msdn.microsoft.com/en-us/library/ms716256(VS.85).aspx:

SQLGetDiagRec does not post diagnostic records for itself. It uses the following return values to report the outcome of its own execution: 
SQL_NO_DATA: RecNumber was greater than the number of diagnostic records that existed for the handle specified in Handle. The function also returns SQL_NO_DATA for any positive RecNumber if there are no diagnostic records for Handle.
.
.
.
An application can scan all diagnostic records by looping, incrementing RecNumber, as long as SQLGetDiagRec returns SQL_SUCCESS.
Comment 1 Tom Lane 2008-08-11 19:02:01 EDT
Please provide a self-contained test case.
Comment 2 Patrick Monnerat 2008-08-12 11:50:19 EDT
Created attachment 314109 [details]
C program exhibiting the bug described

Please locate/create a DB + table with a character field on your target system
and fill the #define at the top of program accordingly.
Comment 3 Bug Zapper 2008-11-26 06:05:30 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Patrick Monnerat 2008-12-04 11:07:02 EST
Bug still occurring on Fedora 10. This report's version changed.
Packages are:
unixODBC-2.2.12-9.fc10.i386
postgresql-odbc-08.03.0200-1.fc10.i386
Comment 5 Tom Lane 2009-02-14 14:02:14 EST
Hm, I can't reproduce this using the supplied test program.  I get

$ ./a.out
(1) 01004 (-2) Fetched item was truncated.
(2) 01004 (-2) Fetched item was truncated.
Name: a 
(1) 01004 (-2) Fetched item was truncated.
(2) 01004 (-2) Fetched item was truncated.
Name: ab
(1) 01004 (-2) Fetched item was truncated.
(2) 01004 (-2) Fetched item was truncated.
Name: ab
(1) 01004 (-2) Fetched item was truncated.
(2) 01004 (-2) Fetched item was truncated.
Name: ab
$ echo $?
0

using a table containing four rows

 a   
 ab  
 abcd
 abcd

Perhaps there is some additional dependency you've not mentioned, like what's in the table?
Some experimenting with other data didn't fail either, though.
Comment 6 Patrick Monnerat 2009-02-16 06:12:55 EST
Strange... the output here is:
$ ./a.out
(1) 01004 (-2) [unixODBC]The buffer was too small for the result.
Segmentation fault
$ 
I can note you get a postgresql-odbc error text, while I get a unixODBC message...

Here is my table dump:
--
-- PostgreSQL database dump
--

SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;

SET search_path = public, pg_catalog;

SET default_tablespace = '';

SET default_with_oids = false;

--
-- Name: client; Type: TABLE; Schema: public; Owner: mc; Tablespace: 
--

CREATE TABLE client (
    id integer NOT NULL,
    name character(48) NOT NULL,
    address1 character(48) NOT NULL,
    address2 character(48) NOT NULL,
    pocode character(16) NOT NULL,
    city character(48) NOT NULL,
    province character(48) NOT NULL,
    country character(48) NOT NULL
);


ALTER TABLE public.client OWNER TO mc;

--
-- Data for Name: client; Type: TABLE DATA; Schema: public; Owner: mc
--

INSERT INTO client VALUES (1, 'Datasphère SA                                   ', 'Chemin des Aulx 16                              ', '                                                ', '1228            ', 'Plan-les-Ouates                                 ', 'Genève                                          ', 'Suisse                                          ');


--
-- Name: client_pkey; Type: CONSTRAINT; Schema: public; Owner: mc; Tablespace: 
--

ALTER TABLE ONLY client
    ADD CONSTRAINT client_pkey PRIMARY KEY (id);


--
-- PostgreSQL database dump complete
--

I tried on the "name" field.
Please note that I tried without the accent characters and it fails too.

Thanks for your investigations.
Comment 7 Tom Lane 2009-02-16 16:06:48 EST
Hmm, I only see that string in the sources for unixODBC's built-in Postgres driver, which is not recommended because it's old/unmaintained/full of bugs.  Try using the postgresql-odbc driver instead.
Comment 8 Patrick Monnerat 2009-02-17 04:52:20 EST
You are perfectly right !

I did not even know that a postgresql driver was built-in unixODBC and I took the default odbcinst.ini content as a real usable data example, stored there in prevision of the postgresql-odbc driver installation.

I addition, there is neither directives nor template file nor %post in postgresql-odbc that configures (or directs you to configure) the installation in odbcinst.ini.

Thus if the built-in driver is bad, may I suggest to remove it from the installed files and from the default odbcinst.ini configuration ?

Many thanks for your help
Comment 9 Tom Lane 2009-02-17 11:17:25 EST
Yeah, it's going to be gone as of the next major unixODBC revision (should be in F-11).  As far as F-10 goes, I'm closing this WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.