Closed notEvil closed 1 year ago
I think I figured it out: its the StringExt to the name "dumpLockedVars" (block 27). So there is no issue, except maybe suboptimal output. It would probably require an additional pass to identify solitary StringExt.
Ok, great. Well, that makes sense I guess.
I notice you commented out jsvGarbageCollect in DumpLockedVars - did it not appear if that was left in?
Presumably it's just bad luck that in this case the StringExt came before the String that referenced it, when usually it would appear after?
I notice you commented out jsvGarbageCollect in DumpLockedVars - did it not appear if that was left in?
It does appear because it is part of the current function call and therefore locked.
Presumably it's just bad luck that in this case the StringExt came before the String that referenced it, when usually it would appear after?
Since the free list isn't guaranteed to always link forwards, it is bad luck, sort of. I have no numbers, but I'd say it is rather common.
Hi,
I was investigating a slow memory usage buildup when I saw a block appearing that didn't make sense. To reproduce, compile 2v17 for Linux with
(had to use C++17 because C++11 showed deprecation errors for abseil), then execute
Block 25 with flags 66 shouldn't be there. Using a function definition is significant. The block magically disappears when flooding the command history with different commands. Hope this description helps identifying the relevant code sections. I tried but didn't succeed.