New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
miniperl segfault on blead (duplocale / S_my_nl_langinfo) #16298
Comments
From p5p@perl.wizbit.beHi, Building blead on an old system results in a miniperl that segfaults: ./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c Bisecting leads to commit commit c70a3e6 Building c70a3e6 with '-Doptimize=-O0 (gdb) bt (gdb) bt full Running current blead (c9ffefc): Best regards, Bram |
From @jkeenanOn Sun, 10 Dec 2017 21:06:01 GMT, p5p@perl.wizbit.be wrote:
[snip output] You say this segfaults on an "old system". Can you attach the output of 'perl -Ilib -V' from your attempt to compile and build perl on that system? Thank you very much. |
The RT System itself - Status changed from 'new' to 'open' |
From p5p@spam.wizbit.beOn Mon, 11 Dec 2017 16:45:20 -0800, jkeenan wrote:
Attaching output of ./myconfig from build directory: Summary of my perl5 (revision 5 version 27 subversion 6) configuration: |
From @khwilliamsonBased on previous experience with *bsd, my guess is that the implementation of the POSIX 2008 locale ops was defective initially, and fixed in later Unixes. Thus this would be resolved by a hints file fix, like Jim recently did for one of those. |
From @khwilliamsonSo, this should have a hints file change for Linux, that says certain earlier versions should not use the Posix 2008 functions, even if they are present. This is because they've been found to be buggy. The problem is I don't know what the cut-off version should be. I know it works on 4.10, and it doesn't work on 2.6.24. But what should the hints file use? Suggestions for how to determine this are welcome. Or, if you have an example of it working on an earlier version than 4.10, post it, so that we can narrow it down. Given that there is no further reports of failure, I'm presuming nobody has an example of it failing after 2.6.24, and so I'm tempted to make that the cut-off, unless further information and/or suggestions are received -- |
From @tonycozOn Thu, Feb 22, 2018 at 01:42:24PM -0800, Karl Williamson via RT wrote:
It's more likely to depend on the glibc version than the kernel Also, some Linux distributions use an alternate libc. Tony |
From @khwilliamsonOn 02/22/2018 02:59 PM, Tony Cook wrote:
Good points. However, the output in this ticket says that bram is using gnulibc_version='2.7' and that is failing; whereas I'm using gnulibc_version='2.24' on a much later Linux and it is working. I don't understand. |
From @khwilliamsonOn 02/22/2018 03:18 PM, Karl Williamson wrote:
I misread my version as 2.4; not 2.24, so it does make sense. Anyway |
From @tonycozOn Thu, Feb 22, 2018 at 03:52:16PM -0700, Karl Williamson wrote:
https://sourceware.org/bugzilla/show_bug.cgi?id=10969 Apparently fixed in 2.12: https://github.com/lattera/glibc/blob/master/NEWS Tony |
From @khwilliamsonOP indicates that e9bc6d6 fixed this for threaded builds Discussion on this ticket has indicated a likely cause of this to be a broken duplocale() in glibc, fixed in 2.12. There is currently a probe for nl_langinfo_l that goes to the bother of verifying that the implementation is indeed actually thread safe, since the POSIX 2008 standard allows some unsafe behavior (while still claiming to be thread-safe). Apparently that probe fails until duplocale has been fixed. I still intend to fix the duplocale probe to do a basic test beyond mere existence. -- |
@khwilliamson - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#132561 (status was 'resolved')
Searchable as RT132561$
The text was updated successfully, but these errors were encountered: