Re: segmentation fault inside waddch_literal()

[Thomas Dickey]

On Sat, Jul 17, 2021 at 08:21:03PM +0900, Tetsuo Handa wrote:
> On 2021/07/16 14:41, Tetsuo Handa wrote:
> > My program (which runs on Linux) is built with symbol _GNU_SOURCE defined
> > in order to make Unix/Linux specific extensions visible. As a result,
> > curses.h is #include'd with symbol _GNU_SOURCE defined.
> > 
> > When this sample is built with -D_GNU_SOURCE, segmentation fault happens.
> > When this sample is built without -D_GNU_SOURCE, it seems to work fine.
> > I have no idea why this makes run-time difference.

The curses.h header file is almost the same for the normal and wide-character
configurations.  However, there's a problem reported here:

20161210
        + add configure script option --disable-wattr-macros for use in cases
          where one wants to use the same headers for ncurses5/ncurses6
          development, by suppressing the wattr* macros which differ due to
          the introduction of extended colors (prompted by comments in
          Debian #230990, Redhat #1270534).

I was reminded of this in January, made a to-do note that
changing the default would be helpful -- for ncurses 6.3, of course.

> I compared string data within sample1 built with _GNU_SOURCE and without 
> _GNU_SOURCE,
> and noticed that there are several differences.
> 
>   $ diff strings-built-with-_GNU_SOURCE strings-built-without-_GNU_SOURCE 
>   13d12
>   < _bkgrnd
>   19d17
>   < cchar_t
>   21d18
>   < chars
>   77d73
>   < ext_color
>   129,130c125
>   < long double
>   < long long int
>   ---
>   > long int
>   180d174
>   < stddef.h
>   192d185
>   < /usr/lib/gcc/x86_64-mageia-linux-gnu/10/include
>   199d191
>   < wchar_t
> 
> It seems that the cause of this problem is "#include <curses.h>" with
> symbol _GNU_SOURCE defined causes NCURSES_WIDECHAR to be defined as 1
> because
> 
>   defined(_XOPEN_SOURCE_EXTENDED) || (defined(_XOPEN_SOURCE) && 
> (_XOPEN_SOURCE - 0 >= 500))
> 
> is evaluated as true, and the disagreement of memory layout of data structure
> definitions between this program and the library cannot be detected until
> this problem occurs.
> 
> It seems that how NCURSES_WIDECHAR is defined has changed in v5_9_20111029.

That was here (after ncurses 6.0 in August 2015):

20151212
        + improve CF_XOPEN_CURSES macro used in test/configure, to define as
          needed NCURSES_WIDECHAR for platforms where _XOPEN_SOURCE_EXTENDED
          does not work.  Also modified the test program to ensure that if
          building with ncurses, that the cchar_t type is checked, since that
          normally is since 20111030 ifdef'd depending on this test.
 
However, I no longer use "_GNU_SOURCE" if "_DEFAULT_SOURCE" works:

20160806
        + improve CF_GNU_SOURCE configure macro to optionally define
          _DEFAULT_SOURCE work around a nuisance in recent glibc releases.

> ----------
> @@ -151,15 +151,21 @@ typedef unsigned @cf_cv_typeof_mmask_t@ mmask_t;
>  
>  /*
>   * With XPG4, you must define _XOPEN_SOURCE_EXTENDED, it is redundant (or
> - * conflicting) when _XOPEN_SOURCE is 500 or greater.
> + * conflicting) when _XOPEN_SOURCE is 500 or greater.  If NCURSES_WIDECHAR is
> + * not already defined, e.g., if the platform relies upon nonstandard feature
> + * test macros, define it at this point if the standard feature test macros
> + * indicate that it should be defined.
>   */
> -#undef NCURSES_WIDECHAR
> -#if defined(_XOPEN_SOURCE_EXTENDED) || defined(_XPG5)
> -#define NCURSES_WIDECHAR
> +#ifndef NCURSES_WIDECHAR
> +#if defined(_XOPEN_SOURCE_EXTENDED) || (defined(_XOPEN_SOURCE) && 
> (_XOPEN_SOURCE - 0 >= 500))
> +#define NCURSES_WIDECHAR 1
> +#else
> +#define NCURSES_WIDECHAR 0
>  #endif

sure: ncurses attempts to use the POSIX definitions, and for platforms
where the developers don't care much about that, it's possible to set
NCURSES_WIDECHAR.

In a quick check, defining _DEFAULT_SOURCE doesn't turn on the unwanted
definitions that _GNU_SOURCE does.  Of course, over time the feature's
likely to degrade.  _GNU_SOURCE used to be usable.

> +#endif /* NCURSES_WIDECHAR */
>  
>  #include <stdarg.h>    /* we need va_list */
> -#ifdef NCURSES_WIDECHAR
> +#if NCURSES_WIDECHAR
>  #include <stddef.h>    /* we want wchar_t */
>  #endif
>  
> ----------
> 
> Building like
> 
>   gcc -Wall -O0 -g -DCOLOR_ON -D_GNU_SOURCE -DNCURSES_WIDECHAR=0 -o sample1 
> sample1.c -lncurses -ltinfo 
> 
> avoids this problem (i.e. behaves as if _GNU_SOURCE is not defined) for 
> Mageia 8 environment.
> But I don't know whether I can add -DNCURSES_WIDECHAR=0 for other Linux 
> environments.

It should work :-)

> How can I know what value my program should specify for NCURSES_WIDECHAR ?

That clump of ifdef's won't change until a new problem arises,
e.g., someone making _DEFAULT_SOURCE as badly broken as _GNU_SOURCE.

Alternatively, you could use -DNCURSES_WATTR_MACROS=0
(offhand, both fixes work with ncurses 6.1 and up).

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature