[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ncurses-bug
Subject:    Re: [MacOS X] ncurses 5.7 and ptmalloc3
From:       Thomas Dickey <dickey () his ! com>
Date:       2010-05-10 20:39:24
Message-ID: 20100510163019.H63741 () mail101 ! his ! com
[Download RAW message or body]

On Mon, 10 May 2010, BERTRAND Joel wrote:

> Thomas Dickey a écrit :
>> On Sat, 8 May 2010, Joel Bertrand wrote:
>> 
>>> Hello,
>>> 
>>> I have found a bug in ncurses 5.7 that only occurs on MacOS X (10.5.6
>>> x86) when ncurses is linked with ptmalloc3.
>>> For some reasons I have to use ptmalloc3 in a portable program that
>>> run fine on several Unix (NetBSD, FreeBSD, Solaris, Linux) and crashes
>>> on MacOS X. I have bissected to find a minimal example that reproduces
>>> the bug:
>> 
>>> From the traceback, it seems to be related to the hashed-database option,
>> which normally is not used on the other platforms (though it can be).
>> I'll take a look to see if I can reproduce this (thanks).
>
> 	I think I have found... On MacOS X strdup is statically linked 
> against malloc(). If you try to use another allocator, you have to use your 
> own strdup(). For example, with ptmalloc3, it could be :

hmm...  The configure script does try to check if strdup is available, and 
will declare its own if not.  I'd assume that it would get some symbol 
conflict if it has two flavors of malloc available for linking.

>
> char * strdup(const char *s) {
>     char * res = public_mALLOc(strlen(s)+1);
>     if (res)
>     	strcpy(res, s);
>     return res;
> }
>
> and ncurses runs fine with ptmalloc.
>
> 	Regards,
>
> 	JKB
>

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

_______________________________________________
Bug-ncurses mailing list
Bug-ncurses@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-ncurses


[prev in list] [next in list] [prev in thread] [next in thread]