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

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.
>