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

Segfault on 32-bit bytecode systems #164

Closed
jamesjer opened this issue Nov 23, 2021 · 2 comments
Closed

Segfault on 32-bit bytecode systems #164

jamesjer opened this issue Nov 23, 2021 · 2 comments

Comments

@jamesjer
Copy link
Contributor

I attempted to build polyml 5.9 for Fedora, but Tests/Succeed/Test160.ML segfaulted on the 32-bit ARM builder. Since that platform is the only 32-bit bytecode platform we build for, I tried passing --disable-native-codegeneration to configure on the 32-bit x86 builder to see if the crash is ARM-specific. It, too, segfaulted, so this seems to be a generic issue with 32-bit bytecode systems. This is what gdb has to say:

(gdb) run --script Tests/Succeed/Test160.ML
Thread 7 "poly" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf587cac0 (LWP 96)]
0xf7f52292 in PolyObject::Get (i=0, this=<optimized out>) at /builddir/build/BUILD/polyml-5.9/libpolyml/globals.h:309
309	    PolyWord Get(POLYUNSIGNED i) const { return ((PolyWord*)this)[i]; }
(gdb) bt 
#0  0xf7f52292 in PolyObject::Get (i=0, this=<optimized out>)
    at /builddir/build/BUILD/polyml-5.9/libpolyml/globals.h:309
#1  ByteCodeInterpreter::RunInterpreter (this=<optimized out>, taskData=<optimized out>)
    at /builddir/build/BUILD/polyml-5.9/libpolyml/bytecode.cpp:846
#2  0xf7f77429 in IntTaskData::EnterPolyCode (this=0x83dc140)
    at /builddir/build/BUILD/polyml-5.9/libpolyml/interpreter.cpp:293
#3  NewThreadFunction (parameter=0x83dc140) at /builddir/build/BUILD/polyml-5.9/libpolyml/processes.cpp:1253
#4  0xf7dc1966 in start_thread (arg=<optimized out>) at pthread_create.c:434
#5  0xf7e4796c in clone3 () at ../sysdeps/unix/sysv/linux/i386/clone3.S:111

Given the comment on line 28 of Test160.ML about overflow, I tried defining just the random function, then ran "doFor random 100;". That triggered the segfault. I've been able to reduce it to this:

> Real.toInt IEEEReal.TO_NEGINF 1000000000.0;
val it = 1000000000: int
> Real.toInt IEEEReal.TO_NEGINF 1000000001.0;
Segmentation fault (core dumped)
@dcjm dcjm closed this as completed in 020d4d7 Nov 23, 2021
@dcjm
Copy link
Contributor

dcjm commented Nov 23, 2021

Thanks for reporting it and narrowing it down. The interpreter wasn't generating the Overflow exception properly in Real.toInt. This bug was also present in the 64-bit interpreter; it just wasn't triggered by this test. I'll add this fix to the fixes branch shortly.

@jamesjer
Copy link
Contributor Author

Thank you for the quick fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants