[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