Re: Problems with ncurses-5.4

[Matt Emmerton]

----- Original Message ----- 
From: "Thomas Dickey" <address@hidden>
To: "Matt Emmerton" <address@hidden>
Cc: <address@hidden>
Sent: Sunday, January 30, 2005 4:58 PM
Subject: Re: Problems with ncurses-5.4


> On Sun, 30 Jan 2005, Matt Emmerton wrote:
>
> >
> > I'm one of the developers of LifeLines (lifelines.sourceforge.net), a
> > genealogy program that uses ncurses.
> >
> > Lately, bunch of distributions that we support have upgraded to
ncurses-5.4,
> > and our code no longer runs as we get segfaults inside of ncurses while
> > calling initscr(), such as this one:
> >
> > #0  0x049e1340 in _nc_unicode_locale () at
> > ../../ncurses/tinfo/lib_setup.c:361
>
> The code looks like this:
>
> NCURSES_EXPORT(int)
> _nc_unicode_locale(void)
> {
>      int result = 0;
> #if HAVE_LANGINFO_CODESET
>      char *env = nl_langinfo(CODESET);
>      result = !strcmp(env, "UTF-8");
>      T(("_nc_unicode_locale(%s) ->%d", env, result));
> #else
>      char *env = _nc_get_locale();
>      if (env != 0) {
>          if (strstr(env, ".UTF-8") != 0) {
>              result = 1;
>              T(("_nc_unicode_locale(%s) ->%d", env, result));
>          }
>      }
> #endif
>      return result;
> }
>
> line 361 in version 1.84 of lib_setup.c would be
>      result = !strcmp(env, "UTF-8");
>
> The manpage for nl_langinfo() states that it returns a pointer to an
> appropriate string, or an "empty string" if no locale applies.  Perhaps
> someone's made it return a null pointer.
>
> > #1  0x049e0279 in _nc_init_acs () at ../../ncurses/tinfo/lib_acs.c:119
> > #2  0x049d07c4 in _nc_setupscreen (slines=24, scolumns=80,
output=0x8605c0)
> > at ../../ncurses/base/lib_set_term.c:388
> > #3  0x049cdf10 in newterm (name=0x0, ofp=0x8605c0, ifp=0x860720) at
> > ../../ncurses/base/lib_newterm.c:146
> > #4  0x049cabff in initscr () at ../../ncurses/base/lib_initscr.c:83
> > #5  0x08053817 in main (argc=1, argv=0xfeff4ac4) at main.c:624
> >
> > The various distributions and versions of ncurses that we've
experimented
> > with are as follows:
> >
> > Mandrake 10.1:    5.4.20040208 / WORKING (sources from gnu.org)
> > Debian-stable:    5.4.20040320 / WORKING
> > Mandrake 10.1:    5.4.20040529 / BROKEN (RPMs that ship with Mandrake)
> > RH Fedora Core 3:    5.4.20040724 / BROKEN
> >
> > It would appear that something changed between March and May of 2004
that is
> > causing bad things to happen, but I've gone through the code and the
vendor
> > patch sets and can't seem to find anything obvious.
>
> There were some changes to _nc_get_locale() in late March.  However,
> since I can reproduce this problem, it's simpler to debug it -
> nl_langinfo() is indeed returning a null pointer rather than a
> pointer to an empty string.  I'll add a check for that.
>
> > One thing that we have found is that a simple test program containing
one
> > object file that links with ncurses works fine, but as soon as a second
> > object is linked, we get segfaults.  We've also had mixed results
linking
> > with a static ncurses versus a dynamic ncurses.  Puzzling to say the
> > least -- especially since these three distributions are using different
> > combinatons of gcc and bintools.
> >
> > Has anyone seen this before?  Does anyone have any ideas/advise to help
us
> > debug this further?
>
> I built a copy of it, ran it as you suggested - first with valgrind, but
> that only told me that there was a null pointer.  Compiling ncurses and
> linking against the corresponding libncurses_g.a let the debugger show
> that the env variable indeed is null.
>
> However, a quick check shows that both Linux and Solaris don't return a
> null pointer:
>
> #include <locale.h>
> #include <stdio.h>
> #include <langinfo.h>
>
> int main()
> {
>          char *p;
>
>          // (setlocale doesn't seem to affect the null/nonnull aspect)
>   // setlocale(LC_ALL, "");
>          p = nl_langinfo(CODESET);
>          printf ("%p\n", p);
>          return 0;
> }
>
> I see that nl_langinfo() is actually within lifelines:
>
>   lifelines-3.0.37.2/src/arch/langinfo.c
>
> so (while having a null pointer check in lib_setup.c is not a bad idea),
> the bug is actually in lifelines

I saw that we don't have a configure check for nl_langinfo(), so we're using
our (flawed) implementation even on platforms that support it.  (This was
the case on Mandrake 10.1.)

I manually removed our version of langinfo.c and rebuilt LL on Mandrake
10.1, and it's now working properly.

Thanks for the help!

--
Matt Emmerton