Re: I'm having a crashing problem with FreeTDS under OSX

Frediano Ziglio wrote:
> Reading at
> http://developer.apple.com/documentation/Darwin/Reference/Manpages/man3/asprintf.3.html
> it seems that same problem apply also to asprintf/vasprintf. They
> returns pointers malloc-ed with libc but if free is not from libc you
> get heap corruption. 

There is only one free(3) in OS X.  I don't find anything in the pages you
linked to that say anything else.  

I do not think there is a fundamental problem with FreeTDS or malloc/free
on OS X.  I use FreeTDS on OS X without problems.  Others do too, or we'd
have lots of problem reports.  

Daniel is using Ruby, which is written in C.  I downloaded
ruby-1.9.1-p0.tar.gz and checked the sources with cscope.  And guess what?
 It manages its own heap.  See YYMALLOC and e.g. rb_parser_malloc().  And
look at this:

include/ruby/util.h:#define strdup(s) ruby_strdup(s)

Looks suspicious to me.  

Daniel, I have a few suggestions for you.  

1.  Do the ODBC unit tests work?  bsqlodbc?  If, as I expect, these
programs work, the problem is related to Ruby somehow.  

2.  Use nm(1) to see if libtdsobdc references ruby_strdup or similar.  If
so, figure out why.  Perhaps the Ruby ODBC framework includes the Ruby
util.h before building the driver. 

3.  OS X has a rich array of environment variables for tracking heap
allocations.  See also leaks(1) and malloc_history(1).  MallocStackLogging
appears to be your friend here.  

4.  Set a breakpoint  in gdb where strdup is called, and trace into the
call.  See if you land in libc.  See what the malloc debugging tools say
before and after the call.  
While it was a useful diagnostic tool, I emphatically do not think you
need tds_strdup().  The important thing to do is to figure out why strdup
is returning a pointer that free(3) doesn't recognize.  .  

HTH.  

--jkl