FreeTDS Development Group

[Daniel Parnell <me AT danielparnell.com>]

I added some code to log the address allocated when date_fmt is set in  
tds/locale.c and to again display the value in odbc.c and they seem to  
be the same

new locale->date_fmt = 0x205d50 - %b %e %Y %I:%M:%S:%z%p
free ctx->locale->date_fmt: 0x205d50 - %b %e %Y %I:%M:%S:%z%p

It's really strange!  It's almost as if the value being returned by  
strdup is bad.

Daniel

On 08/03/2009, at 3:10 AM, James K. Lowden wrote:

> Hi Daniel,
>
> > I put some printfs in around the free and it appears to be pointing  
> > to
> > a valid date format.
>
> That's interesting. I don't know anything about OS X heap management  
> or
> how an executable is arranged in memory.  My instinct says 0x16 is  
> too low
> for the heap, and free(3) seems to agree.
>
> Looking at the code, there are only a few places where data_fmt is  
> set,
> all of them output of calloc(3) or strdup(3).  I'm sure you see the  
> same
> yourself.  I don't see how FreeTDS could have set that pointer to  
> anything
> that can't be freed.
>
> > If I just comment out the free it then seems to fail on the next free
> > the code hits (and of course leaks;)
> > It is almost as if the heap is getting corrupted
>
> The OS X tool vmmap(1) might be of some help here.  I haven't used it
> myself but it's in the right neighborhood.
>
> I still suspect someone somewhere is trimming off the top 4 bytes of a
> pointer and then having a party.
>
> HTH.
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds