On Mon, Mar 15, 2021 at 5:26 PM Stephen R. van den Berg srb@cuci.nl wrote:
I'd think that wouldn't be a problem, since all refs are accounted for.
I'd love to share your optimism, but the GC also detects leaks and such stuffs, calls Pike level code (destroy()/_destruct()) which would all sit on top of your write() in a backtrace requested by those LFUNs).
request a backtrace of your thread and non-hashed strings might leak
I'm not quite sure what happens if someone copies that string for a backtrace. For this to work, the string should then be copied into a new shared string.
Yeah except absolutely no part of Pike or user code is aware of this requirement, and so naturally nothing does it, and that's why your non-hashed string would leak into the system this way and cause all sorts of mayhem later.
into the system like that, or your write call might fail (say OOM), leaving your very own thread with a backtrace leaking the non-hashed string into the system.
That has been taken care of. My non-hashed strings are accounted for and will be cleaned up properly, even in the midst of exceptions.
Nothing is taken care of, they will leak to whoever catches the exception and cause all sorts of mayhem as Pike is not equipped to encounter non-hashed+non-linked strings in the wild in arbitrary, pike-code-reachable svalues.