bug-gnulib
[Top][All Lists]
Advanced

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

Re: Test suite failure for gettext's gnulib on ARMv7HL


From: Kamil Dudka
Subject: Re: Test suite failure for gettext's gnulib on ARMv7HL
Date: Tue, 04 Aug 2020 09:36:51 +0200

On Tuesday, August 4, 2020 2:10:46 AM CEST Bruno Haible wrote:
> Kamil Dudka wrote:
> > Yes, the `ASSERT (msg3 == msg4 || STREQ (msg3, str3))` check is failing 
here:
> >     https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-> 
> > >     strerror_r.c;h=b11d6fd9#l170
> The ASSERT means "either msg3 has been clobbered by the strerror (1729576)
> call, or it has been left unmodified". If it fails, something is happening
> that we don't understand.

I know what the ASSERT means.  But the documentation of strerror() does not 
say that such an assertion is always satisfied, does it?

> Can you, in an interactive gdb session, set a hardware watchpoint on the
> value of msg3?

I was not able to allocate the appropriate HW when I was debugging the issue 
two weeks ago.  They key question is: Does any SW we care about rely on the 
undocumented assumption that calls to strerror() modify previously returned 
strings only by overwriting them with the last returned string?

> One of these lines must modify its contents. The question is: where?
> 
>     msg4 = strerror (1729576);

I believe it is this ^^^ line.

Kamil

>     ASSERT (msg4);
>     str4 = strdup (msg4);
>     ASSERT (str4);
> 
>     strerror_r (EACCES, buf, sizeof buf);
>     strerror_r (-5, buf, sizeof buf);
> 
> Bruno





reply via email to

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