Total shot in the dark, but @Luke Boswell, was wondering if you have encountered this while working on roc-ray when it's host was still using Zig 0.13.
I've been trying to write my own host with Zig 0.13 (stealing some of your code :smile:). When I try to do any kind of heap allocation from the host main.zig
, when I run a sample application against that host it crashes on that allocation with a SIGTRAP.
I've been trying to different types of allocators, different types of data allocated, different places to perform the allocation (including right at the start of main
before calling out to Roc), noe of it seems to make a difference. I noticed that roc-ray used a GeneralPurposeAllocator as well so I was hoping you might have run into the same problem before and found a way to solve it.
I tried to build that version of roc-ray myself to see if I would run into the same problem there, but ran into a problem truying to build it (it can't find libx11, probably a side-effect of me being on NixOS and no dynamic libraries being around). I'll try that again, wanted to ask if you've seen the error before first.
worst case can try malloc from libc?
also lldb
or gdb
or valgrind
is likely your friend here
Thanks! I've tried valgrind already but it didn't tell me anything. Will give lldb
and/or gdb
a try!
I haven't seen this specifically, but it sounds like a familiar experience. How do you know it's related to allocation? that seems strange to me.
Can you strip things back and isolate it somehow?
Thanks!
How do you know it's related to allocation? that seems strange to me.
Yeah, super weird. Pretty sure that's it though, the platform runs fine, creating an allocator is fine, but when I use an allocator then the line on which I do is the last one that runs.
What is your mainForHost api? Also do you have any effects/hosted modules?
mainForHost is mainForHost : Task {} I32 as Fx
and I have an effect module. I still see the behavior if I I don't call mainForHost
and remove all my effects, just having an allocation happen in my main.zig
file. I think it must be an interaction with some of the Roc helpers imported and/or linked in.
Anyway, didn't mean to rope you into debugging, was just curious if happened to know the answer of the top of your head. I'll investigate a bit more and report back if I learn anything interesting. Thank you both!
You're using zig 0.13.0 and the builtins copied from that upgrade branch?
Therr could be an issue in there, we haven't landed and extensively used the zig 0.13 builtins.
I think I've got the helpers from the last roc-ray commit before you migrated it to rust, can double-check though.
Sounds good. Just wanted to clarify
Yeah running through a debugger would be helpful here I think.
Ohhh, fun fact, when I run dynhost
directly that works. But when I run an app making use of the in progress platform then I get the error. Just if I try an allocation in the Zig platform though, if I take that out the app runs fine, including the basic effects I have in place. So maybe it's a linking problem?
It's hard to follow, there's so many different configurations for how you could have set up the host and roc. It sounds like your building a surgical host and preprocessing it, and then using the surgical linker?
If you have linked roc in as a dynamic library and build an executable using zig, and it works well, but then fails later it could be a surgical linker bug.
I believe that's what I'm doing, but I'm not super familiar with all the options so I could be wrong.
I build roc using build --lib platform/libapp.roc --output libapp.so
Then I build a zig executable using zig build
, linked to libapp.so
and libc
. I rename the resulting file dynhost
and copy it into platform/
.
Then I run roc preprocess-host dynhost platform/main.roc platform/libapp.so
. This produces two additional files.
Getting real crowded in platform/
now with these files besides some roc modules:
dynhost
libapp.roc
libapp.so
linux-x64.rh
main.roc
metadata_linux-x64.rm
Then I roc run
a platform file containing this header:
app [main] { pf: platform "../zig-out/platform/main.roc" }
Yeah, this is how you build a surgical host
The dynhost is just a normal executable.. and it runs fine? but then it fails building another app... which might suggest something fishy with surgical linking.
You can try and build a legacy host instead (or as well)
Thanks, will give it a try. And maybe I can reduce my error into a small reproducible example for a surgical linker bug report.
With the legacy linker it worked! roc-ray again was a great example showing me how to do it. Thanks again for the help and the examples!
Jasper Woudenberg has marked this topic as resolved.
Last updated: Jul 06 2025 at 12:14 UTC