[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with ncurses-5.4

From: Thomas Dickey
Subject: Re: Problems with ncurses-5.4
Date: Sun, 30 Jan 2005 16:58:05 -0500 (EST)

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

The code looks like this:

    int result = 0;
    char *env = nl_langinfo(CODESET);
    result = !strcmp(env, "UTF-8");
    T(("_nc_unicode_locale(%s) ->%d", env, result));
    char *env = _nc_get_locale();
    if (env != 0) {
        if (strstr(env, ".UTF-8") != 0) {
            result = 1;
            T(("_nc_unicode_locale(%s) ->%d", env, result));
    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
#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:


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]