Re: Informatica and SSL connections

Hi,

On 2017/02/14 17:34, Jacobo Sánchez wrote:
>
> Hello
>
>
> Im currently looking for a test environment under my control in
> order to check this or any other solution. Is there any specific
> change that may lead to think that this could be already fixed in
> 09.06.100?

After 09.05.0100 the driver uses libpq fully, whereas the driver used
libpq partially before.

regards,
Hiroshi Inoue

> That may give me a chance to speed up things by asking for testing it
> in a real environment.
>
> Thanks for your response, I will notify the results with 09.06.100
> when tested.
>
>
> Regards
>
> Jacobo
>
>
> El 14/02/17 a las 03:26, Inoue, Hiroshi escribió:
>> Hi Jacobo,
>>
>> On 2017/02/14 1:06, Jacobo Sánchez wrote:
>>>
>>> Hello all
>>>
>>>
>>> Im facing an issue using the ODBC driver from Informatica which may
>>> be resumed in the following (im using 09.03.400):
>>
>> Could you try the latest version 09.06.0100?
>>
>> regards,
>> Hiroshi Inoue
>>
>>> https://kb.informatica.com/solution/23/Pages/52/320564.aspx
>>>
>>> If someone does not want to open the URL the failing trace is as
>>> follows:
>>>
>>> Crashing Thread is as follows:
>>>
>>> ntdll!RtlFreeHeap+132
>>> msvcrt!free+1c
>>> libeay32!CRYPTO_free+2e
>>> libeay32!ASN1_STRING_free+27
>>> libeay32!ASN1_primitive_free+ac
>>> libeay32!ASN1_template_free+128
>>> libeay32!ASN1_template_free+9b
>>> libeay32!ASN1_item_free+1e9
>>> libeay32!X509_free+1a
>>> libpq!PQinitSSL+105c
>>> libpq!PQinitSSL+1113
>>> libpq!PQencryptPassword+7cf
>>> libpq!PQfinish+12
>>> psqlodbc35w!ConfigDriver+1b7e
>>> psqlodbc35w!Ordinal93+4162
>>> psqlodbc35w!Ordinal93+3285
>>> psqlodbc35w!SQLDisconnect+5f
>>> odbc32!SQLDisconnect+2ae
>>> pmodbc!TODBCDb::Disconnect+7f
>>> pmodlnt!TDatabase::Disconnect+3c
>>> pmrelrdr!relReader::fetch+54be
>>> pmservnt!readerSource::operator=+307f
>>> pmservnt!DTMMain+219e8
>>> pmservnt!Writer::Writer+632b
>>> pmservnt!SSeqGenHandler::operator=+2897
>>> pmservnt!isForeignKey+6dd
>>> pmcef!SThread::init+293
>>> kernel32!BaseThreadInitThunk+d
>>> ntdll!RtlUserThreadStart+1d
>>>
>>>
>>> ODBC Trace is as follows:
>>>
>>> _dss_000PQZ0I0 19d8-256c ENTER SQLFreeStmt
>>> HSTMT 0x0000000005C2D030
>>> UWORD 1 <SQL_DROP>
>>>
>>> s_dss_000PQZ0I0 19d8-256c EXIT SQLFreeStmt with return code 0
>>> (SQL_SUCCESS)
>>> HSTMT 0x0000000005C2D030
>>> UWORD 1 <SQL_DROP>
>>>
>>> s_dss_000PQZ0I0 19d8-256c ENTER SQLTransact
>>> HENV 0x0000000000000000
>>> HDBC 0x0000000005C25560
>>> UWORD 0 <SQL_COMMIT>
>>>
>>> s_dss_000PQZ0I0 19d8-256c EXIT SQLTransact with return code 0
>>> (SQL_SUCCESS)
>>> HENV 0x0000000000000000
>>> HDBC 0x0000000005C25560
>>> UWORD 0 <SQL_COMMIT>
>>>
>>> s_dss_000PQZ0I0 19d8-256c ENTER SQLDisconnect
>>> HDBC 0x0000000005C25560​
>>>
>>> I am searching for the root of the issue in order to prevent it from
>>> happening but i am not really sure if the problem comes from libpq
>>> or the driver itself. As far as i understand this is a segmentation
>>> fault by trying to free a malloc that has been already freed,
>>> however im not sure if the problem comes from PQfinish of the driver
>>> calling it when it shouldn't.
>>>
>>> Anyone can point me to where the issue comes from?
>>>
>>> Regards, Jacobo
>>>
>>
>