Fix a potential segfault on log message for failing to load module #1153
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Using the `call_arena` here is unsafe in the case of a failure. It's possible for the call_arena to be reset during module processing, making the log crash. The issue is that the lifetime of a URL is often conditional. If the stitched URL has already been seen (i.e. is in the module_cache), then it can be short- lived. EXCEPT, URL.stitch might require an allocation..and then you start to think, well, if URL.stitch is going to allocate anyways...If we stitch with the `page.arena`, and end up not needing a long lifetime, we've wasted memory. If we stitch with `page.call_arena` and end up needing a long lifetime, we need to dupe. It's a bit messy, and I'd like to take a stab at improving it after: #1127. I'm thinking that we need a URL intern pool. HashMap with a composite key of base + path -> resolved. Then all URLs are resolved using the page.arena, but we don't have any duplicates, so it isn't wasteful.
krichprollsch
approved these changes
Oct 16, 2025
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Using the
call_arenahere is unsafe in the case of a failure. It's possible for the call_arena to be reset during module processing, making the log crash.The issue is that the lifetime of a URL is often conditional. If the stitched URL has already been seen (i.e. is in the module_cache), then it can be short- lived. EXCEPT, URL.stitch might require an allocation..and then you start to think, well, if URL.stitch is going to allocate anyways...If we stitch with the
page.arena, and end up not needing a long lifetime, we've wasted memory. If we stitch withpage.call_arenaand end up needing a long lifetime, we need to dupe.It's a bit messy, and I'd like to take a stab at improving it after: #1127.
I'm thinking that we need a URL intern pool. HashMap with a composite key of base + path -> resolved. Then all URLs are resolved using the page.arena, but we don't have any duplicates, so it isn't wasteful.