GNU bug report logs -
#28666
sed 4.2.2 testsuite binary3 test never returns on powerpc64-unknown-linux-gnu
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28666 in the body.
You can then email your comments to 28666 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-sed <at> gnu.org
:
bug#28666
; Package
sed
.
(Mon, 02 Oct 2017 02:08:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dennis Clarke <dclarke <at> blastwave.org>
:
New bug report received and forwarded. Copy sent to
bug-sed <at> gnu.org
.
(Mon, 02 Oct 2017 02:08:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
System is a Debian 8.8 powerpc64 type system on a PowerMac G5 and the
test phase of sed 4.2.2 becomes "wedged" in test binary3 with 100% cpu
usage on a single core. Waited for 2 hours however it never returns.
Is there a way to run this as a single isolated test?
I see this ....
.
.
.
XFAIL: utf8-4
PASS: badenc
PASS: inplace-hold
PASS: brackets
PASS: amp-escape
PASS: help
PASS: version
PASS: file
PASS: quiet
PASS: factor
^C
ppc64_deb8_$ ps -ef | grep "sed"
root 595 1 0 Aug27 ? 00:00:00 /usr/sbin/cups-browsed
dclarke 8794 1766 0 19:30 pts/1 00:00:00 tee
../sed-4.2.2_linux_3.16.0-4-
dclarke 10796 10792 0 19:30 pts/1 00:00:00 /usr/local/bin/gmake
SED=../sed/
dclarke 10797 10796 0 19:30 pts/1 00:00:00 /bin/sh -c LC_ALL=C
../sed/sed
dclarke 10798 10797 99 19:30 pts/1 00:04:46 ../sed/sed -n -f
./binary3.sed
dclarke 10803 1671 0 19:35 pts/0 00:00:00 grep sed
ppc64_deb8_$
Waited and waited. Never returns.
Dennis Clarke
Information forwarded
to
bug-sed <at> gnu.org
:
bug#28666
; Package
sed
.
(Mon, 02 Oct 2017 02:29:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 28666 <at> debbugs.gnu.org (full text, mbox):
I looked into the binary3 test a bit and tried this manually :
deb8_ppc64$
deb8_ppc64$ LC_ALL=C ../sed/sed -n -f ./binary3.sed < binary.inp |
LC_ALL=C tr -d \\r > binary3.out_manual
It just runs endlessly and never returns.
Not sure what data to add in here.
Information forwarded
to
bug-sed <at> gnu.org
:
bug#28666
; Package
sed
.
(Mon, 02 Oct 2017 20:00:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 28666 <at> debbugs.gnu.org (full text, mbox):
On Sun, Oct 1, 2017 at 7:06 PM, Dennis Clarke <dclarke <at> blastwave.org> wrote:
>
> System is a Debian 8.8 powerpc64 type system on a PowerMac G5 and the
> test phase of sed 4.2.2 becomes "wedged" in test binary3 with 100% cpu
> usage on a single core. Waited for 2 hours however it never returns.
>
> Is there a way to run this as a single isolated test?
>
> I see this ....
>
> .
> .
> .
> XFAIL: utf8-4
> PASS: badenc
> PASS: inplace-hold
> PASS: brackets
> PASS: amp-escape
> PASS: help
> PASS: version
> PASS: file
> PASS: quiet
> PASS: factor
> ^C
>
>
> ppc64_deb8_$ ps -ef | grep "sed"
> root 595 1 0 Aug27 ? 00:00:00 /usr/sbin/cups-browsed
> dclarke 8794 1766 0 19:30 pts/1 00:00:00 tee
> ../sed-4.2.2_linux_3.16.0-4-
> dclarke 10796 10792 0 19:30 pts/1 00:00:00 /usr/local/bin/gmake
> SED=../sed/
> dclarke 10797 10796 0 19:30 pts/1 00:00:00 /bin/sh -c LC_ALL=C
> ../sed/sed
> dclarke 10798 10797 99 19:30 pts/1 00:04:46 ../sed/sed -n -f
> ./binary3.sed
> dclarke 10803 1671 0 19:35 pts/0 00:00:00 grep sed
> ppc64_deb8_$
>
>
> Waited and waited. Never returns.
Thank you for the report, and especially for testing on a less-common
architecture.
Would you please try again but with the latest release: sed-4.4?
There were a lot of fixes between the version you used and 4.4.
Here's the announcement for sed-4.4:
https://savannah.gnu.org/forum/forum.php?forum_id=8793
Information forwarded
to
bug-sed <at> gnu.org
:
bug#28666
; Package
sed
.
(Wed, 04 Oct 2017 15:16:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 28666 <at> debbugs.gnu.org (full text, mbox):
On Sun, Oct 1, 2017 at 7:28 PM, Dennis Clarke <dclarke <at> blastwave.org> wrote:
> I looked into the binary3 test a bit and tried this manually :
>
> deb8_ppc64$
> deb8_ppc64$ LC_ALL=C ../sed/sed -n -f ./binary3.sed < binary.inp | LC_ALL=C
> tr -d \\r > binary3.out_manual
>
> It just runs endlessly and never returns.
>
> Not sure what data to add in here.
Thank you for the details. I presume this is with the latest?
Does it also infloop if you remove the output pipe:
LC_ALL=C ../sed/sed -n -f ./binary3.sed < binary.inp > out
Can you run it via gdb and hit ^C then see where/why it's looping?
LC_ALL=C gdb --args ../sed/sed
to run it under gdb, do this:
(gdb) run -n -f ./binary3.sed < binary.inp
Information forwarded
to
bug-sed <at> gnu.org
:
bug#28666
; Package
sed
.
(Wed, 04 Oct 2017 18:27:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 28666 <at> debbugs.gnu.org (full text, mbox):
On 10/04/2017 11:15 AM, Jim Meyering wrote:
> On Sun, Oct 1, 2017 at 7:28 PM, Dennis Clarke <dclarke <at> blastwave.org> wrote:
>> I looked into the binary3 test a bit and tried this manually :
>>
>> deb8_ppc64$
>> deb8_ppc64$ LC_ALL=C ../sed/sed -n -f ./binary3.sed < binary.inp | LC_ALL=C
>> tr -d \\r > binary3.out_manual
>>
>> It just runs endlessly and never returns.
>>
>> Not sure what data to add in here.
>
> Thank you for the details. I presume this is with the latest?
Direct from the release tarball. I also did try a git pull but that
resulted in other problems.
> Does it also infloop if you remove the output pipe:
>
> LC_ALL=C ../sed/sed -n -f ./binary3.sed < binary.inp > out
>
> Can you run it via gdb and hit ^C then see where/why it's looping?
>
> LC_ALL=C gdb --args ../sed/sed
>
> to run it under gdb, do this:
>
> (gdb) run -n -f ./binary3.sed < binary.inp
>
Well, here comes the frustrating problem : it all works now. :-\
Why?
Your guess is as good as mine but there seems to have been a need for a
lot of locales to be installed as well as an old old dusty configure
option to be removed. This is really long :
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28665
Assaf Gordon says that "--enable-regex-tests" should not be used.
quote:
These 'regex' tests are very old, and have not been maintained
since about 2004. We simply haven't gotten around to either fix
them or remove them.
Also :
> FAIL: testsuite/utf8-ru.sh
Assaf Gordon says :
This is one test that will certainly remain even after removing
the "regex tests".
As a first step to understand if this is a false positive or
a sed failure, can you tell us which locales are installed
on your computer ("locale -a") ?
To this I can tell you that I only had the essentials. A few utf8 and
not many of them.
Assaf Gordon also says :
I see the test uses "ru_RU.UTF-8", and it's possible it uses the
locale without first verifying it is available on the system.
I believe that must be true.
After I installed ALL the locale options that I could get as well as
removed the configure option for regex tests we get a clean configure
and a clean compile and testsuite.
So here I am baffled as to what infinite loops were running. I can tell
you that I was running "htop" in an xterm while the system tried and
tried ( vainly ) to perform a gcc bootstrap. The htop showed me that
there were sed binary tests that had been running for 36 hours plus. I
have done a kill -9 on them two days ago but what result I got from that
was that the ppid went away to be replaced by pid 1 and the binary tests
were still running. I was amazed. I ran kill -9 on them again and again
and was eventually able to make them go away.
Now I can not reproduce them.
I really hate problems like this that seem to be based on some minor
issue with locale or a bad configure option or it is a Tuesday and your
mother's birthday. Makes no sense whatsoever to try to reproduce now
because it simply runs and run fine.
However let's see what happens anyways :
I will look into my list of attempts over and over for the past 3 days.
deb8_ppc64$ ls -loptr | grep "sed" | grep "^drw" | cut -c31-96
Oct 1 22:55 sed-4.4_linux_3.16.0-4-powerpc64.001/
Oct 1 23:24 sed-4.3_linux_3.16.0-4-powerpc64.001/
Oct 2 11:21 sed-4.4.84-a59fb_linux_3.16.0-4-powerpc64_ppc64.001/
Oct 2 12:06 sed-4.2.2_linux_3.16.0-4-powerpc64.001/
Oct 3 17:27 sed-4.4_linux_3.16.0-4-powerpc64.002/
Oct 3 17:35 sed-4.4_linux_3.16.0-4-powerpc64.002.pkg/
Oct 3 17:40 sed-4.4_linux_3.16.0-4-powerpc64.003/
Oct 3 17:43 sed-4.4_linux_3.16.0-4-powerpc64.003.pkg/
The last two directories that have the suffix ".pkg" are fully clean
and successful builds and tests. I was so astonished that I did it
twice. Also, installed into /usr/local which is what I really wanted.
Let's go back in time a few days and try the test from within the
first point of failure :
deb8_ppc64$ cd sed-4.4_linux_3.16.0-4-powerpc64.001/testsuite
deb8_ppc64$ LC_ALL=C ../sed/sed -n -f ./binary3.sed < binary.inp > out
gone ... never to return.
deb8_ppc64$ file out
out: empty
It seems to produce nothing. Let's reach for gdb ( which I also had to
build from sources myself ) :
deb8_ppc64$ LC_ALL=C gdb --args ../sed/sed
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../sed/sed...done.
(gdb) run -n -f ./binary3.sed < binary.inp
Starting program:
/usr/local/build/sed-4.4_linux_3.16.0-4-powerpc64.001/sed/sed -n -f
./binary3.sed < binary.inp
Full 100% CPU usage on a single core and into the infinite depths we go.
Wait a full minute and hit CTRL-C :
^C
Program received signal SIGINT, Interrupt.
match_regex (regex=0x10071b20, buf=0x10040080
"aa-\nb;9876543210aaaaaaaaaR| D\n\n192\n168\n18", buflen=25,
buf_start_offset=0,
regarray=0x0, regsize=0) at sed/regexp.c:356
356 if ((regex->flags & REG_NEWLINE) && buffer_delimiter != '\n')
(gdb) print regex
$1 = (struct regex *) 0x10071b20
(gdb) print *regex
$3 = {pattern = {buffer = 0x10074930, allocated = 224, used = 224,
syntax = 50790982, fastmap = 0x10071b90 "", translate = 0x0,
re_nsub = 0, can_be_null = 0, regs_allocated = 1, fastmap_accurate
= 1, no_sub = 1, not_bol = 0, not_eol = 0,
newline_anchor = 0}, flags = 0, sz = 2, dfa = 0x10075440, begline =
false, endline = false, re = "^"}
(gdb)
OKay ... this is at least something to look at. Still makes me wonder
what loop we are in.
Dennis
Information forwarded
to
bug-sed <at> gnu.org
:
bug#28666
; Package
sed
.
(Sun, 29 Oct 2017 04:04:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 28666 <at> debbugs.gnu.org (full text, mbox):
Hello Dennis,
On 2017-10-04 12:26 PM, Dennis Clarke wrote:
> On 10/04/2017 11:15 AM, Jim Meyering wrote:
>
>> Does it also infloop if you remove the output pipe:
>>
>> LC_ALL=C ../sed/sed -n -f ./binary3.sed < binary.inp > out
>>
> Well, here comes the frustrating problem : it all works now. :-\
I've tested the same on a Linux PowerPC64 (power7) machine and I'm not
able to reproduce it, either with sed-4.4 or the latest git version of sed.
With both versions I see the following:
$ ./sed/sed -n -f ./testsuite/binary3.sed < ./testsuite/binary.inp
192
168
1
0
192
168
1
255
With the latest sed, the file 'binary.inp' does not exist (it is
generated on-the fly), and I've tested it both with 'binary.inp' from
the previous release, and by running the new tests with:
make check TESTS=testsuite/binary.sh SUBDIRS=.
Are you still able to reproduce the infloop on the previous release of
sed (sed version 4.4) ?
regards,
- assaf
Reply sent
to
Assaf Gordon <assafgordon <at> gmail.com>
:
You have taken responsibility.
(Mon, 08 Oct 2018 20:13:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dennis Clarke <dclarke <at> blastwave.org>
:
bug acknowledged by developer.
(Mon, 08 Oct 2018 20:13:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 28666-done <at> debbugs.gnu.org (full text, mbox):
With no further response, I'm closing this bug.
If the issue persists, we'll revisit it.
Information forwarded
to
bug-sed <at> gnu.org
:
bug#28666
; Package
sed
.
(Mon, 08 Oct 2018 21:13:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 28666-done <at> debbugs.gnu.org (full text, mbox):
On 10/08/2018 04:11 PM, Assaf Gordon wrote:
> With no further response, I'm closing this bug.
>
> If the issue persists, we'll revisit it.
>
Go ahead. I have long since managed to get a clean test and build on
a Debian ppc64 sid machine with gcc 8.1.0.
Dennis
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 06 Nov 2018 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 172 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.