Samuel Thibault writes:

Hi Samuel,

> jann...@gnu.org, le ven. 15 nov. 2024 17:01:57 +0100, a ecrit:
>> This looks like a pretty simple place, but gnulib error reporting functions
>> are a bit tricky:
>> Thread 4 received signal SIGSEGV, Segmentation fault.
>
> Sounds odd indeed to see a comparison pose problem :) Perhaps call disas
> to get the asm and use si instead of s, just before the segv, to
> pinpoint exactly which instruction poses problem.
>
>> I don't understand how single-stepping on vfprintf (lne 274) brings me
>> to line 234, which is inside "#if _LIBC" code.
>
> In your log it's "if (res != len)" that segfaults. But with
> optimizations, it's hard for gdb to provide correct information, better
> switch to asm.

So, I took another approach.  I minimized the tar archive, keeping only
gnulib and a simple main: bug.c that shows the same hanging behaviour
when called with one command line argument.  See attached.

It turns out that, although there is a gnulib gnu/error.c distributed,
it is not being compiled.  gnu/Makefile.am has

--8<---------------cut here---------------start------------->8---
EXTRA_DIST += error.c error.h
--8<---------------cut here---------------end--------------->8---

Interestingly, gnu/error.h has (#warning instrumentation mine):

--8<---------------cut here---------------start------------->8---
extern void error (int __status, int __errnum, const char *__format, ...)
#if GNULIB_VFPRINTF_POSIX
  #warning POSIX
     _GL_ATTRIBUTE_FORMAT ((_GL_ATTRIBUTE_SPEC_PRINTF_STANDARD, 3, 4))
#else
  #warning NOT-POSIX
     _GL_ATTRIBUTE_FORMAT ((_GL_ATTRIBUTE_SPEC_PRINTF_SYSTEM, 3, 4))
#endif
     ;
--8<---------------cut here---------------end--------------->8---

Which variant to choose is not determined by configure, it has been
hardcoded in gnulib's m4/stdio.m4:

  GNULIB_VFPRINTF_POSIX=0;       AC_SUBST([GNULIB_VFPRINTF_POSIX])

and now you can guess it: we are linking against these functions from
glibc and gnulib chose wrong (or possibly glibc was compiled using the
POSIX version and should not have been??).

Anyway when using the POSIX variant:

--8<---------------cut here---------------start------------->8---
#if 1
#define GNULIB_VFPRINTF_POSIX 1 // fixes the static hang
#else
#define GNULIB_VFPRINTF_POSIX 0 // the gnulib setting: hangs
#endif
#include "error.h"
--8<---------------cut here---------------end--------------->8---

running "./bug foo" just works.

As an extra, when compiling gnu/error.c into libgnu_a by adding:

--8<---------------cut here---------------start------------->8---
libgnu_a_SOURCES += error.c
--8<---------------cut here---------------end--------------->8---

and using

--8<---------------cut here---------------start------------->8---
#define error bug_error
#define error_tail bug_error_tail
--8<---------------cut here---------------end--------------->8---

to be sure not to use the glibc variants, both the POSIX and NOT-POSIX
versions work.

Still not sure how this gnulib tricksery is supposed to work, and why
POSIX and NOT-POSIX variants get combined.  Thoughts?

Greetings,
Janneke

Attachment: bug.c
Description: Binary data

-- 
Janneke Nieuwenhuizen <jann...@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Reply via email to