FreeTDS Development Group

[Daniel Parnell <me AT danielparnell.com>]

Hi James,

I uncompressed a fresh copy of FreeTDS and ran the odbc unit tests, 10  
of which failed, although I suspect most of them could be because of  
SQL Server 2008.
There were two bus errors however.

Please find attached a copy of the output

I also had a poke around with nm and as far as I can see everything  
should be working correctly.
There isn't anything obviously wrong that I can see.

Incidentally I'm running ruby 1.8.6 (Enterprise Ruby actually).   
Initially I tried using the build in ruby that comes with OS X and  
when I got problems I thought I'd somehow messed up the OS X ruby  
installation.

The really bizarre thing is that I've set up 5 or so Macs over the  
last couple of years and never hit anything like this.
Still, it's working now...

Daniel

Attachment: check.out.gz
Description: GNU Zip compressed data

On 09/03/2009, at 7:13 AM, James K. Lowden wrote:

> 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds