Fix a potential segfault on log message for failing to load module #1153
  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.