Skip to content
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

Closed
p5pRT opened this issue Dec 10, 2017 · 12 comments

Comments

@p5pRT
Copy link

commented Dec 10, 2017

Migrated from rt.perl.org#132561 (status was 'resolved')

Searchable as RT132561$

@p5pRT

This comment has been minimized.

Copy link
Author

commented Dec 10, 2017

From p5p@perl.wizbit.be

Hi,

Building blead on an old system results in a miniperl that segfaults​:

  ./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c
'echo >&2 Failed to build miniperl. Please run make minitest; exit 1'
  Segmentation fault (core dumped)
  Failed to build miniperl. Please run make minitest
  make​: *** [lib/buildcustomize.pl] Error 1

Bisecting leads to commit

  commit c70a3e6
  Author​: Karl Williamson <khw@​cpan.org>
  Date​: Thu Sep 14 13​:32​:58 2017 -0600
 
  locale.c​: Use new nl_langinfo equivalent
 
  This converts the final plain nl_langinfo() function call in
locale.c to
  use the new equivalent that is more thread safe, and you don't
have to
  free the returned memory. There was an unlikely leak before
this, if
  the return was somehow "".
 

Building c70a3e6 with '-Doptimize=-O0
-DEBUGGING=-g' and running with gdb​:

(gdb) bt
#0 0xb7dd4bf7 in duplocale () from /lib/tls/i686/cmov/libc.so.6
#1 0x081db943 in S_my_nl_langinfo (item=14, toggle=false) at locale.c​:1322
#2 0x081dcfc9 in Perl__is_cur_LC_category_utf8 (category=0) at
locale.c​:3043
#3 0x081dab55 in S_new_ctype (newctype=0x8246650 "en_US.UTF-8") at
locale.c​:359
#4 0x081dc56c in Perl_init_i18nl10n (printwarn=1) at locale.c​:2297
#5 0x0807169d in perl_construct (my_perl=0x8239008) at perl.c​:299
#6 0x081ed04a in main (argc=2, argv=0xbfb7b444, env=0xbfb7b450) at
miniperlmain.c​:123

(gdb) bt full
#0 0xb7dd4bf7 in duplocale () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#1 0x081db943 in S_my_nl_langinfo (item=14, toggle=false) at locale.c​:1322
  do_free = false
  cur = (locale_t) 0xffffffff
#2 0x081dcfc9 in Perl__is_cur_LC_category_utf8 (category=0) at
locale.c​:3043
  codeset = 0xb7f9f866 "\212\0309"
  save_ctype_locale = 0x0
  is_utf8 = false
  save_input_locale = 0x8246680 "en_US.UTF-8"
  final_pos = 17301504
#3 0x081dab55 in S_new_ctype (newctype=0x8246650 "en_US.UTF-8") at
locale.c​:359
  i = 3085820661
#4 0x081dc56c in Perl_init_i18nl10n (printwarn=1) at locale.c​:2297
  ok = 1
  curctype = 0x8246650 "en_US.UTF-8"
  curcoll = 0x8246660 "en_US.UTF-8"
  curnum = 0x8246670 "en_US.UTF-8"
  language = 0x0
  setlocale_init = 0x822efa8 ""
  trial_locales = {0x822efa8 "", 0x8049d8d "close", 0x99 <Address
0x99 out of bounds>, 0x0,
  0x8231380
"ÐIø·*µ\004\b​:µ\004\bJµ\004\bZµ\004\bjµ\004\bzµ\004\b\212µ\004\b\232µ\004\bªµ\004\b
ìá·Êµ\004\bÚµ\004\bêµ\004\búµ\004\b\n¶\004\b\032¶\004\b*¶\004\b​:¶\004\bJ¶\004\bZ¶\004\bj¶\004\bz¶\004\b\212¶\004\b\232¶\004\bª¶\004\bº¶\004\bʶ\004\bÚ¶\004\bê¶\004\b@​Dâ·\n·\004\b\032·\004\b*·\004\b​:·\004\bJ·\004\bZ·\004\bj·\004\bz·\004\b\212·\004\b\232·\004\bª·\004\bº·\004\bÊ·\004\bÚ·\004\bê·\004\bú·\004\b\n¸\004\b\032¸\004\b*¸\004\b"...}
  trial_locales_count = 1
  lc_all = 0x0
  lang = 0x8240588 "en_US.UTF-8"
  setlocale_failure = false
  i = 0
  bad_lang_use_once = 0x0
  locwarn = true
  done = false
  sl_result = 0x8244890 "en_US.UTF-8"
  locale_param = 0x3f7 <Address 0x3f7 out of bounds>
#5 0x0807169d in perl_construct (my_perl=0x8239008) at perl.c​:299
No locals.
#6 0x081ed04a in main (argc=2, argv=0xbfb7b444, env=0xbfb7b450) at
miniperlmain.c​:123
  exitstatus = -1208267344
  i = 136237401

Running current blead (c9ffefc)​:
(gdb) bt full
#0 0xb7dadbf7 in duplocale () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#1 0x081dcbd2 in S_my_nl_langinfo (item=14, toggle=false) at locale.c​:1309
  do_free = false
  cur = (locale_t) 0xffffffff
#2 0x081de1ab in Perl__is_cur_LC_category_utf8 (category=0) at
locale.c​:2906
  codeset = 0xb7f78866 "\212\0309"
  save_ctype_locale = 0x0
  is_utf8 = false
  save_input_locale = 0x82476b0 "en_US.UTF-8"
  final_pos = 17301504
#3 0x081dbde0 in S_new_ctype (newctype=0x8247660 "en_US.UTF-8") at
locale.c​:486
  i = 3085660917
#4 0x081dd734 in Perl_init_i18nl10n (printwarn=1) at locale.c​:2170
  ok = 1
  language = 0x0
  setlocale_init = 0x822f710 ""
  trial_locales = {0x822f710 "", 0x99 <Address 0x99 out of
bounds>, 0x0,
  0x82325f8
"ÐÙõ·Jµ\004\bZµ\004\bjµ\004\bzµ\004\b\212µ\004\b\232µ\004\bªµ\004\bºµ\004\bʵ\004\b
|ß·êµ\004\búµ\004\b\n¶\004\b\032¶\004\b*¶\004\b​:¶\004\bJ¶\004\bZ¶\004\bj¶\004\bz¶\004\b\212¶\004\b\232¶\004\bª¶\004\bº¶\004\bʶ\004\bÚ¶\004\bê¶\004\bú¶\004\b\n·\004\b@​Ôß·*·\004\b​:·\004\bJ·\004\bZ·\004\bj·\004\bz·\004\b\212·\004\b\232·\004\bª·\004\bº·\004\bÊ·\004\bÚ·\004\bê·\004\bú·\004\b\n¸\004\b\032¸\004\b*¸\004\b​:¸\004\bJ¸\004\b"...,
0x1 <Address 0x1 out of bounds>}
  trial_locales_count = 1
  lc_all = 0x0
  lang = 0x8241588 "en_US.UTF-8"
  setlocale_failure = false
  i = 0
  bad_lang_use_once = 0x0
  locwarn = true
  done = false
  sl_result = {0xbf80ff70 "¸ÿ\200¿@​,ù·\004", 0xb7f8d419
"\203ì\024\211Æe¡\f", 0xb7f9b820 "Ä·ù·", 0xb7f38e98
"\237 \004\b\020ii\r", 0x1 <Address 0x1 out of bounds>,
  0x1 <Address 0x1 out of bounds>, 0x8247640 "en_US.UTF-8"}
  curlocales = {0x8247650 "en_US.UTF-8", 0x8247660 "en_US.UTF-8",
0x8247670 "en_US.UTF-8", 0x8247680 "en_US.UTF-8", 0x8247690
"en_US.UTF-8", 0x82476a0 "en_US.UTF-8",
  0xb7f9b668 ""}
  locale_param = 0xce9a <Address 0xce9a out of bounds>
#5 0x08071775 in perl_construct (my_perl=0x823a008) at perl.c​:300
No locals.
#6 0x081ed476 in main (argc=2, argv=0xbf8100d4, env=0xbf8100e0) at
miniperlmain.c​:123
  exitstatus = -1208427088
  i = 136238473

Best regards,

Bram

@p5pRT

This comment has been minimized.

Copy link
Author

commented Dec 12, 2017

From @jkeenan

On Sun, 10 Dec 2017 21​:06​:01 GMT, p5p@​perl.wizbit.be wrote​:

Hi,

Building blead on an old system results in a miniperl that segfaults​:

./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c
'echo >&2 Failed to build miniperl. Please run make minitest; exit 1'

[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.
--
James E Keenan (jkeenan@​cpan.org)

@p5pRT

This comment has been minimized.

Copy link
Author

commented Dec 12, 2017

The RT System itself - Status changed from 'new' to 'open'

@p5pRT

This comment has been minimized.

Copy link
Author

commented Dec 15, 2017

From p5p@spam.wizbit.be

On Mon, 11 Dec 2017 16​:45​:20 -0800, jkeenan wrote​:

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?

Attaching output of ./myconfig from build directory​:

Summary of my perl5 (revision 5 version 27 subversion 6) configuration​:
 
  Platform​:
  osname=linux
  osvers=2.6.24.3-custom-hm
  archname=i686-linux
  uname='linux bram 2.6.24.3-custom-hm #1 smp fri oct 10 16​:32​:21 cest 2008 i686 gnulinux '
  config_args='-des -Dusedevel -Doptimize=-O0 -DEBUGGING=-g'
  hint=recommended
  useposix=true
  d_sigaction=define
  useithreads=undef
  usemultiplicity=undef
  use64bitint=undef
  use64bitall=undef
  uselongdouble=undef
  usemymalloc=n
  default_inc_excludes_dot=define
  bincompat5005=undef
  Compiler​:
  cc='cc'
  ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
  optimize='-O0 -g'
  cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion=''
  gccversion='4.2.4'
  gccosandvers=''
  intsize=4
  longsize=4
  ptrsize=4
  doublesize=8
  byteorder=1234
  doublekind=3
  d_longlong=define
  longlongsize=8
  d_longdbl=define
  longdblsize=12
  longdblkind=3
  ivtype='long'
  ivsize=4
  nvtype='double'
  nvsize=8
  Off_t='off_t'
  lseeksize=8
  alignbytes=4
  prototype=
  Linker and Libraries​:
  ld='cc'
  ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib /lib/../lib /usr/lib/../lib /lib /usr/lib64
  libs=-lpthread -lnsl -ldb -ldl -lm -lcrypt -lutil -lc
  perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.7.so
  so=so
  useshrplib=false
  libperl=libperl.a
  gnulibc_version='2.7'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs
  dlext=so
  d_dlsymun=undef
  ccdlflags='-Wl,-E'
  cccdlflags='-fPIC'
  lddlflags='-shared -O0 -g -L/usr/local/lib -fstack-protector'

@p5pRT

This comment has been minimized.

Copy link
Author

commented Dec 21, 2017

From @khwilliamson

Based 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.
--
Karl Williamson

@p5pRT

This comment has been minimized.

Copy link
Author

commented Feb 22, 2018

From @khwilliamson

So, 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

--
Karl Williamson

@p5pRT

This comment has been minimized.

Copy link
Author

commented Feb 22, 2018

From @tonycoz

On Thu, Feb 22, 2018 at 01​:42​:24PM -0800, Karl Williamson via RT wrote​:

So, 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

It's more likely to depend on the glibc version than the kernel
version.

Also, some Linux distributions use an alternate libc.

Tony

@p5pRT

This comment has been minimized.

Copy link
Author

commented Feb 22, 2018

From @khwilliamson

On 02/22/2018 02​:59 PM, Tony Cook wrote​:

On Thu, Feb 22, 2018 at 01​:42​:24PM -0800, Karl Williamson via RT wrote​:

So, 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

It's more likely to depend on the glibc version than the kernel
version.

Also, some Linux distributions use an alternate libc.

Tony

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.

@p5pRT

This comment has been minimized.

Copy link
Author

commented Feb 22, 2018

From @khwilliamson

On 02/22/2018 03​:18 PM, Karl Williamson wrote​:

On 02/22/2018 02​:59 PM, Tony Cook wrote​:

On Thu, Feb 22, 2018 at 01​:42​:24PM -0800, Karl Williamson via RT wrote​:

So, 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

It's more likely to depend on the glibc version than the kernel
version.

Also, some Linux distributions use an alternate libc.

Tony

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.

I misread my version as 2.4; not 2.24, so it does make sense. Anyway
does anyone have an earlier version of glibc where it does work than 2.24?

@p5pRT

This comment has been minimized.

Copy link
Author

commented Feb 22, 2018

From @tonycoz

On Thu, Feb 22, 2018 at 03​:52​:16PM -0700, Karl Williamson wrote​:

On 02/22/2018 03​:18 PM, Karl Williamson wrote​:

On 02/22/2018 02​:59 PM, Tony Cook wrote​:

On Thu, Feb 22, 2018 at 01​:42​:24PM -0800, Karl Williamson via RT wrote​:

So, 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

It's more likely to depend on the glibc version than the kernel
version.

Also, some Linux distributions use an alternate libc.

Tony

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.

I misread my version as 2.4; not 2.24, so it does make sense. Anyway does
anyone have an earlier version of glibc where it does work than 2.24?

https://sourceware.org/bugzilla/show_bug.cgi?id=10969

Apparently fixed in 2.12​:

https://github.com/lattera/glibc/blob/master/NEWS

Tony

@p5pRT

This comment has been minimized.

Copy link
Author

commented Mar 8, 2018

From @khwilliamson

OP indicates that e9bc6d6 fixed this for threaded builds
and ee90eb2 for non-threaded.

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.

--
Karl Williamson

@p5pRT

This comment has been minimized.

Copy link
Author

commented Mar 8, 2018

@khwilliamson - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this Mar 8, 2018
@p5pRT p5pRT added the Severity Low label Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.