Обсуждение: Not sure if this crash is in psql odbc driver?

On 06/23/2014 08:50 AM, Itnal, Prakash (NSN - IN/Bangalore) wrote:
> Hi,
>
> We encountered a crash that points to psql odbc driver. The crash is
> not at fixed at same point but it always points to psql-odbc driver. It
> is at same two places shown below. Kindly let me know if this is really
> an issue in psql code!

Could be, but it's impossible to track it down without more information.
For starters, if you could try with a debug-enabled build of the driver,
so that we could see line number information and local variables in the
backtrace, that would help.

If you can reduce the test to a small self-contained test case that
reproduces the crash, that would be best. Can you provide more details
on the application and how it uses the driver? Is it multi-threaded?
What ODBC functions does it call? What config options are you using?

- Heikki

> If you can reduce the test to a small self-contained test case that
> reproduces the crash, that would be best. Can you provide more details
> on the application and how it uses the driver? Is it multi-threaded?
> What ODBC functions does it call? What config options are you using?

We tried to create a self contained program to reproduce the issue but
the issue is not observed with self contained program. It is only observed
with actual application code. So is why I am not fully confident of issue
being in psql odbc driver code but at the same time we do not find any
suspicion in using any of the ODBC APIs.

We will run the test again with debug enabled psql odbc driver code and
share the backtrace.

It is multi-threaded application.

ODBC configuration is almost all default:
# cat odbc.ini
[PostgreSQL]
Description    = data source for PostgreSQL
Driver         = PostgreSQL

# cat odbcinst.ini
[PostgreSQL]
Description    = psql_odbc for PostgreSQL
Driver         = /opt/PostgresClient/lib/psqlodbcw.so
Setup          =
FileUsage      = 1
Threading      = 0


--
Regards,
Prakash I.


-----Original Message-----
From: ext Heikki Linnakangas [mailto:hlinnakangas@vmware.com]
Sent: Monday, June 23, 2014 1:36 PM
To: Itnal, Prakash (NSN - IN/Bangalore); pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Not sure if this crash is in psql odbc driver?

On 06/23/2014 08:50 AM, Itnal, Prakash (NSN - IN/Bangalore) wrote:
> Hi,
>
> We encountered a crash that points to psql odbc driver. The crash is
> not at fixed at same point but it always points to psql-odbc driver. It
> is at same two places shown below. Kindly let me know if this is really
> an issue in psql code!

Could be, but it's impossible to track it down without more information.
For starters, if you could try with a debug-enabled build of the driver,
so that we could see line number information and local variables in the
backtrace, that would help.

If you can reduce the test to a small self-contained test case that
reproduces the crash, that would be best. Can you provide more details
on the application and how it uses the driver? Is it multi-threaded?
What ODBC functions does it call? What config options are you using?

- Heikki

Please find the backtrace with debug enabled psqlODBC driver. This time we encountered abort. The requested table has
onlyone row. 


Thread 1 (LWP 7326):
#0  0x000000556380aff0 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x000000556380f8fc in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00000055638459e4 in __libc_message () from /lib64/libc.so.6
No symbol table info available.
#3  0x0000005563851ec4 in malloc_printerr () from /lib64/libc.so.6
No symbol table info available.
#4  0x0000005563856f04 in free () from /lib64/libc.so.6
No symbol table info available.
#5  0x0000005581d8d200 in QR_free_memory (self=0x5563951a70) at qresult.c:463
        num_backend_rows = 366742936192
        num_fields = 0
#6  0x0000005581d8c6f0 in QR_close_result (self=0x5563951a70, destroy=1) at qresult.c:273
        conn = 0x120f80cd0
        next = 0x5581d8c8a4
        top = 1
#7  0x0000005581d8c8c8 in QR_Destructor (self=0x5563951a70) at qresult.c:327
No locals.
#8  0x0000005581dafc04 in SC_recycle_statement (self=0x120dbbdc0) at statement.c:886
        func = 0x5581dee0b8 "SC_recycle_statement"
        conn = 0x120f709e0
        res = 0x5563951a70
#9  0x0000005581daf924 in SC_initialize_and_recycle (self=0x120dbbdc0) at statement.c:802
No locals.
#10 0x0000005581d7b76c in PGAPI_ExecDirect (hstmt=0x120dbbdc0, szSqlStr=0x55930762a8 "SELECT wbts_id FROM act_wbts
WHEREwbts_id=130", cbSqlStr=-3, flag=1) at execute.c:161 
        stmt = 0x120dbbdc0
        result = 0
        func = 0x5581de5e10 "PGAPI_ExecDirect"
        conn = 0x120f709e0
#11 0x0000005581dc129c in SQLExecDirect (StatementHandle=0x120dbbdc0, StatementText=0x55930762a8 "SELECT wbts_id FROM
act_wbtsWHERE wbts_id=130", TextLength=-3) at odbcapi.c:364 
        func = 0x5581def670 "SQLExecDirect"
        ret = 0
        stmt = 0x120dbbdc0
        flag = 1
#12 0x0000005563d69858 in SQLExecDirect () from /usr/lib64/libodbc.so.2
No symbol table info available.
#13 0x00000055631136b4 in db_ExecDirect1 (stmt1=0x5593076250, query=0x55930762a8 "SELECT wbts_id FROM act_wbts WHERE
wbts_id=130")at ../src/db_utilityqx.c:923 

--
Regards,
Prakash I.


-----Original Message-----
From: ext Heikki Linnakangas [mailto:hlinnakangas@vmware.com]
Sent: Monday, June 23, 2014 1:36 PM
To: Itnal, Prakash (NSN - IN/Bangalore); pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Not sure if this crash is in psql odbc driver?

On 06/23/2014 08:50 AM, Itnal, Prakash (NSN - IN/Bangalore) wrote:
> Hi,
>
> We encountered a crash that points to psql odbc driver. The crash is
> not at fixed at same point but it always points to psql-odbc driver. It
> is at same two places shown below. Kindly let me know if this is really
> an issue in psql code!

Could be, but it's impossible to track it down without more information.
For starters, if you could try with a debug-enabled build of the driver,
so that we could see line number information and local variables in the
backtrace, that would help.

If you can reduce the test to a small self-contained test case that
reproduces the crash, that would be best. Can you provide more details
on the application and how it uses the driver? Is it multi-threaded?
What ODBC functions does it call? What config options are you using?

- Heikki

Oh, that came from a libc assertion free(). Did it print out an error
message with more details? Seems to be some sort of memory corruption,
that explains why you're seeing crashes at random places.

I'd suggest running the test program with Valgrind, to see if it finds
the issue. If it's a driver bug, I think we'll need to see a
self-contained test program to reproduce it, otherwise it'll be
impossible to track it down.

On 06/26/2014 08:16 AM, Itnal, Prakash (NSN - IN/Bangalore) wrote:
> Please find the backtrace with debug enabled psqlODBC driver. This time we encountered abort. The requested table has
onlyone row. 
>
>
> Thread 1 (LWP 7326):
> #0  0x000000556380aff0 in raise () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x000000556380f8fc in abort () from /lib64/libc.so.6
> No symbol table info available.
> #2  0x00000055638459e4 in __libc_message () from /lib64/libc.so.6
> No symbol table info available.
> #3  0x0000005563851ec4 in malloc_printerr () from /lib64/libc.so.6
> No symbol table info available.
> #4  0x0000005563856f04 in free () from /lib64/libc.so.6
> No symbol table info available.
> #5  0x0000005581d8d200 in QR_free_memory (self=0x5563951a70) at qresult.c:463
>          num_backend_rows = 366742936192
>          num_fields = 0
> #6  0x0000005581d8c6f0 in QR_close_result (self=0x5563951a70, destroy=1) at qresult.c:273
>          conn = 0x120f80cd0
>          next = 0x5581d8c8a4
>          top = 1
> #7  0x0000005581d8c8c8 in QR_Destructor (self=0x5563951a70) at qresult.c:327
> No locals.
> #8  0x0000005581dafc04 in SC_recycle_statement (self=0x120dbbdc0) at statement.c:886
>          func = 0x5581dee0b8 "SC_recycle_statement"
>          conn = 0x120f709e0
>          res = 0x5563951a70
> #9  0x0000005581daf924 in SC_initialize_and_recycle (self=0x120dbbdc0) at statement.c:802
> No locals.
> #10 0x0000005581d7b76c in PGAPI_ExecDirect (hstmt=0x120dbbdc0, szSqlStr=0x55930762a8 "SELECT wbts_id FROM act_wbts
WHEREwbts_id=130", cbSqlStr=-3, flag=1) at execute.c:161 
>          stmt = 0x120dbbdc0
>          result = 0
>          func = 0x5581de5e10 "PGAPI_ExecDirect"
>          conn = 0x120f709e0
> #11 0x0000005581dc129c in SQLExecDirect (StatementHandle=0x120dbbdc0, StatementText=0x55930762a8 "SELECT wbts_id FROM
act_wbtsWHERE wbts_id=130", TextLength=-3) at odbcapi.c:364 
>          func = 0x5581def670 "SQLExecDirect"
>          ret = 0
>          stmt = 0x120dbbdc0
>          flag = 1
> #12 0x0000005563d69858 in SQLExecDirect () from /usr/lib64/libodbc.so.2
> No symbol table info available.
> #13 0x00000055631136b4 in db_ExecDirect1 (stmt1=0x5593076250, query=0x55930762a8 "SELECT wbts_id FROM act_wbts WHERE
wbts_id=130")at ../src/db_utilityqx.c:923 
>
> --
> Regards,
> Prakash I.
>
>
> -----Original Message-----
> From: ext Heikki Linnakangas [mailto:hlinnakangas@vmware.com]
> Sent: Monday, June 23, 2014 1:36 PM
> To: Itnal, Prakash (NSN - IN/Bangalore); pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Not sure if this crash is in psql odbc driver?
>
> On 06/23/2014 08:50 AM, Itnal, Prakash (NSN - IN/Bangalore) wrote:
>> Hi,
>>
>> We encountered a crash that points to psql odbc driver. The crash is
>> not at fixed at same point but it always points to psql-odbc driver. It
>> is at same two places shown below. Kindly let me know if this is really
>> an issue in psql code!
>
> Could be, but it's impossible to track it down without more information.
> For starters, if you could try with a debug-enabled build of the driver,
> so that we could see line number information and local variables in the
> backtrace, that would help.
>
> If you can reduce the test to a small self-contained test case that
> reproduces the crash, that would be best. Can you provide more details
> on the application and how it uses the driver? Is it multi-threaded?
> What ODBC functions does it call? What config options are you using?
>
> - Heikki
>


--
- Heikki

Hi,

In the backtrace I observed num_backend_rows set to some big number. Is this expected? Because our tables does not have
suchhigh row count! I am asking just out-of-curiosity! 

> #5  0x0000005581d8d200 in QR_free_memory (self=0x5563951a70) at qresult.c:463
>          num_backend_rows = 366742936192
>          num_fields = 0

We will further analyze application code to understand memory corruption.

--
Regards,
Prakash I.


-----Original Message-----
From: ext Heikki Linnakangas [mailto:hlinnakangas@vmware.com]
Sent: Thursday, June 26, 2014 1:54 PM
To: Itnal, Prakash (NSN - IN/Bangalore); pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Not sure if this crash is in psql odbc driver?

Oh, that came from a libc assertion free(). Did it print out an error
message with more details? Seems to be some sort of memory corruption,
that explains why you're seeing crashes at random places.

I'd suggest running the test program with Valgrind, to see if it finds
the issue. If it's a driver bug, I think we'll need to see a
self-contained test program to reproduce it, otherwise it'll be
impossible to track it down.

On 06/26/2014 08:16 AM, Itnal, Prakash (NSN - IN/Bangalore) wrote:
> Please find the backtrace with debug enabled psqlODBC driver. This time we encountered abort. The requested table has
onlyone row. 
>
>
> Thread 1 (LWP 7326):
> #0  0x000000556380aff0 in raise () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x000000556380f8fc in abort () from /lib64/libc.so.6
> No symbol table info available.
> #2  0x00000055638459e4 in __libc_message () from /lib64/libc.so.6
> No symbol table info available.
> #3  0x0000005563851ec4 in malloc_printerr () from /lib64/libc.so.6
> No symbol table info available.
> #4  0x0000005563856f04 in free () from /lib64/libc.so.6
> No symbol table info available.
> #5  0x0000005581d8d200 in QR_free_memory (self=0x5563951a70) at qresult.c:463
>          num_backend_rows = 366742936192
>          num_fields = 0
> #6  0x0000005581d8c6f0 in QR_close_result (self=0x5563951a70, destroy=1) at qresult.c:273
>          conn = 0x120f80cd0
>          next = 0x5581d8c8a4
>          top = 1
> #7  0x0000005581d8c8c8 in QR_Destructor (self=0x5563951a70) at qresult.c:327
> No locals.
> #8  0x0000005581dafc04 in SC_recycle_statement (self=0x120dbbdc0) at statement.c:886
>          func = 0x5581dee0b8 "SC_recycle_statement"
>          conn = 0x120f709e0
>          res = 0x5563951a70
> #9  0x0000005581daf924 in SC_initialize_and_recycle (self=0x120dbbdc0) at statement.c:802
> No locals.
> #10 0x0000005581d7b76c in PGAPI_ExecDirect (hstmt=0x120dbbdc0, szSqlStr=0x55930762a8 "SELECT wbts_id FROM act_wbts
WHEREwbts_id=130", cbSqlStr=-3, flag=1) at execute.c:161 
>          stmt = 0x120dbbdc0
>          result = 0
>          func = 0x5581de5e10 "PGAPI_ExecDirect"
>          conn = 0x120f709e0
> #11 0x0000005581dc129c in SQLExecDirect (StatementHandle=0x120dbbdc0, StatementText=0x55930762a8 "SELECT wbts_id FROM
act_wbtsWHERE wbts_id=130", TextLength=-3) at odbcapi.c:364 
>          func = 0x5581def670 "SQLExecDirect"
>          ret = 0
>          stmt = 0x120dbbdc0
>          flag = 1
> #12 0x0000005563d69858 in SQLExecDirect () from /usr/lib64/libodbc.so.2
> No symbol table info available.
> #13 0x00000055631136b4 in db_ExecDirect1 (stmt1=0x5593076250, query=0x55930762a8 "SELECT wbts_id FROM act_wbts WHERE
wbts_id=130")at ../src/db_utilityqx.c:923 
>
> --
> Regards,
> Prakash I.
>
>
> -----Original Message-----
> From: ext Heikki Linnakangas [mailto:hlinnakangas@vmware.com]
> Sent: Monday, June 23, 2014 1:36 PM
> To: Itnal, Prakash (NSN - IN/Bangalore); pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Not sure if this crash is in psql odbc driver?
>
> On 06/23/2014 08:50 AM, Itnal, Prakash (NSN - IN/Bangalore) wrote:
>> Hi,
>>
>> We encountered a crash that points to psql odbc driver. The crash is
>> not at fixed at same point but it always points to psql-odbc driver. It
>> is at same two places shown below. Kindly let me know if this is really
>> an issue in psql code!
>
> Could be, but it's impossible to track it down without more information.
> For starters, if you could try with a debug-enabled build of the driver,
> so that we could see line number information and local variables in the
> backtrace, that would help.
>
> If you can reduce the test to a small self-contained test case that
> reproduces the crash, that would be best. Can you provide more details
> on the application and how it uses the driver? Is it multi-threaded?
> What ODBC functions does it call? What config options are you using?
>
> - Heikki
>


--
- Heikki

Hi,

Recently we tested this with debug version of psql-odbc driver. Attached is the backtrace. Due security policies I have
deletecertain sections which are any way not relevant from backtrace. 

ODBC version: Latest ODBC code from trunk
Postgres server version: 9.1
Unix ODBC: 2.2.14
Target Architecture: mips-64
Scenario: Restart (server and client both running on same HW unit)


Below is quick summary from backtrace:

From backtrace:
Thread 1 (LWP 7532):
#0  0x000000555aec5d7c in memcpy () from /lib64/libc.so.6
No symbol table info available.
#1  0x000000559b99dd08 in copy_and_convert_field (stmt=0x559c076130, field_type=17, atttypmod=-1, valuei=0x559c229c90,
fCType=-2,precision=0, rgbValue=0x55a7fd7310, cbValueMax=1252, pcbValue=0x55a7fd7298, pIndicator=0x55a7fd7298) at
convert.c:1793
.
.
         ptr = 0x0
.
.


From code:
1788                 if (cbValueMax > 0)
1789                 {
1790                     copy_len = (len > cbValueMax) ? cbValueMax : len;
1791
1792                     /* Copy the data */
1793                     memcpy(rgbValueBindRow, ptr, copy_len);
1794
1795                     /* Adjust data_left for next time */
1796                     if (stmt->current_col >= 0)
1797                         pgdc->data_left -= copy_len;
1798                 }

Since the ptr is 0x0 (NULL), the memcpy is failed. We are not able to debug it fully since we are not fully competent
withpsqlODBC code base.  

It would be of great help if someone helps to resolve this!

--
Regards,
Prakash I.

-----Original Message-----
From: ext Heikki Linnakangas [mailto:hlinnakangas@vmware.com]
Sent: Thursday, June 26, 2014 1:54 PM
To: Itnal, Prakash (NSN - IN/Bangalore); pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Not sure if this crash is in psql odbc driver?

Oh, that came from a libc assertion free(). Did it print out an error
message with more details? Seems to be some sort of memory corruption,
that explains why you're seeing crashes at random places.

I'd suggest running the test program with Valgrind, to see if it finds
the issue. If it's a driver bug, I think we'll need to see a
self-contained test program to reproduce it, otherwise it'll be
impossible to track it down.

On 06/26/2014 08:16 AM, Itnal, Prakash (NSN - IN/Bangalore) wrote:
> Please find the backtrace with debug enabled psqlODBC driver. This time we encountered abort. The requested table has
onlyone row. 
>
>
> Thread 1 (LWP 7326):
> #0  0x000000556380aff0 in raise () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x000000556380f8fc in abort () from /lib64/libc.so.6
> No symbol table info available.
> #2  0x00000055638459e4 in __libc_message () from /lib64/libc.so.6
> No symbol table info available.
> #3  0x0000005563851ec4 in malloc_printerr () from /lib64/libc.so.6
> No symbol table info available.
> #4  0x0000005563856f04 in free () from /lib64/libc.so.6
> No symbol table info available.
> #5  0x0000005581d8d200 in QR_free_memory (self=0x5563951a70) at qresult.c:463
>          num_backend_rows = 366742936192
>          num_fields = 0
> #6  0x0000005581d8c6f0 in QR_close_result (self=0x5563951a70, destroy=1) at qresult.c:273
>          conn = 0x120f80cd0
>          next = 0x5581d8c8a4
>          top = 1
> #7  0x0000005581d8c8c8 in QR_Destructor (self=0x5563951a70) at qresult.c:327
> No locals.
> #8  0x0000005581dafc04 in SC_recycle_statement (self=0x120dbbdc0) at statement.c:886
>          func = 0x5581dee0b8 "SC_recycle_statement"
>          conn = 0x120f709e0
>          res = 0x5563951a70
> #9  0x0000005581daf924 in SC_initialize_and_recycle (self=0x120dbbdc0) at statement.c:802
> No locals.
> #10 0x0000005581d7b76c in PGAPI_ExecDirect (hstmt=0x120dbbdc0, szSqlStr=0x55930762a8 "SELECT wbts_id FROM act_wbts
WHEREwbts_id=130", cbSqlStr=-3, flag=1) at execute.c:161 
>          stmt = 0x120dbbdc0
>          result = 0
>          func = 0x5581de5e10 "PGAPI_ExecDirect"
>          conn = 0x120f709e0
> #11 0x0000005581dc129c in SQLExecDirect (StatementHandle=0x120dbbdc0, StatementText=0x55930762a8 "SELECT wbts_id FROM
act_wbtsWHERE wbts_id=130", TextLength=-3) at odbcapi.c:364 
>          func = 0x5581def670 "SQLExecDirect"
>          ret = 0
>          stmt = 0x120dbbdc0
>          flag = 1
> #12 0x0000005563d69858 in SQLExecDirect () from /usr/lib64/libodbc.so.2
> No symbol table info available.
> #13 0x00000055631136b4 in db_ExecDirect1 (stmt1=0x5593076250, query=0x55930762a8 "SELECT wbts_id FROM act_wbts WHERE
wbts_id=130")at ../src/db_utilityqx.c:923 
>
> --
> Regards,
> Prakash I.
>
>
> -----Original Message-----
> From: ext Heikki Linnakangas [mailto:hlinnakangas@vmware.com]
> Sent: Monday, June 23, 2014 1:36 PM
> To: Itnal, Prakash (NSN - IN/Bangalore); pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Not sure if this crash is in psql odbc driver?
>
> On 06/23/2014 08:50 AM, Itnal, Prakash (NSN - IN/Bangalore) wrote:
>> Hi,
>>
>> We encountered a crash that points to psql odbc driver. The crash is
>> not at fixed at same point but it always points to psql-odbc driver. It
>> is at same two places shown below. Kindly let me know if this is really
>> an issue in psql code!
>
> Could be, but it's impossible to track it down without more information.
> For starters, if you could try with a debug-enabled build of the driver,
> so that we could see line number information and local variables in the
> backtrace, that would help.
>
> If you can reduce the test to a small self-contained test case that
> reproduces the crash, that would be best. Can you provide more details
> on the application and how it uses the driver? Is it multi-threaded?
> What ODBC functions does it call? What config options are you using?
>
> - Heikki
>


--
- Heikki

(2014/07/21 19:43), Itnal, Prakash (NSN - IN/Bangalore) wrote:
> Hi,
>
> Recently we tested this with debug version of psql-odbc driver. Attached is the backtrace. Due security policies I
havedelete certain sections which are any way not relevant from backtrace. 
>
> ODBC version: Latest ODBC code from trunk
> Postgres server version: 9.1
> Unix ODBC: 2.2.14
> Target Architecture: mips-64
> Scenario: Restart (server and client both running on same HW unit)
>
>
> Below is quick summary from backtrace:
>
>  From backtrace:
> Thread 1 (LWP 7532):
> #0  0x000000555aec5d7c in memcpy () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x000000559b99dd08 in copy_and_convert_field (stmt=0x559c076130, field_type=17, atttypmod=-1,
valuei=0x559c229c90,fCType=-2, precision=0, rgbValue=0x55a7fd7310, cbValueMax=1252, pcbValue=0x55a7fd7298,
pIndicator=0x55a7fd7298)at convert.c:1793 
> .
> .
>           ptr = 0x0

    What's the value of len?

regards.
Hiroshi Inoue

> .
> .
>
>
>  From code:
> 1788                 if (cbValueMax > 0)
> 1789                 {
> 1790                     copy_len = (len > cbValueMax) ? cbValueMax : len;
> 1791
> 1792                     /* Copy the data */
> 1793                     memcpy(rgbValueBindRow, ptr, copy_len);
> 1794
> 1795                     /* Adjust data_left for next time */
> 1796                     if (stmt->current_col >= 0)
> 1797                         pgdc->data_left -= copy_len;
> 1798                 }
>
> Since the ptr is 0x0 (NULL), the memcpy is failed. We are not able to debug it fully since we are not fully competent
withpsqlODBC code base. 
>
> It would be of great help if someone helps to resolve this!
>
> --
> Regards,
> Prakash I.

Hi,

The attached file in previous mail contains full backtrace. Anyway I am printing the frame 0 for quick reference.

738 Thread 1 (LWP 7532):
739 #0  0x000000555aec5d7c in memcpy () from /lib64/libc.so.6
740 No symbol table info available.
742         func = 0x559ba1a808 "copy_and_convert_field"
743         value = 0x559c229c90 ""
744         opts = 0x559c076210
745         gdata = 0x559c0763c8
746         len = 1252
747         copy_len = 1252
748         needbuflen = 0
749         std_time = {infinity = 0, m = 7, d = 16, y = 2014, hh = 0, mm = 0, ss = 0, fr = 0}
750         stmt_t = 1405483185
751         tim = 0x55a7fd6d98
752         tm = {tm_sec = 45, tm_min = 59, tm_hour = 6, tm_mday = 16, tm_mon = 6, tm_year = 114, tm_wday = 3, tm_yday
=196, tm_isdst = 1, tm_gmtoff = 10800, tm_zone = 0x120d04960 "EEST"} 
753         pcbValueOffset = 0
754         rgbValueOffset = 0
755         rgbValueBindRow = 0x55a7fd7310 ""
756         pcbValueBindRow = 0x55a7fd7298
757         pIndicatorBindRow = 0x55a7fd7298
758         ptr = 0x0
759         bind_row = 0
760         bind_size = 0
761         result = 0
762         conn = 0x559c072d30
763         changed = 0
764         text_handling = 0
765         localize_needed = 0
766         neut_str = 0x559c229c90 ""
767         midtemp = {"\000\000\000U\234#oP", '\000' <repeats 11 times>, "\001", '\000' <repeats 11 times>, '\000'
<repeats31 times>} 
768         mtemp_cnt = 0
769         pgdc = 0x559c0763c8
770         wconverted = 0
771         g = {Data1 = 0, Data2 = 0, Data3 = 0, Data4 = "\000\000\000\000\000\000\002"}

--
Regards,
Prakash I.

-----Original Message-----
From: ext Inoue, Hiroshi [mailto:inoue@tpf.co.jp]
Sent: Thursday, July 24, 2014 5:15 AM
To: Itnal, Prakash (NSN - IN/Bangalore)
Cc: ext Heikki Linnakangas; pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Not sure if this crash is in psql odbc driver?

(2014/07/21 19:43), Itnal, Prakash (NSN - IN/Bangalore) wrote:
> Hi,
>
> Recently we tested this with debug version of psql-odbc driver. Attached is the backtrace. Due security policies I
havedelete certain sections which are any way not relevant from backtrace. 
>
> ODBC version: Latest ODBC code from trunk
> Postgres server version: 9.1
> Unix ODBC: 2.2.14
> Target Architecture: mips-64
> Scenario: Restart (server and client both running on same HW unit)
>
>
> Below is quick summary from backtrace:
>
>  From backtrace:
> Thread 1 (LWP 7532):
> #0  0x000000555aec5d7c in memcpy () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x000000559b99dd08 in copy_and_convert_field (stmt=0x559c076130, field_type=17, atttypmod=-1,
valuei=0x559c229c90,fCType=-2, precision=0, rgbValue=0x55a7fd7310, cbValueMax=1252, pcbValue=0x55a7fd7298,
pIndicator=0x55a7fd7298)at convert.c:1793 
> .
> .
>           ptr = 0x0

    What's the value of len?

regards.
Hiroshi Inoue

> .
> .
>
>
>  From code:
> 1788                 if (cbValueMax > 0)
> 1789                 {
> 1790                     copy_len = (len > cbValueMax) ? cbValueMax : len;
> 1791
> 1792                     /* Copy the data */
> 1793                     memcpy(rgbValueBindRow, ptr, copy_len);
> 1794
> 1795                     /* Adjust data_left for next time */
> 1796                     if (stmt->current_col >= 0)
> 1797                         pgdc->data_left -= copy_len;
> 1798                 }
>
> Since the ptr is 0x0 (NULL), the memcpy is failed. We are not able to debug it fully since we are not fully competent
withpsqlODBC code base. 
>
> It would be of great help if someone helps to resolve this!
>
> --
> Regards,
> Prakash I.