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:
>
> --8<---------------cut here---------------start------------->8---
> Thread 4 hit Breakpoint 5, __error (status=0, errnum=0, message=0x5aff78
> "Option %s: Treating date '%s' as %s") at error.c:274
> 274 vfprintf (stderr, message, args);
> (gdb) p stderr
> $6 = (FILE *) 0x608400 <_IO_2_1_stderr_>
> (gdb) p message
> $7 = 0x5aff78 "Option %s: Treating date '%s' as %s"
> (gdb) p args
> No symbol "args" in current context.
> (gdb) down
> Bottom (innermost) frame selected; you cannot go down.
> (gdb) up
> #1 0x000000000042897b in report_textual_dates (args=0x160fb40) at tar.c:1113
> 1113 WARN ((0, 0, _("Option %s: Treating date '%s' as %s"),
> (gdb) s
> __error_internal (status=0, errnum=0, message=0x5aff78 "Option %s: Treating
> date '%s' as %s", args=args@entry=0x160f9f8, mode_flags=mode_flags@entry=0)
> at error.c:242
> 242 res = mbsrtowcs (wmessage, &tmp, len, &st);
> (gdb) s
> 243 if (res != len)
> (gdb) s
> 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.
Samuel
