5.24.1 'make test' failures on linux-x86_64 (Linux: 4.10 glibc: 2.25 gcc: 5,4.0) #15946
Comments
From @JVD66Created by @JVD66The PERL 5.24.1 I am using for this bug report failed its test If these test failures have been seen before / are expected / excerpts from the make.test.log file produced after successful Configure and $ make -j4 2>&1 | tee make.log && make test 2>&1 | tee make.test.log The process was stuck doing (shown by strace of it) : getitimer(ITIMER_VIRTUAL, {it_interval={0, 400000}, it_value={0, 490041}}) = 0 ... times({tms_utime=4, tms_stime=46582, tms_cutime=0, tms_cstime=0}) = 430811075 The only major difference in configuration between 5.22.1, which I will be investigating each problem above further unless someone Perl Info |
From @JVD66Re-Configuring and answering 'n' (No) to using fast stdio (PerlIO) It could be that something is buggy with Linux 4.10.0's timing subsystem - I've |
From @JVD66Re-Configuring and answering 'n' (No) to using fast stdio (PerlIO) It could be that something is buggy with Linux 4.10.0's timing subsystem - |
From [Unknown Contact. See original ticket]Re-Configuring and answering 'n' (No) to using fast stdio (PerlIO) It could be that something is buggy with Linux 4.10.0's timing subsystem - |
From @jkeenanOn Sun, 09 Apr 2017 16:03:35 GMT, jvdias wrote:
This is going to be difficult for us to diagnose without more information. You indicate that when configuring perl-5.24.1, you answered 'Yes' to one question to which, in perl-5.22.1, you answered 'No'. But that doesn't tell us how you answered all the *other* questions during manual configuration. For example, the output of 'perl -V' you attached shows no 'config_args' but does show 'useithreads=define', suggesting you answered Yes to "Build a threading Perl? [n]". If I download a tarball of perl-5.24.1 and start to configure manually, I have to know how to answer each of the questions as a prerequisite to further diagnose. If you know how you want to configure Perl, can you give us that description in regular words? We could then translate that into the particular set of arguments to Configure that meet your objective and get all tests to PASS. Thank you very much.
-- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jkeenanOn Sun, 09 Apr 2017 16:54:53 GMT, jkeenan wrote:
After unwrapping a perl-5.24.1 tarball, I configured with this command: ##### This was my guess at what your configuration would have looked like if done non-interactively -- with two exceptions: 1. I was running as myself, not as root. (And I confess I don't know why you would do this as root.) 2. I did not include '-Duseshrplib'. (When I did include '-Duseshrplib' I got errors in 4 of the test files you cited.) All tests PASSed. Content of './perl -Ilib -V' attached. So my hunch is that those two differences just mentioned are the source of your test failures. Thank you very much. |
From @jkeenanSummary of my perl5 (revision 5 version 24 subversion 1) configuration: Characteristics of this binary (from libperl): |
From @JVD66On Sun, 09 Apr 2017 11:15:37 -0700, jkeenan wrote:
Thanks very much for your response, James - I did attach a copy of my config.sh to the mail, which didn't get attached to this bug - attaching now . I built linux 4.10.9, and rebuilt perl with the -Dusefaststdio option - building I need the -Duseshrplib option. Could it be, after all this time, that I am re-running tests as non-root user, with : and the config.sh as attached. Same tests are still failing . I will investigate further and find out exactly why all the Thanks & Regards, |
From @JVD66On Sun, 09 Apr 2017 16:35:34 -0700, jvdias wrote:
Aha ! there is a problem on my system with times() - RE: t/op/time.t - The test that fails is : $ LD_LIBRARY_PATH=${PWD} \ # ok($now > $beg && $now - $beg < 10, 'very basic time test'); my $x = "aaaa"; print $beguser, " ", $begsys, " ", join(" ",times),"\n"; ie. Linux / glibc is returning FOUR elements for times() - struct tms { would set $begsys to the remainder of the list ? Confirmed by doing : print time, " ", $now, " ", $beg, "\n"; print $i," ", $beguser+$begcuser, " ", $begsys + $begcsys, " ",$nowuser+$nowcuser, " ", $nowsys+$nowcsys, " [", join(" ",times),"]\n";' 1491786835 1491786835 1491786834 $ Note the test would still fail : ok($i >= 2_000_000, 'very basic times test'); since $i is 559601 . I guess under Linux 4.10.9 , it is no longer Anyway, on my system, NO user CPU cycles are measured , $i = 2_000_000 if $nowuser > $beguser && ( $nowsys >= $begsys || is never true. Perhaps this should be something like: $i = 2_000_000 if (($nowuser + $nowcuser + $beguser + $begcuser) > 0) || ?? |
From [Unknown Contact. See original ticket]On Sun, 09 Apr 2017 16:35:34 -0700, jvdias wrote:
Aha ! there is a problem on my system with times() - RE: t/op/time.t - The test that fails is : $ LD_LIBRARY_PATH=${PWD} \ # ok($now > $beg && $now - $beg < 10, 'very basic time test'); my $x = "aaaa"; print $beguser, " ", $begsys, " ", join(" ",times),"\n"; ie. Linux / glibc is returning FOUR elements for times() - struct tms { would set $begsys to the remainder of the list ? Confirmed by doing : print time, " ", $now, " ", $beg, "\n"; print $i," ", $beguser+$begcuser, " ", $begsys + $begcsys, " ",$nowuser+$nowcuser, " ", $nowsys+$nowcsys, " [", join(" ",times),"]\n";' 1491786835 1491786835 1491786834 $ Note the test would still fail : ok($i >= 2_000_000, 'very basic times test'); since $i is 559601 . I guess under Linux 4.10.9 , it is no longer Anyway, on my system, NO user CPU cycles are measured , $i = 2_000_000 if $nowuser > $beguser && ( $nowsys >= $begsys || is never true. Perhaps this should be something like: $i = 2_000_000 if (($nowuser + $nowcuser + $beguser + $begcuser) > 0) || ?? |
From @JVD66On Sun, 09 Apr 2017 18:23:18 -0700, jvdias wrote:
I think on modern Linux, times() is becoming less and less accurate. Linux is becoming less and less real time capable as time progresses - |
From [Unknown Contact. See original ticket]On Sun, 09 Apr 2017 18:23:18 -0700, jvdias wrote:
I think on modern Linux, times() is becoming less and less accurate. Linux is becoming less and less real time capable as time progresses - |
From @jkeenanOn Mon, 10 Apr 2017 01:43:51 GMT, jvdias wrote:
P5P List: Is there anyone who could start providing smoke tests for Linux 4.10.9? Linux 4.9.11 is the highest version I could find at http://perl5.test-smoke.org/search. Thank you very much. -- |
From @jkeenanOn Sun, 09 Apr 2017 23:35:34 GMT, jvdias wrote:
I know little about -Duseshrplib, so other readers will have to help you out on that. -- |
From @JVD66On Sun, 09 Apr 2017 18:43:51 -0700, jvdias wrote:
Fix for times issues is this patch : Inline Patch--- pp_sys.c~ 2016-07-14 19:08:08.000000000 +0000
+++ pp_sys.c 2017-04-10 02:42:37.169810362 +0000
@@ -4651,0 +4652,4 @@
+#if defined(__linux__)
+#include <linux/version.h>
+#endif
+
@@ -4657 +4661,3 @@
-
+#if (defined(__linux__) && ( (LINUX_VERSION_CODE >> 16) >= 4 ))
+ struct timespec ts;
+#endif
@@ -4660 +4666,8 @@
-
+
+#if (defined(__linux__) && ( (LINUX_VERSION_CODE >> 16) >= 4 ))
+ /* Linux's times() no longer measures accurate user CPU time */
+ clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts );
+ timesbuf.tms_utime = (ts.tv_sec * PL_clocktick) +
+ (ts.tv_nsec / ( 1000000000 / PL_clocktick) );
+#endif
+
All other tests that failed above (except time.t or Benchmark.t)
are still failing. |
From @JVD66pp_sys.patch--- pp_sys.c~ 2016-07-14 19:08:08.000000000 +0000
+++ pp_sys.c 2017-04-10 02:42:37.169810362 +0000
@@ -4651,0 +4652,4 @@
+#if defined(__linux__)
+#include <linux/version.h>
+#endif
+
@@ -4657 +4661,3 @@
-
+#if (defined(__linux__) && ( (LINUX_VERSION_CODE >> 16) >= 4 ))
+ struct timespec ts;
+#endif
@@ -4660 +4666,8 @@
-
+
+#if (defined(__linux__) && ( (LINUX_VERSION_CODE >> 16) >= 4 ))
+ /* Linux's times() no longer measures accurate user CPU time */
+ clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts );
+ timesbuf.tms_utime = (ts.tv_sec * PL_clocktick) +
+ (ts.tv_nsec / ( 1000000000 / PL_clocktick) );
+#endif
+
|
From [Unknown Contact. See original ticket]On Sun, 09 Apr 2017 18:43:51 -0700, jvdias wrote:
Fix for times issues is this patch : Inline Patch--- pp_sys.c~ 2016-07-14 19:08:08.000000000 +0000
+++ pp_sys.c 2017-04-10 02:42:37.169810362 +0000
@@ -4651,0 +4652,4 @@
+#if defined(__linux__)
+#include <linux/version.h>
+#endif
+
@@ -4657 +4661,3 @@
-
+#if (defined(__linux__) && ( (LINUX_VERSION_CODE >> 16) >= 4 ))
+ struct timespec ts;
+#endif
@@ -4660 +4666,8 @@
-
+
+#if (defined(__linux__) && ( (LINUX_VERSION_CODE >> 16) >= 4 ))
+ /* Linux's times() no longer measures accurate user CPU time */
+ clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts );
+ timesbuf.tms_utime = (ts.tv_sec * PL_clocktick) +
+ (ts.tv_nsec / ( 1000000000 / PL_clocktick) );
+#endif
+
All other tests that failed above (except time.t or Benchmark.t)
are still failing. |
From @iabynOn Sun, Apr 09, 2017 at 06:43:52PM -0700, Jason Vas Dias via RT wrote:
Do you have any indications that times() returning garbage is new intended I would be *extremely* reluctant to include code in perl that is Can you compile and run the following little program to confirm whether #include <stdio.h> int main(int argc, char**argv) On my platform I see: $ make c real 0m4.168s -- |
From @JVD66On Mon, 10 Apr 2017 01:41:59 -0700, davem wrote:
Thanks for responding, Dave! Yes, something is very strange about Linux 4.10+ 's $ gcc -o times1 times1.c This took a noticeable time to complete - @ 3.52 seconds - Getting out my trusty bash built-in high-res timer which $ . /lib64/bash-4.3.42\(9\)-release_loadables/load.sh So even getrusage does not record ANY user CPU time . One explanation might be that improved branch prediction in Linux kernel for (i=0; i<1; i++) has no effect because 'j' is never used; indeed the compiler might realize that But it does look like a linux bug ; NO 'user' CPU cycles are being recorded $ ps -e -o 'pid=' -o 'ppid=' -o 'utime=' -o 'stime=' -o 'etimes=' -o 'psr=' -o 'state=' EVERY process in the system has '-' (0) utime and the SAME 'stime' , I'll re-examine all process accounting kernel CONFIG_ items - but I Thanks to perl test suite for opening my eyes to this issue ! Will report back when kernel issue is resolved . |
From @JVD66The times() issue was due to me mistakenly enabling the kernel .config : CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_VIRT_CPU_ACCOUNTING is not a complete feature yet. Sorry ! But it still doesn't explain other test failures like : t/run/switches ................................................ # Failed test 9 - RT \#61362: Cannot syntax-check a directory at run/switches.t line 128 t/op/taint .................................................... # Failed test 732 - tainted $! at op/taint.t line 2060 This happens when running tests as non-root user now: cpan/autodie/t/utime .......................................... Can't utime('1491789341', '1491779964', '/usr/build/linux/perl-5.24.1/cpan/autodie/t/touch_me'): 1 at t/utime.t line 24 cpan/ExtUtils-Install/t/Installed ............................. # Failed test '... should find doc file under given dir' dist/autouse/t/autouse ........................................ # Failed test 'Function imported via 'autouse' performs as expected' dist/constant/t/constant ...................................... # Failed test at t/constant.t line 99. None of these tests fail when run under perl 5.22.1, which I am keeping till I can |
From [Unknown Contact. See original ticket]The times() issue was due to me mistakenly enabling the kernel .config : CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_VIRT_CPU_ACCOUNTING is not a complete feature yet. Sorry ! But it still doesn't explain other test failures like : t/run/switches ................................................ # Failed test 9 - RT \#61362: Cannot syntax-check a directory at run/switches.t line 128 t/op/taint .................................................... # Failed test 732 - tainted $! at op/taint.t line 2060 This happens when running tests as non-root user now: cpan/autodie/t/utime .......................................... Can't utime('1491789341', '1491779964', '/usr/build/linux/perl-5.24.1/cpan/autodie/t/touch_me'): 1 at t/utime.t line 24 cpan/ExtUtils-Install/t/Installed ............................. # Failed test '... should find doc file under given dir' dist/autouse/t/autouse ........................................ # Failed test 'Function imported via 'autouse' performs as expected' dist/constant/t/constant ...................................... # Failed test at t/constant.t line 99. None of these tests fail when run under perl 5.22.1, which I am keeping till I can |
From @JVD66OK, I rebuilt the kernel with CONFIG_TICK_CPU_ACCOUNTING defined and times() and itimers now work as expected. But the remaining test failures still persist, when run either as root t/run/switches ................................................ # Failed test 9 - RT \#61362: Cannot syntax-check a directory at run/switches.t line 128 t/op/taint .................................................... # Failed test 732 - tainted $! at op/taint.t line 2060 cpan/ExtUtils-Install/t/Installed ............................. # Failed test '... should find doc file under given dir' dist/autouse/t/autouse ........................................ # Failed test 'Function imported via 'autouse' performs as expected' dist/constant/t/constant ...................................... # Failed test at t/constant.t line 99. |
From [Unknown Contact. See original ticket]OK, I rebuilt the kernel with CONFIG_TICK_CPU_ACCOUNTING defined and times() and itimers now work as expected. But the remaining test failures still persist, when run either as root t/run/switches ................................................ # Failed test 9 - RT \#61362: Cannot syntax-check a directory at run/switches.t line 128 t/op/taint .................................................... # Failed test 732 - tainted $! at op/taint.t line 2060 cpan/ExtUtils-Install/t/Installed ............................. # Failed test '... should find doc file under given dir' dist/autouse/t/autouse ........................................ # Failed test 'Function imported via 'autouse' performs as expected' dist/constant/t/constant ...................................... # Failed test at t/constant.t line 99. |
From @JVD66OK, here is my attempt to fix each issue: 1. t/run/switches ................................................ # Failed test 9 - RT \#61362: Cannot syntax-check a directory at run/switches.t line 128 The code that fails is equivalent to this perl script, which I created in <quote><pre> $ LD_PRELINK=${PWD}/libperl.so LD_LIBRARY_PATH=${PWD} \ error is: rp is: Can't open perl script "tmp9540B": (null) $ echo $((6400>>8)) $ LD_PRELINK=${PWD}/libperl.so LD_LIBRARY_PATH=${PWD} \ So perl 5.24.1 , when given a directory to run, actually exits with status 25 : ENOTTY , this is 5.22.1: the newly built 5.24.1: I think the actual point of RT #61362 has not been fixed: And it is a regression that perl 5.24.1 cannot print the This does not appear to be a minor issue, utils.c: being able to unpack the arguments, given to Perl_vcroak() . $ diff -U1 perl.c~ perl.c Inline Patch--- perl.c~ 2017-01-02 17:27:54.000000000 +0000
+++ perl.c 2017-04-10 22:40:07.740195693 +0000
@@ -3861,3 +3861,3 @@
CopFILE(PL_curcop),
- Strerror(EISDIR));
+ Strerror(errno=EISDIR));
My fix would be to back out any changes made to the die_unwind_ex Nice that the test suite picked up this disastrous fault in the croak mechanism! |
From [Unknown Contact. See original ticket]OK, here is my attempt to fix each issue: 1. t/run/switches ................................................ # Failed test 9 - RT \#61362: Cannot syntax-check a directory at run/switches.t line 128 The code that fails is equivalent to this perl script, which I created in <quote><pre> $ LD_PRELINK=${PWD}/libperl.so LD_LIBRARY_PATH=${PWD} \ error is: rp is: Can't open perl script "tmp9540B": (null) $ echo $((6400>>8)) $ LD_PRELINK=${PWD}/libperl.so LD_LIBRARY_PATH=${PWD} \ So perl 5.24.1 , when given a directory to run, actually exits with status 25 : ENOTTY , this is 5.22.1: the newly built 5.24.1: I think the actual point of RT #61362 has not been fixed: And it is a regression that perl 5.24.1 cannot print the This does not appear to be a minor issue, utils.c: being able to unpack the arguments, given to Perl_vcroak() . $ diff -U1 perl.c~ perl.c Inline Patch--- perl.c~ 2017-01-02 17:27:54.000000000 +0000
+++ perl.c 2017-04-10 22:40:07.740195693 +0000
@@ -3861,3 +3861,3 @@
CopFILE(PL_curcop),
- Strerror(EISDIR));
+ Strerror(errno=EISDIR));
My fix would be to back out any changes made to the die_unwind_ex Nice that the test suite picked up this disastrous fault in the croak mechanism! |
From @jkeenanOn Mon, 10 Apr 2017 23:00:51 GMT, jvdias wrote:
Can you supply the output of perl -V for these perl builds? Also, did you configure interactively, or did you supply command-line options to ./Configure? The latter would be particularly helpful to us in attempting to reproduce your problems. Thank you very much. |
From @iabynOn Mon, Apr 10, 2017 at 04:00:51PM -0700, Jason Vas Dias via RT wrote:
If I understand you correctly, there are two separate issues here. The first is that the fix for "perl /a_directory" is incomplete; although
Is my understanding correct? The second issue is that while perl5.22.x correctly gives an error message: $ perl5220 /tmp a regression in 5.24.x means that it now gives: $ perl5241 /tmp And, if I understand correctly, the Strerror(errno=EISDIR)) change doesn't A really important thing to point out is that this is only happening for $ perl5241 /tmp; echo $? and indeed the test which has been failing you, has passed thousands of
seems a bit of an over-statement. It seems far more likely that there is something up with the return value Perl_croak(aTHX_ "Can't open perl script \"%s\": %s\n", On my system, the last arg passed to croak() is a pointer the string What Strerror is #defined to depends on what Configure finds in the way $ egrep 'strerror|syserrlst|strerrm' config.sh Are you absolutely certain that on your platform, at the point that The "Is a directory" pointer is retrieved on the second execution of this Perl_sv_vcatpvfn_flags(....) At this point all that has happened is that Perl_croak() has passed its
Its not disastrous.
I doubt that it has regressed. I think its more likely that something -- |
From @jkeenanOn Tue, 11 Apr 2017 10:24:55 GMT, davem wrote:
I concur. Yesterday I took the OP's sample program and simplified it to remove all the locale-related stuff, which seemed extraneous (attached). I then built perl in 6 different configurations (3 x 2 below) and ran the program in each. Commit points: tag v5.22.3 Configure: sh ./Configure -des -Dusedevel I got the same results in all 6 cases. Here's one example: ##### In each case, I got "Is a directory" in the error message. In each case, the errno was ENOTTY rather than EISDIR. So I don't see any regression. EISDIR may, in principle, be a better errno for this situation than ENOTTY, but that's not a regression and not something we should change for 5.26.0. Thank you very much. |
From @JVD66Aha! I found & fixed the strerror problem. My 'man strerror_r' manual page says : SYNOPSIS char *strerror(int errnum); int strerror_r(int errnum, char *buf, size_t buflen); char *strerror_r(int errnum, char *buf, size_t buflen); char *strerror_l(int errnum, locale_t locale); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): strerror_r(): In my config.h, STRERROR_R_PROTO is defined to be REENTRANT_PROTO_I_IBW ; in # define strerror(a) (strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size) == 0 ? PL_reentrant_buffer->_strerror_buffer : 0) This really makes no sense for any strerror_r version - all strerror_r prototypes Also, if the XSI version is being used, then strerror_r does not return a string So here is the patch to reentr.h that fixes the problem for me (also attached): $ diff -U1 reentr.h~ reentr.h Inline Patch--- reentr.h~ 2016-07-14 19:07:47.000000000 +0000
+++ reentr.h 2017-04-11 11:49:00.793988243 +0000
@@ -1397,3 +1397,7 @@
# if !defined(strerror) && STRERROR_R_PROTO == REENTRANT_PROTO_I_IBW
-# define strerror(a) (strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size) == 0 ? PL_reentrant_buffer->_strerror_buffer : 0)
+# if ((_POSIX_C_SOURCE >= 200112L) && (!defined(_GNU_SOURCE)))
+# define strerror(a) ({ register int _str = strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size); (_str == 0) ? PL_reentrant_buffer->_strerror_buffer : NULL; })
+# else
+# define strerror(a) strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size)
+# endif
# endif
$ LD_PRELINK=${PWD}/libperl.so LD_LIBRARY_PATH=${PWD} \ PERL5LIB=${PWD}:${PWD}/lib:${PWD}/ext LANG=C LC_ALL=C \ |
From @JVD66131126_reentr_h.patch--- reentr.h~ 2016-07-14 19:07:47.000000000 +0000
+++ reentr.h 2017-04-11 11:49:00.793988243 +0000
@@ -1397,3 +1397,7 @@
# if !defined(strerror) && STRERROR_R_PROTO == REENTRANT_PROTO_I_IBW
-# define strerror(a) (strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size) == 0 ? PL_reentrant_buffer->_strerror_buffer : 0)
+# if ((_POSIX_C_SOURCE >= 200112L) && (!defined(_GNU_SOURCE)))
+# define strerror(a) ({ register int _str = strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size); (_str == 0) ? PL_reentrant_buffer->_strerror_buffer : NULL; })
+# else
+# define strerror(a) strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size)
+# endif
# endif
|
From [Unknown Contact. See original ticket]Aha! I found & fixed the strerror problem. My 'man strerror_r' manual page says : SYNOPSIS char *strerror(int errnum); int strerror_r(int errnum, char *buf, size_t buflen); char *strerror_r(int errnum, char *buf, size_t buflen); char *strerror_l(int errnum, locale_t locale); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): strerror_r(): In my config.h, STRERROR_R_PROTO is defined to be REENTRANT_PROTO_I_IBW ; in # define strerror(a) (strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size) == 0 ? PL_reentrant_buffer->_strerror_buffer : 0) This really makes no sense for any strerror_r version - all strerror_r prototypes Also, if the XSI version is being used, then strerror_r does not return a string So here is the patch to reentr.h that fixes the problem for me (also attached): $ diff -U1 reentr.h~ reentr.h Inline Patch--- reentr.h~ 2016-07-14 19:07:47.000000000 +0000
+++ reentr.h 2017-04-11 11:49:00.793988243 +0000
@@ -1397,3 +1397,7 @@
# if !defined(strerror) && STRERROR_R_PROTO == REENTRANT_PROTO_I_IBW
-# define strerror(a) (strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size) == 0 ? PL_reentrant_buffer->_strerror_buffer : 0)
+# if ((_POSIX_C_SOURCE >= 200112L) && (!defined(_GNU_SOURCE)))
+# define strerror(a) ({ register int _str = strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size); (_str == 0) ? PL_reentrant_buffer->_strerror_buffer : NULL; })
+# else
+# define strerror(a) strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size)
+# endif
# endif
$ LD_PRELINK=${PWD}/libperl.so LD_LIBRARY_PATH=${PWD} \ PERL5LIB=${PWD}:${PWD}/lib:${PWD}/ext LANG=C LC_ALL=C \ |
From @JVD66Note that with the incorrect passing of the strerror buffer as the last argument |
From [Unknown Contact. See original ticket]Note that with the incorrect passing of the strerror buffer as the last argument |
From @JVD66OK, I found & fixed the main issues here : 1) wrong prototype assumed for strerror_r perl was assuming : with the effective CFLAGS produced by config.sh : gcc -c -DPERL_CORE -g -fPIC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -fwrapv -std=c89 -mtune=native -O2 -g -fPIC -Wall -Werror=declaration-after-statement -Wextra -Wc++-compat -Wwrite-strings -fPIC perl.c ( this is how perl.c gets compiled ). From GLIBC-2.25's /usr/include/string.h : #ifdef __USE_XOPEN2K In config.h, we see : that is why the GNU prototype, that returns a const char*, gets used , The attached patch uses the GNU prototype if GNU_SOURCE is defined - If I might make a suggestion to PERL testers, a platform containing If you had compiled PERL under GLIBC 2.25, you would see same issues. So all the test failures except the ExtUtils::Install issue are fixed when PERL The ExtUtils::Install issue was because I gave the same value for '$Config{man1direxp}' as for $Config{man3direxp} - the test doesn't like it when these are the same. Sorry for confusion! This test resolved alot of issues on my system. Thanks for your time, Jason |
From @JVD66perl_bug_131126.patchdiff -up perl-5.24.1/perl.c.5.24.1 perl-5.24.1/perl.c
--- perl-5.24.1/perl.c.5.24.1 2017-01-02 17:27:54.000000000 +0000
+++ perl-5.24.1/perl.c 2017-04-11 11:04:22.064538560 +0000
@@ -3857,10 +3857,11 @@ S_open_script(pTHX_ const char *scriptna
if (fd < 0 ||
(PerlLIO_fstat(fd, &tmpstatbuf) >= 0
&& S_ISDIR(tmpstatbuf.st_mode)))
+ { register const char *em = Strerror(errno=EISDIR);
Perl_croak(aTHX_ "Can't open perl script \"%s\": %s\n",
CopFILE(PL_curcop),
- Strerror(EISDIR));
-
+ em);
+ }
return rsfp;
}
diff -up perl-5.24.1/reentr.h.5.24.1 perl-5.24.1/reentr.h
--- perl-5.24.1/reentr.h.5.24.1 2016-07-14 19:07:47.000000000 +0000
+++ perl-5.24.1/reentr.h 2017-04-11 20:27:19.314194174 +0000
@@ -1395,7 +1395,11 @@ typedef struct {
# if defined(PERL_REENTR_API) && (PERL_REENTR_API+0 == 1)
# undef strerror
# if !defined(strerror) && STRERROR_R_PROTO == REENTRANT_PROTO_I_IBW
+# if ((_POSIX_C_SOURCE >= 200112L) && (!defined(_GNU_SOURCE)))
# define strerror(a) (strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size) == 0 ? PL_reentrant_buffer->_strerror_buffer : 0)
+# else
+# define strerror(a) strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size)
+# endif
# endif
# if !defined(strerror) && STRERROR_R_PROTO == REENTRANT_PROTO_I_IBI
# define strerror(a) (strerror_r(a, PL_reentrant_buffer->_strerror_buffer, PL_reentrant_buffer->_strerror_size) == 0 ? PL_reentrant_buffer->_strerror_buffer : 0)
|
From @khwilliamsonOn 04/11/2017 02:46 PM, Jason Vas Dias via RT wrote:
Darwin uses only the int returning version. I don't see how your patch We don't use 'register' declarations in the Perl core any more. The
|
From @JVD66On Tue, 11 Apr 2017 15:02:23 -0700, public@khwilliamson.com wrote:
Yes, by all means paraphrase my patch / add the test for That patch is just what I put together to get the test I think GNU's prototype is more sensible - what is Perhaps PERL should really be backing up the value of errno - On Darwin, if using GCC, can't you use _GNU_SOURCE and You can view the string.h of GLIBC 2.25 online : you can see the const char * returning prototype is used if |
From @iabynOn Tue, Apr 11, 2017 at 01:46:53PM -0700, Jason Vas Dias via RT wrote:
Ok, the errno=EISDIR change is to fix the exit value from "perl /dir".
I think this is fixing things from the wrong end. reentr.h already # if !defined(strerror) && STRERROR_R_PROTO == REENTRANT_PROTO_B_IBW The real question is why Configure on your system is concluding that -- |
From @LeontOn Thu, Apr 13, 2017 at 10:52 AM, Dave Mitchell <davem@iabyn.com> wrote:
That's exactly what I was thinking. Leon |
From @JVD66On Fri, 14 Apr 2017 07:24:15 -0700, LeonT wrote:
Sorry I didn't see this post until now. |
From @JVD66On Fri, 14 Apr 2017 07:24:15 -0700, LeonT wrote:
OK, I can explain this now . In Configure, you are running gcc for the test programs WITHOUT _GNU_SOURCE I'm glad PERL is deciding to use _GNU_SOURCE - if it weren't, I'd have to But then it should use _GNU_SOURCE for all the Configure tests, too . I've attached an excerpt from the log produced by a clean Configure: An excerpt from the log is attached, showing the I_IBW prototype is used, |
From @JVD66STRERROR: ++ td=define |
From @JVD66And of course, that log is showing the opposite - it IS using _GNU_SOURCE ! The Configure.log from the original perl-5.24.1 build that fails shows Doing variable substitutions on .SH files... and it gets the I_IBW strerror prototype, but it does set _GNU_SOURCE in I think this was because for the version that failed, I Perhaps PERL should be making extra checks that if it is going to insert '#define _GNU_SOURCE' |
From [Unknown Contact. See original ticket]And of course, that log is showing the opposite - it IS using _GNU_SOURCE ! The Configure.log from the original perl-5.24.1 build that fails shows Doing variable substitutions on .SH files... and it gets the I_IBW strerror prototype, but it does set _GNU_SOURCE in I think this was because for the version that failed, I Perhaps PERL should be making extra checks that if it is going to insert '#define _GNU_SOURCE' |
From @LeontOn Sat, Apr 15, 2017 at 2:54 PM, Jason Vas Dias via RT
What Configure arguments are you using exactly? Leon |
Migrated from rt.perl.org#131126 (status was 'open')
Searchable as RT131126$
The text was updated successfully, but these errors were encountered: