Skip to Content.
Sympa Menu

freetds - Re: [freetds] I'm having a crashing problem with FreeTDS under OSX

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] I'm having a crashing problem with FreeTDS under OSX
  • Date: Fri, 6 Mar 2009 00:52:11 -0500

Daniel Parnell wrote:
> here is the first little bit of the stack trace for the first
> crash
> I'm seeing.
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000016
> 0x0010f7fa in free ()
> (gdb) bt
> #0 0x0010f7fa in free ()
> #1 0x02f55c38 in _SQLAllocEnv (phenv=0x812c70) at odbc.c:1353

Bug. Eh. The pointer being freed might not have been allocated, and
isn't zeroed when initialized.

free(ctx->locale->date_fmt);

Locale is allocated by tds_alloc_locale() and initialized by
tds_parse_locale(). Something's a little wrong, because
tds_parse_locale() should find a proper date format string in
locales.conf. In case it doesn't, though, *nothing* initializes the
memory; it's just pointing to random space. A little while later, the
ODBC driver fastidiously frees the tiny string it thinks was allocated,
and you send a message to the list.

I would double-check what's going on with TDSDUMPCONFIG, which should show
a locales.conf being read and the date_fmt being initialized. But this
patch wouldn't do any harm:

RCS file: /cvsroot/freetds/freetds/src/tds/mem.c,v
retrieving revision 1.175.2.2
diff -u -r1.175.2.2 mem.c
--- src/tds/mem.c 5 Nov 2008 14:56:12 -0000 1.175.2.2
+++ src/tds/mem.c 6 Mar 2009 05:49:34 -0000
@@ -656,7 +656,7 @@
{
TDSLOCALE *locale;

- TEST_MALLOC(locale, TDSLOCALE);
+ TEST_CALLOC(locale, TDSLOCALE, 1);
return locale;

Cleanup:

HTH.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page