Stream: beginners

Topic: Memory corruption errors since updating to basic-cli 0.15.0

Ian McLerran (Sep 12 2024 at 19:44):

The error seems to take many different forms, but always in the update logic for roc-start. Often it will crash in the first update (platforms), but may also crash during the package update (haven't observed an app-stub crash yet - this logic is different). It may also successfully update (no crashes in any stage of the updates), but if it does, then when the tui menu is reached, either the last item in the platforms menu list will be corrupted, or the program will crash when progressing from app name input to platform selection. In at least some cases (definitely in the tui crash case - example 6), the carriage return becomes broken in the current terminal instance, and any time that a newline is printed, the carriage does not return. It should be noted that the local files which store the platforms/packages do not get corrupted, and if the app is re-run without the update flag, all platforms, etc will list correctly, including newly downloaded items.

Error forms encountered:

1) Heap corruption

2) Non-alligned pointer being freed

3) Segfault

4) Internal invariant broken (next ptr of prev)

5) Pointer being freed was not allocated

6) Double free when progressing from app name input to platform selection

7) Corrupt string where for last platform in the list (with roc-turtle added to platform list, roc-turtle is now corrupted)

Ian McLerran (Sep 12 2024 at 19:46):

PS: I'm currently still trying to drill down on exactly where in (my) code this error is happening, although it appears to be somewhat inconsistent.

Brendan Hansknecht (Sep 12 2024 at 19:46):

Probably need to pull it up on linux with valgrind. building with the legacy linker and a dev build preferably.

Brendan Hansknecht (Sep 12 2024 at 19:47):

That said, sometimes a dev build on mac viewed with lldb can be helpful

Brendan Hansknecht (Sep 12 2024 at 19:51):

Sometimes also helpful to build the builtins with debeg info depending on where the issue is coming from. That said, to do that, you need to modify the compiler.

Ian McLerran (Sep 12 2024 at 19:58):

My linux machine is down right now, so I'll spin up a VM here and see what I can do. Haven't used valgrind before - looks like the memcheck tool is probably what I need?

Brendan Hansknecht (Sep 12 2024 at 20:05):

Yeah, and it is default

Brendan Hansknecht (Sep 12 2024 at 20:05):

That said, it can be pretty verbose at times

Luke Boswell (Sep 12 2024 at 23:06):

Which version of basic-cli is this from? edit: lol it's in the thread title

Just a hunch, but it it related to fetching http requests? maybe there is a bug we've introduced there.

Ian McLerran (Sep 12 2024 at 23:15):

My hunch is that its actually file reads. Current implementation downloads to filesystem and then reads from FS (should be optimized to load directly into memory). It looks like the fetch completes, but then reading the file encounters issues.

All that I've done so far is some print debugging, and not extensive yet, so I'm not 100% sure.

Luke Boswell (Sep 12 2024 at 23:22):

I'm wondering if it's related to the TCP heap, and somehow similar to the segfault I've been seeing on basic-webserver trying to implement JWT

Luke Boswell (Sep 12 2024 at 23:22):

Or FILE_HEAP I guess

Ian McLerran (Sep 12 2024 at 23:41):

Currently fighting to get a VM running on apple silicone... :face_with_raised_eyebrow: Once I get that sorted we'll see what valgrind can tell me.

Anton (Sep 14 2024 at 14:54):

Can you make an issue for this @Ian McLerran?

Ian McLerran (Sep 15 2024 at 22:03):

Sure, I can file one. I wasn't able to get an x86 linux distro running on my Mac, so I haven't been able to use valgrind to dig any deeper into this bug yet.

I'm working on doing a little more print debugging to try to narrow down the source of the error, but not sure how much I'm going to be able to surface through that route.

@Anton shall I just file an issue based on my original message in this thread?

Anton (Sep 16 2024 at 07:03):

Yes please :)

Ian McLerran (Sep 16 2024 at 16:38):

Filed here. :octopus:

Luke Boswell (Sep 17 2024 at 09:36):

I thought I might test roc-start against the changes in https://github.com/roc-lang/roc/pull/7084

This is what I am seeing. Though I may not have built everything correctly agains that branch.

 $ ./roc-start tui -u
Updating platform repository... ✔
Updating package repository... ✔
Updating app-stubs... roc-start(3791,0x16d47f000) malloc: Heap corruption detected, free list is damaged at 0x6000037942c0
*** Incorrect guard value: 1297437786
roc-start(3791,0x16d47f000) malloc: *** set a breakpoint in malloc_error_break to debug
zsh: abort      ./roc-start tui -u

Luke Boswell (Sep 17 2024 at 09:37):

I tried building an optimized version and waited ~5mins before killing it. Ended up using a non-opt build.

$ roc build --output roc-start src/main.roc
🔨 Rebuilding platform...
0 errors and 0 warnings found in 1702 ms

Luke Boswell (Sep 17 2024 at 09:45):

I'm trying to investigate these failures further.

Luke Boswell (Sep 17 2024 at 09:50):

For (my) future reference; I'm using nix develop and updated the flake to target the branch using roc.url = "github:roc-lang/roc?ref=tag-padding"; and build a debug build of roc by changing the sharedInputs to rocPkgs.cli-debug

Luke Boswell (Sep 17 2024 at 09:51):

I've hit a debug assert using the debug build of roc

$ roc build --output roc-start --optimize  src/main.roc
thread '<unnamed>' panicked at crates/compiler/mono/src/ir/decision_tree.rs:777:17:
IntLiteral([91, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], U8)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

There was an unrecoverable error in the Roc compiler. The `roc check` command can sometimes give a more helpful error report than other commands.

Last updated: Jul 05 2025 at 12:14 UTC