Re: Crashing with copy_and_convert_field - Mailing list pgsql-odbc

Hi Henrik,

On 2020/09/22 17:00, Henrik Krohns wrote:
> Compiled fresh stack with unixODBC 2.3.9 / libpq 12.4 / psqlodbc git, with
> debugging info.
>
> Actually I can reproduce this with simple isql help command, forget the
> previous Oracle stuff.  I guess it's related to Solaris 11 somehow, I've
> tried both Solaris Studio 12.6 and GCC 9.3 for compiling.  Maybe I'll try
> compiling later on Linux if it's the same.

Could you show me config.h and config.log?

regards,
Hiroshi Inoue

>
>
> $ isql linkkitesti ...
> +---------------------------------------+
> | Connected!                            |
> |                                       |
> | sql-statement                         |
> | help [tablename]                      |
> | quit                                  |
> |                                       |
> +---------------------------------------+
> SQL> select * from testitaulu;
> +---------------------------------------------------+
> | foo                                               |
> +---------------------------------------------------+
> | bar                                               |
> +---------------------------------------------------+
> SQLRowCount returns -1
> 1 rows fetched
> SQL> help testitaulu
> Bus Error (core dumped)
>
>
> (gdb) where
> #0  copy_and_convert_field (stmt=0x100147280, field_type=26, atttypmod=-1, valuei=0x100131a30, fCType=4, precision=0,
rgbValue=0xffffffff7fffe9cc,cbValueMax=4, pcbValue=0x0, pIndicator=0x0) at convert.c:1887
 
> #1  0xfffffffef464e218 in copy_and_convert_field_bindinfo (stmt=0x100147280, field_type=26, atttypmod=-1,
value=0x100131a30,col=11) at convert.c:785
 
> #2  0xfffffffef46a3e38 in SC_fetch (self=0x100147280) at statement.c:1814
> #3  0xfffffffef4682a28 in PGAPI_Fetch (hstmt=0x100147280) at results.c:1212
> #4  0xfffffffef462cd24 in PGAPI_Columns (hstmt=0x1001451a0, szTableQualifier=0x0, cbTableQualifier=0,
szTableOwner=0x0,cbTableOwner=0, szTableName=0x100131650 "testitaulu", cbTableName=-3, szColumnName=0x0,
cbColumnName=0,flag=2, reloid=0, attnum=0) at info.c:2588
 
> #5  0xfffffffef46b5a18 in SQLColumns (StatementHandle=0x1001451a0, CatalogName=0x0, NameLength1=0, SchemaName=0x0,
NameLength2=0,TableName=0x100131650 "testitaulu", NameLength3=-3, ColumnName=0x0, NameLength4=0) at odbcapi.c:125
 
> #6  0xfffffffef4827b18 in SQLColumns (statement_handle=0x100144b10, catalog_name=0x0, name_length1=0,
schema_name=0x0,name_length2=0, table_name=0x100131650 "testitaulu", name_length3=-3, column_name=0x0, name_length4=0)
atSQLColumns.c:369
 
> #7  0x0000000100007bac in ExecuteHelp (hDbc=0x100115600, szSQL=0x100110f20 "help testitaulu", cDelimiter=0 '\000',
bColumnNames=0,bHTMLTable=0) at isql.c:1212
 
> #8  0x00000001000050e0 in main (argc=5, argv=0xffffffff7ffff608) at isql.c:500
>
>
> enterprisedb@linkkitesti=# \d testitaulu
>                      Table "public.testitaulu"
>   Column |         Type          | Collation | Nullable | Default
> --------+-----------------------+-----------+----------+---------
>   foo    | character varying(50) |           | not null |
>
> enterprisedb@linkkitesti=# select version();
>                                                                      version
>
-----------------------------------------------------------------------------------------------------------------------------------------------
>   PostgreSQL 12.4 (EnterpriseDB Advanced Server 12.4.5) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623
(RedHat 4.8.5-36), 64-bit
 
>
>
> Cheers,
> Henrik
>
>
> On Sun, Sep 20, 2020 at 11:01:14AM +0300, Henrik Krohns wrote:
>> TL;DR psqlodbc is dumping core regarding copy_and_convert_field.  No one
>> here can help debug it?
>>
>> On Tue, Sep 01, 2020 at 07:36:48AM +0300, Henrik Krohns wrote:
>>> Any developer around?
>>>
>>>
>>> On Mon, Aug 24, 2020 at 05:41:31PM +0300, Henrik Krohns wrote:
>>>> Hello,
>>>>
>>>> I've been trying to get Oracle 18c -> EnterpriseDB 12.4 ODBC connection
>>>> working without success..
>>>>
>>>> Compiled unixODBC 2.3.7 / libpq 12.2 / psqlodbc 12.02 stack for our Oracle
>>>> server, running Solaris 11.4 SPARC.
>>>>
>>>>
>>>> Basic conf:
>>>>
>>>>
>>>> ### ORACLE_HOME/hs/admin/initLINKKITESTI.ora
>>>> HS_FDS_CONNECT_INFO = linkkitesti
>>>> HS_FDS_TRACE_LEVEL = 255
>>>> HS_FDS_SHAREABLE_NAME = /opt/unixODBC/lib/libodbc.so
>>>>
>>>> ### odbc.ini
>>>> [linkkitesti]
>>>> Driver = PostgreSQL
>>>> Database = linkkitesti
>>>> Servername = ppas.server.com
>>>> Port = 5432
>>>> UseDeclareFetch = 1
>>>> Debug = 1
>>>> LowerCaseIdentifier = 1
>>>>
>>>> ### odbcinst.ini
>>>> [PostgreSQL]
>>>> Description = PostgreSQL ODBC driver
>>>> Driver = /opt/unixODBC/lib/psqlodbcw.so
>>>> Setup = /opt/unixODBC/lib/libodbcpsqlS.so
>>>> FileUsage = 1
>>>>
>>>>
>>>> Results in:
>>>>
>>>>
>>>> Connected to:
>>>> Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
>>>> Version 18.11.0.0.0
>>>>
>>>> SQL> create database link linkkitesti connect to "linkkitesti" identified by "xxxx" using 'LINKKITESTI';
>>>>
>>>> Database link created.
>>>>
>>>> SQL> select * from "testitaulu"@linkkitesti;
>>>> select * from "testitaulu"@linkkitesti
>>>>                             *
>>>> ERROR at line 1:
>>>> ORA-28511: lost RPC connection to heterogeneous remote agent using
>>>> SID=ORA-28511: lost RPC connection to heterogeneous remote agent using
>>>> SID=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxx)(PORT=1522))
>>>> )(CONNECT_DATA=(SID=LINKKITESTI)))
>>>> ORA-02063: preceding line from LINKKITESTI
>>>>
>>>>
>>>>
>>>> Getting core dump with references to copy_and_convert_field function.  The
>>>> test table I have contains nothing but single varchar col with short string.
>>>>
>>>> Here's bunch of odbc/oracle trace files:
>>>>
>>>> https://pastebin.com/RMG5V5vR
>>>> https://pastebin.com/NGtt9hmN
>>>> https://pastebin.com/6Nea2emc
>>>> https://pastebin.com/8qfjsMJw
>>>>
>>>>
>>>> I've tried playing with all sorts of HS_ language settings etc, nothing
>>>> makes a difference.  Downgrading way back to psqlodbc-10.03.0000 stops
>>>> crashing, but the query fails anyway with other errors.
>>>>
>>>> Cheers,
>>>> Henrik
>>>>
>>>>
>