Bug 2219085

Summary: Maxima segfaults with SBCL and GCL runtimes
Product: [Fedora] Fedora Reporter: James <james>
Component: maximaAssignee: Rex Dieter <rdieter>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 38CC: jamatos, rdieter
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-05-28 13:18:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description James 2023-07-01 20:39:52 UTC
maxima-5.45.1-4.fc38.x86_64
maxima-runtime-sbcl-5.45.1-4.fc38.x86_64
maxima-runtime-gcl-5.45.1-4.fc38.x86_64

Maxima segfaults when using the sbcl or gcl runtimes. It's fine under ecl or clisp.

sbcl segfaults around 1 in 5 times, but not completely deterministically. The coredumpctl debug backtrace never has much in it, though.

gcl segfaults consistently:

#0  0x0000000000081bae in make_simple_string (s=s@entry=0x37bd6b "free(3) error.")
    at /usr/src/debug/gcl-2.6.13-1.fc38.x86_64/o/string.d:70
Downloading source file /usr/src/debug/gcl-2.6.13-1.fc38.x86_64/o/string.d
70                      p[i] = s[i];                                                                                                
(gdb) bt
#0  0x0000000000081bae in make_simple_string (s=s@entry=0x37bd6b "free(3) error.")
    at /usr/src/debug/gcl-2.6.13-1.fc38.x86_64/o/string.d:70
#1  0x0000000000033755 in free (ptr=ptr@entry=0x5fda1d8) at alloc.c:1698
#2  0x00007f7f5e07288f in selinuxfs_exists () at /usr/src/debug/libselinux-3.5-1.fc38.x86_64/src/init.c:77
#3  0x00007f7f5e06d36c in init_selinuxmnt () at /usr/src/debug/libselinux-3.5-1.fc38.x86_64/src/init.c:97
#4  init_lib () at /usr/src/debug/libselinux-3.5-1.fc38.x86_64/src/init.c:150
#5  0x00007f7f5e7d117f in call_init (env=0x7ffe85c3db20, argv=0x7ffe85c3dae8, argc=6, l=<optimized out>) at dl-init.c:70
#6  call_init (l=<optimized out>, argc=6, argv=0x7ffe85c3dae8, env=0x7ffe85c3db20) at dl-init.c:26
#7  0x00007f7f5e7d127d in _dl_init (main_map=0x7f7f5e8002c0, argc=6, argv=0x7ffe85c3dae8, env=0x7ffe85c3db20) at dl-init.c:117
#8  0x00007f7f5e7e73e0 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#9  0x0000000000000006 in ?? ()
#10 0x00007ffe85c3fd3e in ?? ()
#11 0x00007ffe85c3fd69 in ?? ()
#12 0x00007ffe85c3fd6f in ?? ()
#13 0x00007ffe85c3fd7e in ?? ()
#14 0x00007ffe85c3fd81 in ?? ()
#15 0x00007ffe85c3fd84 in ?? ()
#16 0x0000000000000000 in ?? ()




Reproducible: Always

Steps to Reproduce:
1. Start maxima with --lisp=sbcl or --lisp=gcl
Actual Results:  
Segfault.

Expected Results:  
Working session.

Comment 1 James 2023-07-01 21:32:06 UTC
OK so there seems some variability based on the hardware used. I see trouble on:

Ryzen 7 5700G, 32GiB RAM
i3-1005G1 laptop, 16GiB RAM

But the following machines work OK with sbcl/gcl:

i5-10210U laptop, 16GiB RAM
i5-4670 desktop, 8GiB RAM

All up-to-date Fedora 38. Not sure what else distinguishes these machines, other than the working ones have older silicon.

Comment 2 José Matos 2024-02-16 17:29:21 UTC
Do you still see this problem?

I have no problems with AMD Ryzen 7 4800H, 32 GiB RAM, laptop.

You can also use the ecl backend: --lisp=ecl

Comment 3 Aoife Moloney 2024-05-28 13:18:19 UTC
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.