Re: Informatica and SSL connections

Hi

I think so.At least it includes libeay and ssleay dlls (which i
tried to replace with the ones from the driver).

I managed to narrow it down to libpq in fe-secure-openssl.c in
pgtls_close.

With the mentioned heidiSQL fields in conn->ssl struct seems to be
messed up with invalid values so it is not the same issue than Informatica.

The call to openssl crashing Informatica is

SSL_free(conn->ssl);

dont know why currently. Just printed some conn->ssl struct fields
(ssl->type, ssl->version, ssl->quiet_shutdown, ssl->shutdown,
ssl->references) but still did not found anything suspicious. I will
try to figure out at least when it will fail in order to prevent the
call then.

Thanks for your replys BTW!

Regards

Jacobo

El 16/02/17 a las 13:30, Inoue, Hiroshi escribió:
> Hi,
>
> Does informatica itself use SSL communications?
>
> regards,
> Hiroshi Inoue
>
> On 2017/02/16 18:50, Jacobo Sánchez wrote:
>>
>> Hi again
>>
>> I could somehow install a similar environment in my machine and
>> new version also crashes when using SSL. However from what i have
>> found from google it points more to an issue with libpq (interacting
>> with some other libraries maybe). I could avoid the issue by not
>> calling PQFinish() in method SOCK_Destructor of socket.c from version
>> 09.03.400 but im not sure which kind of problems/leaks this may
>> raise, do you have any idea of how bad may be this workaround?
>>
>> I could also reproduce the error by installing 32 bit version of
>> heidiSQL (following the error described in
>> http://www.heidisql.com/forum.php?t=15646) and it also crashes
>> calling PQFinish() method (by calling directly libpq and not using ODBC).
>>
>> There is also an old (2005) thread in the postgres mailing list
>> that seems related but im not really sure
>> http://postgresql.nabble.com/BUG-2246-Bad-malloc-interactions-ecpg-openssl-td2119930.html
>>
>> All i found points more to libpq than to the driver itself.
>> However seems to be a tricky thing and i have not an isolated test
>> case without using external clients :(
>>
>> Regards
>> Jacobo
>>
>>
>> El 14/02/17 a las 12:21, Inoue, Hiroshi escribió:
>>> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>