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.
Please provide a self-contained test case.
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.
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
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
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.
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.
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.
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
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.