Re: [libodbcxx-devel] segmentation fault help please

[Simon W. <si...@gi...>]

On 06/08/2012 09:48 AM, Buck Huppmann wrote:
>
> On Wed, Jun 06, 2012 at 08:01:48PM -0900, Simon Walter wrote:
>>
>> On 06/07/2012 01:34 PM, Buck wrote:
>>>
>>> looks like the ``leak'' is in the C library's getpwuid(), which allocates
>>> a ``static buffer'' for the returned struct passwd, no?  if you're suggest-
>>> ing that libodbc should call (the reentrant, and non-static struct passwd-
>>> returning) getpwuid_r() directly, then you need to talk to the unixODBC
>>> folks.  but if you're saying GNU libc's getpwuid() should clean up at exit
>>> or something, that's a different political arena
>>>
>>> anyways, thanks for sussing out the correct release semantics for the var-
>>> ious libodbc++ objects
>>
>> Hi Buck,
>>
>> Thanks for setting me straight. I'm relatively new to c/c++ development
>> on nix platforms and wasn't sure what I was seeing. I'm kind of
>> surprised/annoyed that things are in this state - at least on Debian. It
>> affects multi-threaded applications quite a bit. If I can't get them to
>> sort it out, I'll have to steer clear of unixODBC for now. Or maybe use
>> a different OS.
>
> Dang.  5,192 bytes over the lifetime of a process that get reclaimed at
> process exit is that big a price to pay?
>
> cause, at least from glancing at
>
> http://sourceware.org/git/?p=glibc.git;a=blob;f=nss/getXXbyYY.c;h=336676ad555a0e7905318a11bbd0f9fc57fe8793;hb=HEAD
>
> it seems to me that it's 1 buffer per process and not per thread, so you
> can spin up as many threads as you like and not ever leak more than that,
> whereas i'd wager that another OS' process/thread/related kernel/subsys-
> tem's object's overhead is gonna have a bigger footprint than that


Sorry I've been sick with some kind of food poisoning. Better now.

I must have sent the wrong trace. When using a MySQL db via ODBC, I was 
losing 4 bytes for every connect and disconnect. I built the MySQL ODBC 
driver from source, and it seems to crash less. It still crashes 
occasionally. It seems the problem is primarily with the driver. I'm 
going to try this on another platform - currently Debian 6.

Cheers,

Simon

-- 
simonsmicrophone.com