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: Daniel Parnell <me AT danielparnell.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>, "James K. Lowden" <jklowden AT freetds.org>
  • Subject: Re: [freetds] I'm having a crashing problem with FreeTDS under OSX
  • Date: Mon, 9 Mar 2009 08:50:49 +1100

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




Archive powered by MHonArc 2.6.24.

Top of Page