Re: Problems with ncurses-5.4

[Thomas Dickey]

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

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