Open demerphq opened 1 year ago
stdio
smoking has been disabled on this HP-UX box. All was green after that.
Can this issue be closed now?
I /think/ a note in README.hpux
would be appropriate. @demerphq ?
@tux that makes sense to me. Normal builds work, not sure we should care too much about stdio builds given there aren't many people targeting this platform.
AIX suffers the same failure pattern, but I do not know if it is the same cause.
AIX suffers the same failure pattern, but I do not know if it is the same cause.
That is a bit surprising. Do they share C libraries or compilers or something? If not that suggests there is something beyond a bug in the standard libraries at fault here. My analysis was that there is a bug in fclose(), but it seems unlikely that such a bug would affect two different platforms. We should try to dig deeper into this I think.
Automated smoke report for branch blead 5.38.0 patch 815251bd22ddf4bf221549c96736004652928824 v5.38.0-RC2-2-g815251b
i3: PPC_POWER5 (ppc/1 cpu)
on AIX - 5.3.0.0/TL12-05
using xlc -q32 version 12.1.0.12
smoketime 1 day 34 minutes (average 3 hours 4 minutes)
Summary: FAIL(F)
O = OK F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during: - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep
v5.38.0-RC2-2-g815251b Configuration (common) none
----------- ---------------------------------------------------------
F O O F O O
F O O F O O -Duse64bitall
F O O F O O -Duseithreads
F O O F O O -Duseithreads -Duse64bitall
| | | | | +- LC_ALL = EN_US.UTF-8 -DDEBUGGING
| | | | +--- PERLIO = perlio -DDEBUGGING
| | | +----- PERLIO = stdio -DDEBUGGING
| | +------- LC_ALL = EN_US.UTF-8
| +--------- PERLIO = perlio
+----------- PERLIO = stdio
Locally applied patches:
RC2
uncommitted-changes
SMOKE815251bd22ddf4bf221549c96736004652928824
Testsuite was run only with 'harness'
Failures: (common-args) none
[stdio]
[stdio] -DDEBUGGING
[stdio] -Duse64bitall
[stdio] -DDEBUGGING -Duse64bitall
[stdio] -Duseithreads
[stdio] -DDEBUGGING -Duseithreads
[stdio] -Duseithreads -Duse64bitall
[stdio] -DDEBUGGING -Duseithreads -Duse64bitall
../t/io/open.t..............................................FAILED
44, 92
I'm strongly suspecting this is another case of fallout of 80c1f1e45e8ef8c27d170fae7ade41971fe20218, just like #21187
Description t/io/open.t fails on HPUX with PERLIO=stdio
You can see this in the smoke reports from @Tux eg: https://tux.nl/perl5/smoke/hpux1131/511/cc/mktest.rpt
The code starting at line 3309 in perlio.c is as follows:
The call to PerlSIO_fclose(stdio) returns a non-zero exit code indicating an error, but it does not set ERRNO. You can force ERRNO to be whatever you like before triggering this code and it does not change. IIRC the "invalidate" variable is false when this code is called on HPUX, although this is from a fallable memory a long time after when i was debugging this.
I looked for errata from HPUX about this, but i couldnt find anything. As far as I can tell the underlying system call here (fclose) is broken on HPUX and does not set ERRNO correctly when it returns an error, and/or returns an error when it shouldnt. I found this extremely difficult to debug.
Steps to Reproduce make test
or
Expected behavior test should pass.
Perl configuration