HP-UX 10.20 blead
H.Merijn Brand
What can I do to get more info?
A full build+test takes about 4½ hours :(
so binary searching will take weeks.
Test Summary Report
-------------------
re/reg_fold.t (Wstat: 0 Tests: 4722 Failed: 0)
TODO passed: 458, 2632, 4398, 4404, 4410, 4416, 4422
4428, 4434
re/regexp_qr_embed_thr.t (Wstat: 0 Tests: 1398 Failed: 958)
Failed tests: 323-338, 342-352, 356, 358-361, 364-367
369-378, 380-440, 442-468, 470-522, 527
529-568, 571-600, 603, 605-630, 633-635
639-929, 931-935, 937-946, 948-952, 954-982
985-1026, 1041-1068, 1072-1107, 1109-1188
1190-1191, 1193-1196, 1198-1204, 1206-1212
1214-1216, 1218-1220, 1222-1224, 1226-1227
1229-1231, 1233-1236, 1239-1248, 1273, 1276-1280
1283-1290, 1293-1298, 1300-1301, 1303, 1306-1319
1322-1324, 1326-1328, 1330-1344, 1346-1354
1357-1365, 1367-1372, 1374-1381, 1385, 1387
1389-1390, 1394, 1396
op/stash.t (Wstat: 0 Tests: 31 Failed: 0)
TODO passed: 26
op/threads.t (Wstat: 0 Tests: 15 Failed: 0)
TODO passed: 15
op/time.t (Wstat: 0 Tests: 44 Failed: 4)
Failed tests: 33-36
porting/manifest.t (Wstat: 0 Tests: 9427 Failed: 1)
Failed test: 9427
../cpan/Math-Complex/t/Trig.t (Wstat: 2048 Tests: 153 Failed: 8)
Failed tests: 100, 102, 109, 111, 125, 127, 131, 133
Non-zero exit status: 8
../dist/Net-Ping/t/450_service.t (Wstat: 0 Tests: 26 Failed: 0)
TODO passed: 9, 18
../dist/threads-shared/t/wait.t (Wstat: 0 Tests: 91 Failed: 12)
Failed tests: 38, 40, 42, 44, 46, 48, 81, 83, 85, 87
89, 91
../dist/threads-shared/t/waithires.t (Wstat: 0 Tests: 57 Failed: 12)
Failed tests: 19, 21, 23, 25, 27, 29, 47, 49, 51, 53
55, 57
../ext/Time-Local/t/Local.t (Wstat: 1536 Tests: 175 Failed: 6)
Failed tests: 109-114
Non-zero exit status: 6
../lib/Time/localtime.t (Wstat: 65280 Tests: 1 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 109 tests but ran 1.
Files=1794, Tests=356184, 11362 wallclock secs (1593.29 usr 110.65 sys + 8503.53 cusr 339.35 csys = 10546.82 CPU)
Result: FAIL
make: *** [test_harness] Error 233
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Nicholas Clark
> Smoke killed, manual build threaded debugging.
>
> What can I do to get more info?
> A full build+test takes about 4� hours :(
> so binary searching will take weeks.
Doctor doctor, it hurts if I do that.
Then don't do that.
As in:
1: Don't run the full tests, just the test (or tests) that you are interested
in (`make test_prep` seems to be ideal for doing the least work)
> re/regexp_qr_embed_thr.t (Wstat: 0 Tests: 1398 Failed: 958)
> op/time.t (Wstat: 0 Tests: 44 Failed: 4)
> porting/manifest.t (Wstat: 0 Tests: 9427 Failed: 1)
> ../cpan/Math-Complex/t/Trig.t (Wstat: 2048 Tests: 153 Failed: 8)
> ../dist/threads-shared/t/wait.t (Wstat: 0 Tests: 91 Failed: 12)
> ../dist/threads-shared/t/waithires.t (Wstat: 0 Tests: 57 Failed: 12)
> ../ext/Time-Local/t/Local.t (Wstat: 1536 Tests: 175 Failed: 6)
2: None of the tests involve encodings, so Configure to build without Encode
Encode takes time to build
3: (Build and) install ccache if it's not there
4: Do the smokes say when the tests last passed? I'm assuming that you have
some idea of which revision is the low end for the binary search.
Run Configure for the current revision, and save the config.sh
Run Configure for that revision, and compare with the config.sh
If it's the same - bingo - skip the "run Configure" step and just use
./Configure -S
If not, see if the current config.sh is good enough to clean-build the start
revision. (And all tests pass). If so, assume that that config.sh is good
enough to use with ./Configure -S
Were you planning to binary search on all tests together? Or individually?
Ignoring the MANIFEST test failure, which may be a red herring, I'm wondering
if binary searching on just the first test for the commit which breaks it,
will turn out to be the same commit that breaks several of the other tests.
Nicholas Clark
H.Merijn Brand
wrote:
> On Sat, Dec 19, 2009 at 02:52:43PM +0100, H.Merijn Brand wrote:
> > Smoke killed, manual build threaded debugging.
> >
> > What can I do to get more info?
> > A full build+test takes about 4½ hours :(
> > so binary searching will take weeks.
>
> Doctor doctor, it hurts if I do that.
> Then don't do that.
>
> As in:
>
> 1: Don't run the full tests, just the test (or tests) that you are interested
> in (`make test_prep` seems to be ideal for doing the least work)
That is already in the smoke/manual process, but as most of the smokes
are cut because of time, I thought I'd run the whole thing for once
> > re/regexp_qr_embed_thr.t (Wstat: 0 Tests: 1398 Failed: 958)
>
> > op/time.t (Wstat: 0 Tests: 44 Failed: 4)
>
> > porting/manifest.t (Wstat: 0 Tests: 9427 Failed: 1)
>
> > ../cpan/Math-Complex/t/Trig.t (Wstat: 2048 Tests: 153 Failed: 8)
>
> > ../dist/threads-shared/t/wait.t (Wstat: 0 Tests: 91 Failed: 12)
>
> > ../dist/threads-shared/t/waithires.t (Wstat: 0 Tests: 57 Failed: 12)
>
> > ../ext/Time-Local/t/Local.t (Wstat: 1536 Tests: 175 Failed: 6)
>
> 2: None of the tests involve encodings, so Configure to build without Encode
> Encode takes time to build
Can do
> 3: (Build and) install ccache if it's not there
Of course already there
> 4: Do the smokes say when the tests last passed? I'm assuming that you have
> some idea of which revision is the low end for the binary search.
Already discussed with Jesse on IRC:
Last smoke that did not show thread fails:
Automated smoke report for 5.11.0 patch 6151f429289815aa2ca4ecae706ff8f66fa49d02 blead-2198-g6151f42
First smoke after that one (which showed thread fails):
Automated smoke report for 5.11.0 patch dba3d646d21716f1dbbeb5e0e7ba484a1e782f0f blead-2245-gdba3d64
> Run Configure for the current revision, and save the config.sh
> Run Configure for that revision, and compare with the config.sh
> If it's the same - bingo - skip the "run Configure" step and just use
> ./Configure -S
> If not, see if the current config.sh is good enough to clean-build the start
> revision. (And all tests pass). If so, assume that that config.sh is good
> enough to use with ./Configure -S
>
> Were you planning to binary search on all tests together? Or individually?
I wasn't *planning* any binary search at all, as with that machine's
speed, it might be new year before we get usable result
> Ignoring the MANIFEST test failure, which may be a red herring, I'm wondering
> if binary searching on just the first test for the commit which breaks it,
> will turn out to be the same commit that breaks several of the other tests.
--
Jesse
On Sat, Dec 19, 2009 at 03:47:31PM +0100, H.Merijn Brand wrote:
> On Sat, 19 Dec 2009 14:13:36 +0000, Nicholas Clark <ni...@ccl4.org>
> wrote:
>
> > On Sat, Dec 19, 2009 at 02:52:43PM +0100, H.Merijn Brand wrote:
> > > Smoke killed, manual build threaded debugging.
> > >
> > > What can I do to get more info?
> > > A full build+test takes about 4½ hours :(
> > > so binary searching will take weeks.
Theremay be something faulty with my math, but I believe we determined
that the failure started between
6151f429289815aa2ca4ecae706ff8f66fa49d02 blead-2198-g6151f42
and
dba3d646d21716f1dbbeb5e0e7ba484a1e782f0f blead-2245-gdba3d64
That's about 47 revisions.
It's true that a linear search of those revisions would take us until
2010. But a _binary_ search should take only about 6 revisions. Which
is only a day or two.
-Jesse
H.Merijn Brand
> On Sat, Dec 19, 2009 at 03:47:31PM +0100, H.Merijn Brand wrote:
> > On Sat, 19 Dec 2009 14:13:36 +0000, Nicholas Clark <ni...@ccl4.org>
> > wrote:
> >
> > > On Sat, Dec 19, 2009 at 02:52:43PM +0100, H.Merijn Brand wrote:
> > > > Smoke killed, manual build threaded debugging.
> > > >
> > > > What can I do to get more info?
> > > > A full build+test takes about 4½ hours :(
> > > > so binary searching will take weeks.
>
> Theremay be something faulty with my math, but I believe we determined
> that the failure started between
>
> 6151f429289815aa2ca4ecae706ff8f66fa49d02 blead-2198-g6151f42
>
> and
>
> dba3d646d21716f1dbbeb5e0e7ba484a1e782f0f blead-2245-gdba3d64
>
>
> That's about 47 revisions.
Some yak-shaving later (installed bash, coreutils' install to install a
crippled git ...
$ git pull
$ git bisect start
$ git bisect bad dba3d646d21716
$ git bisect good d55aad059d63cf3faa3
$ git bisect run /pro/3gl/CPAN/run
:
:
a5446a64ab75205e7ec7185a30ff6e9f7c532dd0 is the first bad commit
commit a5446a64ab75205e7ec7185a30ff6e9f7c532dd0
Author: David Mitchell <da...@iabyn.com>
Date: Sat Jul 11 17:56:06 2009 +0100
[perl #61520] Segfault in debugger with tr// and UTF8
commit 043e41b8 (29765), which made tr// threadsafe by moving the
swash into the pad, didn't mark the pad SV as read-only, so it was getting
removed from anon sub prototypes
:100644 100644 54d2a64a78fe42754249b38f1512a6d7f9bf802f d7ef32c3cd80033fc7baff430a17a14cc6b7c60f M op.c
:040000 040000 9a6393950f0a72b27764a05912e33f21fb17d5d6 f80a3e92339da7318c883477c05f5165090eddce M t
bisect run success
$ cat ../run
#!/bin/sh
PATH=/pro/local/bin/cached:$PATH
#git clean -dxf
cp -p -f ../Policy.sh .
Configure -Dusedevel -Dusethreads -Dnoextensions=Encode -des
test -f config.sh || exit 125
make test_prep
[ -x ./perl ] || exit 125
./perl -Ilib t/re/regexp_qr_embed_thr.t
ret=$?
[ $ret -gt 127 ] && ret=127
git clean -dxf
exit $ret
> It's true that a linear search of those revisions would take us until
> 2010. But a _binary_ search should take only about 6 revisions. Which
> is only a day or two.
Dave Mitchell
(Just catching up on 3 months worth of unread p5p emails)
Is this still an issue?
Is it only a failure of that test on that one platform?
Is there any further background or info?
I'm confused about the date ranges: earlier above it's said that the
failure is between
> > 6151f429289815aa2ca4ecae706ff8f66fa49d02 blead-2198-g6151f42
> >
> > and
> >
> > dba3d646d21716f1dbbeb5e0e7ba484a1e782f0f blead-2245-gdba3d64
Which are between Sep 9 and sep 11, but then the bisect shows a July
commit at fault???
--
Hofstadter's Law: It always takes longer than you expect, even when you
take into account Hofstadter's Law.
H.Merijn Brand
wrote:
Yes and no. We've decided that threads on HP-UX 20.20 - in this case
implemented by pth - are not longer supported:
commit 30026e362a034115c7d0374a1e217a52f4111932
Author: H.Merijn Brand <h.m....@xs4all.nl>
Date: Mon Dec 21 12:17:57 2009 +0100
The use of PTH will be unsupported in perl-5.12 for HP-UX 10.20
> Is it only a failure of that test on that one platform?
No, see http://doc.procura.nl/smoke/hpux1020/511/cc/mktest.rpt
http://doc.procura.nl/smoke/hpux1020/511/cc/mktest.out and
http://doc.procura.nl/smoke/hpux1020/511/cc/smoke.log
> Is there any further background or info?
>
> I'm confused about the date ranges: earlier above it's said that the
> failure is between
Which was a bad analysis
> > > 6151f429289815aa2ca4ecae706ff8f66fa49d02 blead-2198-g6151f42
> > >
> > > and
> > >
> > > dba3d646d21716f1dbbeb5e0e7ba484a1e782f0f blead-2245-gdba3d64
>
> Which are between Sep 9 and sep 11, but then the bisect shows a July
> commit at fault???
git-bisect++
I ported git to HP-UX 10.20, which was easier than writing something
wrappering around other means of finding the exact cause.
H.Merijn Brand
wrote:
> Um, aren't they still referring to HP-UX 10.20; also I can't see any
> regexp_qr_embed_thr.t failure in them???
Because they are not testing threads anymore
Do you *really* want the results? I can do a full build/test for you if
you still want.
Dave Mitchell
Um, aren't they still referring to HP-UX 10.20; also I can't see any
regexp_qr_embed_thr.t failure in them???
--
"The GPL violates the U.S. Constitution, together with copyright,
antitrust and export control laws"
-- SCO smoking crack again.
Dave Mitchell
> Because they are not testing threads anymore
> Do you *really* want the results? I can do a full build/test for you if
> you still want.
I think we're probably misunderstanding each other.
I'm coming from the point of view that one of my commits has been
identified as causing a regression. I want to know whether I need to
devote time to fixing this (and indeed whether anything actually needs
fixing).
So...
was 10.20 threading disabled due to this issue, or was there a more
general problem with threads on that platform?
Does this issue occur on any platforms apart from 10.20; and if so, which
ones?
--
Now is the discount of our winter tent
-- sign seen outside camping shop
H.Merijn Brand
wrote:
> On Sun, Jan 03, 2010 at 07:30:35PM +0100, H.Merijn Brand wrote:
> > Because they are not testing threads anymore
> > Do you *really* want the results? I can do a full build/test for you if
> > you still want.
>
> I think we're probably misunderstanding each other.
>
> I'm coming from the point of view that one of my commits has been
> identified as causing a regression. I want to know whether I need to
> devote time to fixing this (and indeed whether anything actually needs
> fixing).
>
> So...
>
> was 10.20 threading disabled due to this issue,
Yes, but it was just the drop.
Threading on HP-UX 10.20 is a PITA. HP-UX 10.20 has no native thread
support at all, and I have to use pth in order to get threads working
at all. Me being the only one in the world still building Open Source
from scratch for 10.20 and releasing that on my site, I can justify to
drop thread support. I have never released a threaded perl build for
10.20, as it causes a big slowdown.
> or was there a more general problem with threads on that platform?
Yes, also.
> Does this issue occur on any platforms apart from 10.20; and if so,
> which ones?
Not that we know of.
Dave Mitchell
> Threading on HP-UX 10.20 is a PITA. HP-UX 10.20 has no native thread
> support at all, and I have to use pth in order to get threads working
> at all. Me being the only one in the world still building Open Source
> from scratch for 10.20 and releasing that on my site, I can justify to
> drop thread support. I have never released a threaded perl build for
> 10.20, as it causes a big slowdown.
>
> > or was there a more general problem with threads on that platform?
>
> Yes, also.
>
> > Does this issue occur on any platforms apart from 10.20; and if so,
> > which ones?
>
> Not that we know of.
So it sounds like I can ignore this issue?
--
But Pity stayed his hand. "It's a pity I've run out of bullets",
he thought. -- "Bored of the Rings"
H.Merijn Brand
wrote:
> On Sun, Jan 03, 2010 at 09:07:20PM +0100, H.Merijn Brand wrote:
> > Threading on HP-UX 10.20 is a PITA. HP-UX 10.20 has no native thread
> > support at all, and I have to use pth in order to get threads working
> > at all. Me being the only one in the world still building Open Source
> > from scratch for 10.20 and releasing that on my site, I can justify to
> > drop thread support. I have never released a threaded perl build for
> > 10.20, as it causes a big slowdown.
> >
> > > or was there a more general problem with threads on that platform?
> >
> > Yes, also.
> >
> > > Does this issue occur on any platforms apart from 10.20; and if so,
> > > which ones?
> >
> > Not that we know of.
>
> So it sounds like I can ignore this issue?
If you ask me, yes.