JeffIrwin / syntran

An interpreter written in Fortran, I guess
BSD 3-Clause "New" or "Revised" License
13 stars 1 forks source link

syntran crashes on Windows intermittently #16

Open JeffIrwin opened 1 month ago

JeffIrwin commented 1 month ago

When running syntran on Windows, it will crash rarely and intermittently, maybe 10% of the time or less, with a segfault and invalid memory reference shown below.

Re-running the same syntran file will usually succeed. The bug is not consistent.

For example, running the 2023 aoc suite with the 0.0.49 release will crash sometimes. It's strange that the main function finishes and syntran prints the final return value before crashing. Maybe the crash occurs during a final deallocation. You can tell from the run.sh script output that it does not enter the next directory before the crash.

I see similar failures when building from source on Windows, e.g. fpm test test. Even under the (default) debug profile, I can't get a meaningful stack trace.

Workaround

Run a Linux binary inside of WSL instead of the native Windows executable. Only Windows is affected. Linux has proved extremely reliable, at least with the supported compilers (gfortran 10 through 12).

Log

/c/git/syntran/src/tests/long/aoc/2023
dir = 07
/c/git/syntran/src/tests/long/aoc/2023/07 /c/git/syntran/src/tests/long/aoc/2023

 syntran 0.0.49
 https://github.com/JeffIrwin/syntran

 Interpreting file "main.syntran"

Starting AOC syntran main 2023/07
part 1 = 250453939
part 2 = 248652697
Ending AOC syntran main

     499106636

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x93d390ba
#1  0x93cae913
#2  0xaeab0871
#3  0xdd47eff
#4  0x109b504e
#5  0x1092e865
#6  0x109b403d
#7  0xdd11c3f
#8  0xdd11b38
#9  0xdd119f8
#10  0xdd11297
#11  0xdd11239
#12  0xdd111f6
#13  0x93d50a03
#14  0x93d3dbdf
#15  0xae5a42b7
#16  0xae5a4659
#17  0xae5a12ee
#18  0xae5a1405
#19  0x1071257c
#20  0x1096af27
#21  0xffffffff
JeffIrwin commented 1 month ago

As of the introduction of structs in https://github.com/JeffIrwin/syntran/commit/b5603a3782253f058d28fcd041c126e0dcad4795, the frequency of this issue seems to be significantly reduced, but still not 100% fixed

Re-running fpm test test 1000 times in https://github.com/JeffIrwin/syntran/commit/42a08512d3915c28520fb5a9402b9c18998bf503, I see about 40 crashes. Given that the whole test suite executed by fpm test test contains 1404 unit tests as of that commit, that's a failure rate of 40 / (1000 1404) ~= 3e-5 = 0.003% per syntran_eval() call. Crash frequency is roughly the same in debug and release. That's not terrible, but I still wouldn't use Windows syntran in a car or a hospital

I think it improved because of the addition of the fn_t copy constructor fn_copy. Perhaps other types need manually defined copy constructors for the complete resolution of this bug

* when you run a whole syntran script with a command-line like syntran.exe file.syntran, that's a single syntran_eval() call, regardless of the size or complexity of the script file