Perl 5.32 segfaults on Linux/m68k (regression)

[glaubitz]

Hi!

Perl 5.32 has introduced a regression which results in miniperl segfaulting during build.

The backtrace with gdb looks like this:

root@pacman:/srv/perl2/perl-5.32.0~rc1/build-static# gdb --args ./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 Failed to build miniperl.  Please run make mint/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 Failed to build miniperl.  Please run make mininiperl.  Please run make minitminiperl.  Please run make minitest; exit 1'


GNU gdb (Debian 9.2-1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "m68k-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./miniperl...
(gdb) r
Starting program: /srv/perl2/perl-5.32.0~rc1/build-static/miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e \<\?\>
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/m68k-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
S_link_freed_op (o=0x803120aa, slab=<optimized out>, slab=<optimized out>, 
    my_perl=0x8030a190) at op.c:269
269         if (!slab->opslab_freed) {
(gdb) bt
#0  S_link_freed_op (o=0x803120aa, slab=<optimized out>, slab=<optimized out>, 
    my_perl=0x8030a190) at op.c:269
#1  0x8000901e in Perl_Slab_Free (op=0x80312136, my_perl=0x8030a190)
    at op.c:505
#2  Perl_Slab_Free (my_perl=0x8030a190, op=0x803120aa) at op.c:484
#3  0x8000fae6 in S_op_destroy (o=<optimized out>, my_perl=<optimized out>)
    at op.c:6416
#4  Perl_op_append_list (type=<optimized out>, last=<optimized out>, 
    first=0x80312136, my_perl=<optimized out>) at op.c:6416
#5  Perl_op_append_list (my_perl=<optimized out>, type=<optimized out>, 
    first=<optimized out>, last=<optimized out>) at op.c:6397
#6  0x800625c8 in Perl_yyparse (my_perl=0x8030a190, gramtype=258)
    at perly.y:239
#7  0x800321fe in S_parse_body (xsinit=0x801885f8 <xs_init>, env=0x0, 
    my_perl=0x8030a190) at perl.c:2576
#8  perl_parse (my_perl=0x8030a190, xsinit=0x801885f8 <xs_init>, argc=7, 
    argv=0xeffffc14, env=0x0) at perl.c:1871
#9  0x800050ae in main (argc=<optimized out>, argv=<optimized out>, 
    env=<optimized out>) at miniperlmain.c:132
(gdb)

A wild guess is that might be an alignment issue as the natural alignment for m68k is 16 bits, not 32 bits.

CC @AndreasSchwab @karcherm

[jkeenan]

On 6/18/20 6:10 AM, John Paul Adrian Glaubitz wrote: Hi! Perl 5.32 has introduced a regression which results in |miniperl| segfaulting during build. The backtrace with |gdb| looks like this: ***@***.***:/srv/perl2/perl-5.32.0~rc1/build-static# gdb --args ./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 Failed to build miniperl. Please run make mint/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 Failed to build miniperl. Please run make mininiperl. Please run make minitminiperl. Please run make minitest; exit 1' GNU gdb (Debian 9.2-1) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "m68k-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./miniperl... (gdb) r Starting program: /srv/perl2/perl-5.32.0~rc1/build-static/miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e \<\?\> [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/m68k-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. S_link_freed_op (o=0x803120aa, slab=<optimized out>, slab=<optimized out>, my_perl=0x8030a190) at op.c:269 269 if (!slab->opslab_freed) { (gdb) bt #0 S_link_freed_op (o=0x803120aa, slab=<optimized out>, slab=<optimized out>, my_perl=0x8030a190) at op.c:269 #1 0x8000901e in Perl_Slab_Free (op=0x80312136, my_perl=0x8030a190) at op.c:505 #2 Perl_Slab_Free (my_perl=0x8030a190, op=0x803120aa) at op.c:484 #3 0x8000fae6 in S_op_destroy (o=<optimized out>, my_perl=<optimized out>) at op.c:6416 #4 Perl_op_append_list (type=<optimized out>, last=<optimized out>, first=0x80312136, my_perl=<optimized out>) at op.c:6416 #5 Perl_op_append_list (my_perl=<optimized out>, type=<optimized out>, first=<optimized out>, last=<optimized out>) at op.c:6397 #6 0x800625c8 in Perl_yyparse (my_perl=0x8030a190, gramtype=258) at perly.y:239 #7 0x800321fe in S_parse_body (xsinit=0x801885f8 <xs_init>, env=0x0, my_perl=0x8030a190) at perl.c:2576 #8 perl_parse (my_perl=0x8030a190, xsinit=0x801885f8 <xs_init>, argc=7, argv=0xeffffc14, env=0x0) at perl.c:1871 #9 0x800050ae in main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at miniperlmain.c:132 (gdb) | A wild guess is that might be an alignment issue as the natural alignment for m68k is 16 bits, not 32 bits. CC @AndreasSchwab <https://github.com/AndreasSchwab> @karcherm <https://github.com/karcherm>

Please supply the way you invoked 'sh ./Configure' to achieve these results. Example: ##### sh ./Configure -des -Dusedevel -Duseithreads ##### Thank you very much. Jim Keenan

[glaubitz]

Hi Jim! Thanks for your answer.

The full build log can be found in: https://buildd.debian.org/status/fetch.php?pkg=perl&arch=m68k&ver=5.32.0%7Erc1-1&stamp=1592359772&raw=0

From the Debian process, it looks like the configure script is invoked as:

/bin/sh debian/config.debian --static

I'm currently bisecting the git tree from upstream now to see if I can find the commit in question that broke the build.

[jkeenan]

On 6/18/20 6:10 AM, John Paul Adrian Glaubitz wrote: Hi! Perl 5.32 has introduced a regression which results in |miniperl| segfaulting during build. The backtrace with |gdb| looks like this: ***@***.***:/srv/perl2/perl-5.32.0~rc1/build-static# gdb --args ./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 Failed to build miniperl. Please run make mint/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 Failed to build miniperl. Please run make mininiperl. Please run make minitminiperl. Please run make minitest; exit 1' GNU gdb (Debian 9.2-1) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "m68k-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./miniperl... (gdb) r Starting program: /srv/perl2/perl-5.32.0~rc1/build-static/miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e \<\?\> [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/m68k-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. S_link_freed_op (o=0x803120aa, slab=<optimized out>, slab=<optimized out>, my_perl=0x8030a190) at op.c:269 269 if (!slab->opslab_freed) { (gdb) bt #0 S_link_freed_op (o=0x803120aa, slab=<optimized out>, slab=<optimized out>, my_perl=0x8030a190) at op.c:269 #1 0x8000901e in Perl_Slab_Free (op=0x80312136, my_perl=0x8030a190) at op.c:505 #2 Perl_Slab_Free (my_perl=0x8030a190, op=0x803120aa) at op.c:484 #3 0x8000fae6 in S_op_destroy (o=<optimized out>, my_perl=<optimized out>) at op.c:6416 #4 Perl_op_append_list (type=<optimized out>, last=<optimized out>, first=0x80312136, my_perl=<optimized out>) at op.c:6416 #5 Perl_op_append_list (my_perl=<optimized out>, type=<optimized out>, first=<optimized out>, last=<optimized out>) at op.c:6397 #6 0x800625c8 in Perl_yyparse (my_perl=0x8030a190, gramtype=258) at perly.y:239 #7 0x800321fe in S_parse_body (xsinit=0x801885f8 <xs_init>, env=0x0, my_perl=0x8030a190) at perl.c:2576 #8 perl_parse (my_perl=0x8030a190, xsinit=0x801885f8 <xs_init>, argc=7, argv=0xeffffc14, env=0x0) at perl.c:1871 #9 0x800050ae in main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at miniperlmain.c:132 (gdb) | A wild guess is that might be an alignment issue as the natural alignment for m68k is 16 bits, not 32 bits. CC @AndreasSchwab <https://github.com/AndreasSchwab> @karcherm <https://github.com/karcherm>

Thank you for this report and especially for the backtrace. When I first read this ticket, I had no idea what "Linux/m68k" was. Eventually I found this page, http://www.linux-m68k.org/index.html, which informed me that this was a project to port Linux to the Motorola 68000 series of microprocessors. That page appears to have been last updated around 2002. Searching our issue queue for https://github.com/Perl/perl5/issues?q=m68k+in%3Atitle, it appears this is the first bug report we've had for this platform since 2003. And, AFAICT, we have never received a smoke-test report for m68k at http://perl5.test-smoke.org/. Questions: * Probably the only way we could identify the commit which broke this build would be to run Porting/bisect.pl on the machine where you observed this failure. Is that at all feasible? * To continue to support perl on this platform going forward, we would need to have regular smoke-test reports? Would that be feasible? * Does this architecture have sufficient use in production to warrant an attempt to maintain perl on it? Thank you very much. Jim Keenan

[glaubitz]

When I first read this ticket, I had no idea what "Linux/m68k" was.
Eventually I found this page, http://www.linux-m68k.org/index.html,
which informed me that this was a project to port Linux to the Motorola
68000 series of microprocessors. That page appears to have been last
updated around 2002.

We are maintaining it in Debian, see: https://buildd.debian.org/status/architecture.php?a=m68k&suite=sid

Searching our issue queue for
https://github.com/Perl/perl5/issues?q=m68k+in%3Atitle, it appears this
is the first bug report we've had for this platform since 2003.

It might just have worked well all the time :).

Probably the only way we could identify the commit which broke this
build would be to run Porting/bisect.pl on the machine where you
observed this failure. Is that at all feasible?

Sure. It's also reproducible in QEMU. You can easily install Debian/m68k on QEMU, see: https://wiki.debian.org/M68k/QemuSystemM68k

To continue to support perl on this platform going forward, we would
need to have regular smoke-test reports? Would that be feasible?

Depends on what you mean with regular. People are maintaining Linux (and NetBSD) on classic computers in their free time. So if you are asking for a weekly CI run, it might be a bit too much.

Does this architecture have sufficient use in production to warrant an
attempt to maintain perl on it?

It's used by the community who are maintaining Linux and NetBSD for older architectures.

In any case, Perl doesn't have any architecture-specific bits, does it? And it just seems there is a minor regression to me, so I don't think it would take much effort to fix this problem.

[Leont]

From the Debian process, it looks like the configure script is invoked as:

./perl -Ilib -V:config_args should also give the required information if you can get that far. Otherwise you could peek into lib/Config_heavy.pl and look for "config_args".

I'm currently bisecting the git tree from upstream now to see if I can find the commit in question that broke the build.

I would guess it to be 7b85c12 (only change in that area at first glance), @iabyn do you have a clue?

[glaubitz]

I have bisected the problematic commit to be 0bd6eef.

Reverting it, fixes Perl for me on m68k.

[glaubitz]

It's the alignment of opslot that causes the segmentation fault.

This fixes the problem for me:

diff --git a/op.h b/op.h
index fc21f03cda..480c95245b 100644
--- a/op.h
+++ b/op.h
@@ -698,7 +698,7 @@ struct opslot {
     U16         opslot_size;        /* size of this slot (in pointers) */
     U16         opslot_offset;      /* offset from start of slab (in ptr units) */
     OP         opslot_op;              /* the op itself */
-};
+} __attribute__ ((aligned (4)));
 
 struct opslab {
     OPSLAB *   opslab_next;            /* next slab */

The native alignment on m68k is 16 bits.

[glaubitz]

Alternatively, one should be able to add a padding variable of type U16 in the struct.

[iabyn]

On Thu, Jun 18, 2020 at 12:37:29PM -0700, John Paul Adrian Glaubitz wrote: It's the alignment of ```opslot``` that causes the segmentation fault.

In what way exactly is the compiler getting the alignment wrong?

…

-- Fire extinguisher (n) a device for holding open fire doors.

[jkeenan]

On 6/18/20 3:18 PM, John Paul Adrian Glaubitz wrote: I have bisected the problematic commit to be 0bd6eef <0bd6eef>. Reverting it, fixes Perl for me on m68k.

In the core distribution I have created branch 'smoke-me/jkeenan/gh-17871-m68k' to make this patch available for smoke-testing. Glaubnitz, if you could provide us (off-list) with an appropriate email-address, that would facilitate our listing you properly in AUTHORS. Thank you very much. Jim Keenan

[glaubitz]

The native alignment on m68k is 16 bits, not 32 bits, i.e. what you would expect from a 32-bits architecture.

[jkeenan]

@tonycoz Can you take a look? Thanks.