Segfault (Bad permissions for mapped region at address 0x1E201D) on startup of cli-platform examples

[Qqwy]

The problem occurs when running e.g.

cargo run -- build ./examples/interactive/countdown.roc
valgrind ./examples/interactive/countdown

Valgrind output:

==596170== Memcheck, a memory error detector
==596170== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==596170== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==596170== Command: ./examples/interactive/countdown
==596170== 
==596170== 
==596170== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==596170==  Bad permissions for mapped region at address 0x1E201D
==596170==    at 0x1E201D: ??? (in /run/media/qqwy/Serendipity/Programming/Personal/roc/roc/examples/interactive/countdown)
==596170==    by 0x400248F: ??? (in /nix/store/rir9pf0kz1mb84x5bd3yr0fx415yy423-glibc-2.33-123/lib/ld-2.33.so)
==596170== 
==596170== HEAP SUMMARY:
==596170==     in use at exit: 0 bytes in 0 blocks
==596170==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==596170== 
==596170== All heap blocks were freed -- no leaks are possible
==596170== 
==596170== For lists of detected and suppressed errors, rerun with: -s
==596170== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

Note by the way that the address value 0x1E201D remains constant between program/valgrind invocations. The same value is also shown in valgrind's output when running another example (like echo.roc).

---

Using git bisect, it seems like the problem was introduced in 8b036ea1c5cb2b0d12bcf73463c70e91f5455610.

I am on an x86-64 Linux (Manjaro) installation, and build/run the project with the nix develop wrapper.

[folkertdev]

I cannot reproduce this on linux mint (not using nix)

folkertdev@folkertdev ~/r/roc (trunk)> valgrind --leak-check=full --track-origins=yes  ./examples/interactive/countdown
==73585== Memcheck, a memory error detector
==73585== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==73585== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==73585== Command: ./examples/interactive/countdown
==73585== 

Let's count down from 10 together - all you have to do is press <ENTER>.

10...

9...

8...

7...

6...

5...

4...

3...

2...

1...

🎉 SURPRISE! Happy Birthday! 🎂

==73585== 
==73585== HEAP SUMMARY:
==73585==     in use at exit: 8,232 bytes in 2 blocks
==73585==   total heap usage: 24 allocs, 22 frees, 11,334 bytes allocated
==73585== 
==73585== LEAK SUMMARY:
==73585==    definitely lost: 0 bytes in 0 blocks
==73585==    indirectly lost: 0 bytes in 0 blocks
==73585==      possibly lost: 0 bytes in 0 blocks
==73585==    still reachable: 8,232 bytes in 2 blocks
==73585==         suppressed: 0 bytes in 0 blocks
==73585== Reachable blocks (those to which a pointer was found) are not shown.
==73585== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==73585== 
==73585== For lists of detected and suppressed errors, rerun with: -s
==73585== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[Qqwy]

I have managed to build Roc from source now without Nix.

Without Nix, the example also runs fine on my machine. Very odd.

[Anton-4]

I was able to reproduce this on Ubuntu 20.04 in and outside of nix.

[Anton-4]

I'm not able to reproduce this anymore, @Qqwy can you do a cargo clean and try it again in nix develop?

[Qqwy]

I have the project checked out twice in different folders, to make sure that running it with and without nix do not interact with each other.

Running, from within nix develop:

$ cargo clean
$ cargo run -- build ./examples/interactive/countown.roc
$ valgrind ./examples/interactive/countdown 
==30052== Memcheck, a memory error detector
==30052== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==30052== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==30052== Command: ./examples/interactive/countdown
==30052== 
==30052== 
==30052== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==30052==  Bad permissions for mapped region at address 0x1E201D
==30052==    at 0x1E201D: ??? (in /run/media/qqwy/Serendipity/Programming/Personal/roc/roc2/examples/interactive/countdown)
==30052==    by 0x400248F: ??? (in /nix/store/rir9pf0kz1mb84x5bd3yr0fx415yy423-glibc-2.33-123/lib/ld-2.33.so)
==30052== 
==30052== HEAP SUMMARY:
==30052==     in use at exit: 0 bytes in 0 blocks
==30052==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==30052== 
==30052== All heap blocks were freed -- no leaks are possible
==30052== 
==30052== For lists of detected and suppressed errors, rerun with: -s
==30052== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

So the problem is still there.

This is on the new trunk (58049d39b2a1ea52f3bb862423454e408d2c6d97).

[Anton-4]

Hmm, I'll try it out on my Arch Linux vm.

[Anton-4]

I'm now able to reproduce this on Arch Linux inside nix.

[Anton-4]

From searching around, this error typically occurs when trying to write to read-only memory. @folkertdev do you see anything in 8b036ea1c5cb2b0d12bcf73463c70e91f5455610 that could do something like that?

[Anton-4]

We've encountered a related issue where this was caused by a bug in the surgical linker, as soon as #3483 is fixed we can check if using the legacy linker (cargo run -- build ./examples/interactive/countdown.roc --linker=legacy) prevents this issue as well.

[bhansconnect]

@Qqwy Now that #3540 is closed, can you try again on latest trunk?