Jasper Woudenberg (Oct 18 2024 at 16:09): Jasper Woudenberg (Oct 18 2024 at 16:09):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.
Brendan Hansknecht (Oct 18 2024 at 16:32):worst case can try malloc from libc?
Brendan Hansknecht (Oct 18 2024 at 16:36):also lldb or gdb or valgrind is likely your friend here
Jasper Woudenberg (Oct 18 2024 at 16:59):Thanks! I've tried valgrind already but it didn't tell me anything. Will give lldb and/or gdb a try!
Luke Boswell (Oct 18 2024 at 18:51):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?
Jasper Woudenberg (Oct 18 2024 at 19:04):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.
Luke Boswell (Oct 18 2024 at 19:06):What is your mainForHost api? Also do you have any effects/hosted modules?
Jasper Woudenberg (Oct 18 2024 at 19:16):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!
Luke Boswell (Oct 18 2024 at 19:18):You're using zig 0.13.0 and the builtins copied from that upgrade branch?
Luke Boswell (Oct 18 2024 at 19:19):Therr could be an issue in there, we haven't landed and extensively used the zig 0.13 builtins.
Jasper Woudenberg (Oct 18 2024 at 19:20):I think I've got the helpers from the last roc-ray commit before you migrated it to rust, can double-check though.
Luke Boswell (Oct 18 2024 at 19:22):Sounds good. Just wanted to clarify
Luke Boswell (Oct 18 2024 at 19:23):Yeah running through a debugger would be helpful here I think.
Jasper Woudenberg (Oct 18 2024 at 19:28):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?
Luke Boswell (Oct 18 2024 at 19:38):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.
Jasper Woudenberg (Oct 18 2024 at 19:45):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
Luke Boswell (Oct 18 2024 at 19:50):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.
Luke Boswell (Oct 18 2024 at 19:50):You can try and build a legacy host instead (or as well)
Jasper Woudenberg (Oct 18 2024 at 19:54):Thanks, will give it a try. And maybe I can reduce my error into a small reproducible example for a surgical linker bug report.
Jasper Woudenberg (Oct 18 2024 at 20:36):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!
Notification Bot (Oct 18 2024 at 20:38):Jasper Woudenberg has marked this topic as resolved.
Last updated: Jul 26 2025 at 12:14 UTC