FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

valgrind is your friend :)

I bet is related to a conflict of SQLWCHAR ABI

freddy77

2011/4/8 Randy Syring <randy AT rcs-comp.com>:
> 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
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>