Skip to Content.
Sympa Menu

freetds - Re: [freetds] segmentation fault - FreeTDS 0.91RC2 + pymssql HG tip

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] segmentation fault - FreeTDS 0.91RC2 + pymssql HG tip
  • Date: Wed, 17 Aug 2011 09:44:24 +0200

2011/8/15 James Burry <jburry AT gmail.com>:
> Good day everyone. I am seeing the following segmentation fault with a
> FreeTDS 0.91RC2 + pymssql HG tip setup. I originally started trying
> these newer versions to try to get around a similar segfault with
> FreeTDS 0.82 + pymssql 1.02. The database is mssql 2005. I see this
> segfault about every 3 days or so.
>

After 3 days? Perhaps the best solution is:
- compile FreeTDS/pymssql with debugging informations (this does not
mean no optimization, just do not strip executable/shared objects)
- enable core generations
- wait core
- use gdb/whatever to do a "full bt" (gdb syntax for verbose backtrace).

> Start.py[24106]: segfault at 0 ip b718f6b6 sp bfaf8670 error 6 in
> _mssql.so[b7189000+2c000]
> python[12549]: segfault at 0 ip b70df6c8 sp bfcf5ad0 error 6 in
> _mssql.so[b70d9000+2c000]
>
> If anyone has some input on this, it would be greatly appreciated. I
> would be happy to try any particular log settings to capture
> additional information.
>
> Some settings from freetds.conf :
>
> <<
>
> [global]
>        # TDS protocol version
> ;       tds version = 7.2
>        tds version = 8.0
>        port=1433
>
>        # Whether to write a TDSDUMP file for diagnostic purposes
>        # (setting this to /tmp is insecure on a multi-user system)
> ;       dump file = /tmp/freetds.log
> ; see http://www.freetds.org/userguide/freetdsconf.htm for flags
> ;       debug flags = 0x0006
>
>        # Command and connection timeouts
> ;       timeout = 10
> ;       connect timeout = 10
>
>        # If you get out-of-memory errors, it may mean that your client
>        # is trying to allocate a huge buffer for a TEXT field.
>        # Try setting 'text size' to a more reasonable limit
>        text size = 64512
>
>>>
>
>
> James

Frediano




Archive powered by MHonArc 2.6.24.

Top of Page