Re: Not sure if this crash is in psql odbc driver?

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