Re: FreeTDS Crash: free(): invalid next size (fast)

What options should I run valgrind with?

--------------------------------------
Randy Syring
Intelicom
Direct: 502-276-0459
Office: 502-212-9913

For the wages of sin is death, but the
free gift of God is eternal life in
Christ Jesus our Lord (Rom 6:23)


On 04/08/2011 10:58 AM, Frediano Ziglio wrote:
> valgrind is your friend :)
>
> I bet is related to a conflict of SQLWCHAR ABI
>
> freddy77
>
> 2011/4/8 Randy Syring<[email protected]>:
>> FYI, one of the original links I posted was wrong, the correct one is:
>>
>> http://rcs-comp.com/tmp/freetds-082-1build6.log
>>
>> But, I am kind of stumped at this point.  The simple test case filed on
>> the pyodbc issue was "fixed" by using a CVS version of FreeTDS and
>> ClientCharset=UTF-8.  But, I am still getting crashes when running my
>> unit tests for my web application with SQLAlchemy + pyodbc.
>>
>> The last part of the dump file, before the crash, is:
>>
>> token.c:554:processing result tokens.  marker is  ff(DONEINPROC)
>> token.c:2335:tds_process_end: more_results = 1
>>          was_cancelled = 0
>>          error = 0
>>          done_count_valid = 1
>> token.c:2366:                rows_affected = 1
>> util.c:156:Changed query state from READING to PENDING
>> odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 1
>> odbc.c:3535:    result_type=4054, TDS_DONE_COUNT=10, TDS_DONE_ERROR=0
>> odbc.c:3599:odbc_process_tokens: processed TDS_DONEINPROC_RESULT
>> odbc.c:3374:_SQLExecute: odbc_process_tokens returned result_type 4054
>> token.c:539:tds_process_tokens(0x36fffa0, 0x7fff573205ac,
>> 0x7fff573205a8, 0x6914)
>> util.c:156:Changed query state from PENDING to READING
>> token.c:554:processing result tokens.  marker is  79(RETURNSTATUS)
>> token.c:554:processing result tokens.  marker is  ac(PARAM)
>> token.c:611:processing parameters for sp 13
>> token.c:613:calling tds_process_param_result
>> token.c:1243:tds_process_param_result(0x36fffa0, 0x7fff57320528)
>> token.c:1587:tds_get_data_info(0x36fffa0, 0x3a16b70, 1) [for parameter]
>> token.c:1650:processing result. type = 38(integer-null), varint_size 1
>> token.c:1655:processing result. column_size 4
>> token.c:2045:tds_get_data: type 38, varint size 1
>> token.c:2106:tds_get_data(): wire column size is 4
>> log.c:493:type integer-null has value 65
>> token.c:617:1 hidden return parameters
>> token.c:554:processing result tokens.  marker is  fe(DONEPROC)
>> token.c:2335:tds_process_end: more_results = 0
>>          was_cancelled = 0
>>          error = 0
>>          done_count_valid = 0
>> token.c:2351:tds_process_end() state set to TDS_IDLE
>> util.c:156:Changed query state from READING to IDLE
>> token.c:2366:                rows_affected = 0
>> util.c:104:logic error: cannot change query state from IDLE to PENDING
>> odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 1
>> odbc.c:3535:    result_type=4053, TDS_DONE_COUNT=0, TDS_DONE_ERROR=0
>> odbc.c:3578:odbc_process_tokens: processed TDS_DONEPROC_RESULT
>> token.c:539:tds_process_tokens(0x36fffa0, 0x7fff573205ac,
>> 0x7fff573205a8, 0x26914)
>> token.c:542:tds_process_tokens() state is COMPLETED
>> odbc.c:3534:odbc_process_tokens: tds_process_tokens returned 2
>> odbc.c:3535:    result_type=4052, TDS_DONE_COUNT=0, TDS_DONE_ERROR=0
>> odbc.c:3374:_SQLExecute: odbc_process_tokens returned result_type 4046
>> odbc.c:3519:SQLExecute returns SQL_SUCCESS
>> odbc.c:4154:SQLFreeStmt(0x381e960, 3)
>> odbc.c:4075:_SQLFreeStmt(0x381e960, 3, 0)
>>
>> Next thing I see on the console is:
>>
>> free(): invalid next size (fast): 0x00000000038a3d60 ***
>>
>> I'm just not sure where to go from here.  I'm willing to do more work to
>> help figure out where the problem is, just let me know what you would
>> like to see.
>>
>> Thanks.
>>
>> --------------------------------------
>> Randy Syring
>> Intelicom
>> Direct: 502-276-0459
>> Office: 502-212-9913
>>
>> For the wages of sin is death, but the
>> free gift of God is eternal life in
>> Christ Jesus our Lord (Rom 6:23)
>>
>>
>> On 04/07/2011 03:02 PM, Randy Syring wrote:
>>> I went ahead and narrowed down my test case and submitted the report
>>> to pyodbc.  I suspect FreeTDS is also related, but I could be wrong.
>>> I just can't get any lower level than pyodbc to be able to rule that
>>> out.  A TDS dump and very simple python script to reproduce the
>>> problem are attached to the pyodbc issue:
>>>
>>> http://code.google.com/p/pyodbc/issues/detail?id=170
>>>
>>> --------------------------------------
>>> Randy Syring
>>> Intelicom
>>> Direct: 502-276-0459
>>> Office: 502-212-9913
>>>
>>> For the wages of sin is death, but the
>>> free gift of God is eternal life in
>>> Christ Jesus our Lord (Rom 6:23)
>>>
>>>
>>> On 04/07/2011 11:07 AM, Randy Syring wrote:
>>>> My platform:
>>>>
>>>> Ubuntu 10.04
>>>> Python 2.6.5
>>>> UnixODBC 2.2.11-21
>>>> pyodbc 2.1.8
>>>> SQLAlchemy 0.6.6
>>>>
>>>> I can run simple tests scripts without a problem.  However, I have
>>>> experienced some kind of crash doing some unit tests on a Python web
>>>> application.
>>>>
>>>> The error appears with both the FreeTDS version that ships with my
>>>> distro (0.82-1build6) as well as a CVS version I compiled myself.
>>>>
>>>> Here is the error in context of some SQLAlchemy debugging output:
>>>>
>>>>> 2011-04-07 10:48:42,514 INFO sqlalchemy.engine.base.Engine.0x...a350
>>>>> SELECT auth_users.id AS auth_users_id, auth_users.createdts AS
>>>>> auth_users_createdts, auth_users.updatedts AS auth_users_updatedts,
>>>>> auth_users.username AS auth_users_username,
>>>>> auth_users.username_inactive AS auth_users_username_inactive,
>>>>> auth_users.authsrc_uid AS auth_users_authsrc_uid,
>>>>> auth_users.alternate_uid AS auth_users_alternate_uid,
>>>>> auth_users.name_first AS auth_users_name_first,
>>>>> auth_users.name_middle AS auth_users_name_middle,
>>>>> auth_users.name_last AS auth_users_name_last, auth_users.phone AS
>>>>> auth_users_phone, auth_users.email AS auth_users_email,
>>>>> auth_users.inactive_flag AS auth_users_inactive_flag,
>>>>> auth_users.inactive_date AS auth_users_inactive_date,
>>>>> auth_users.password_expires AS auth_users_password_expires,
>>>>> auth_users.wfh_flag AS auth_users_wfh_flag, auth_users.wfh_ca_key AS
>>>>> auth_users_wfh_ca_key, auth_users.wfh_ext_reason AS
>>>>> auth_users_wfh_ext_reason, auth_users.wfh_ext_url AS
>>>>> auth_users_wfh_ext_url, auth_users.wfh_ext_link_text AS
>>>>> auth_users_wfh_ext_link_text, auth_users.auth_source_id AS
>>>>> auth_users_auth_source_id
>>>>> FROM auth_users
>>>>> WHERE auth_users.id = ?
>>>>> 2011-04-07 10:48:42,514 INFO sqlalchemy.engine.base.Engine.0x...a350
>>>>> (1,)
>>>>> 2011-04-07 10:48:42,527 INFO sqlalchemy.engine.base.Engine.0x...a350
>>>>> INSERT INTO corporate_sessions (createdts, updatedts, id, hits,
>>>>> relatedip, user_id) VALUES (?, ?, ?, ?, ?, ?)
>>>>> 2011-04-07 10:48:42,528 INFO sqlalchemy.engine.base.Engine.0x...a350
>>>>> (datetime.datetime(2011, 4, 7, 10, 48, 42, 527866), None,
>>>>> u'd2f8bb5f5w7njUnTDy0s', 0, '10.121.113.107', 1)
>>>>> *** glibc detected ***
>>>>> /home/rsyring/dev/customers/pai/paiauth-venv/bin/python: free():
>>>>> invalid next size (fast): 0x0000000004029b40 ***
>>>>> free(): invalid next size (fast): 0x0000000004029b40 ***
>>>> I then have to kill the process.
>>>>
>>>> The TDS dumps are here:
>>>>
>>>> http://rcs-comp.com/tmp/freetds-091CVS.log
>>>> http://rcs-comp.com/tmp/freetds-082.log
>>>>
>>>> I haven't taken the time to try and narrow down the test case because
>>>> I am hoping the dumps will be sufficient to track down the problem.
>>>> However, if needed, I can try to do that, its just going to be
>>>> difficult b/c its buried in test setup.
>>>>
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds