funchook failed: Could not find a free region near [function address]
I got a crash report from a Cartograph user that they're keep getting a crash after updating the mod to >0.8.3: https://github.com/yeshjho/Cartograph/issues/4
They are running on Linux via Epic/Heroic.
They tried restarting their PC, verifying the game files, and using different SML versions.
There wasn't any change in Cartograph regarding function hooks during 0.8.3->0.9.0: diff
I have removed one function hook during 0.9.0->1.0.0: diff
What could have caused the issue?
Solution:Jump to solution
Update, their environment were deprecated and they were able to solve the issue by switching to ProtonGE from WineGE.
I was able to fix the problem 🙂 Your comment about the environment let me try out a few more things....
13 Replies
Automated responses for yeshjho (353886187879923712)
Key Details for LogWith1.0.0.zip
Key Details for LogWith0.9.0.zip
Key Details for LogWith0.8.3.zip
Outdated mods found!
Cartograph: Buildings on Map can be updated to
1.0.0
Update these mods, there may be fixes for your issue in doing so.Crash found in FactoryGame_c633db54_Local_Stable_WindowsClient.log
It has been attached to this message.
Crash found in FactoryGame_c633db54_Local_Stable_WindowsClient.log
It has been attached to this message.
to my knowledge, it means that there was no free memory to use to put the hook code into within that range (needs to be within jump range). I don't think it is necessarily your "fault", as in, caused by how you made your mod. it can just happen sometimes. not sure if there is a fix
@Mircea (Area Actions) understands far more about the hooking system and can probably give some more insight
Those addresses look weirdly low, but maybe that's just where wine places the dlls (probably no ASLR)
I think the
enableFunchookLogging option should still exist in the SML.cfg
It will generate a SML-funchook.log or something in the same logs dir as the gameThanks Robb and Mircea!
I quickly did a very brief research about hooking, and yeah, it seems like there's nothing I can do about it...
It might be the case that my code got bigger in 0.9.0 just enough to shrink the free space down to the point where it can't install the hooks, idk.
Looked at the
funchook's code, I'm not good at reading C code, but it looks like it's finding within INT32_MAX range around the function address, so it means it couldn't find any free space to install the hook in [function address] +- 2GB space? That's wild...My assumption is this is a Linux-emulation-related problem at its core unfortunately 😦
Yeah I agree... 😔
But I wonder if there's any workaround.
Like allocating some memory when the mod is loaded and freeing right before hooking? I don't know how cumbersome it is, but it sounds like it might work in theory
I wonder how far is the heap space away from the code space in that environment... If it's within 2GB, it'll be easy to implement, but if it's not, well...
It would be hard to try the theories thru 3rd person, without setting yourself up a test environment with similar conditions
True... I might put it in the backlog (and never come back like how backlogs work 😂)
This would be a very good way to tell what actually causes that
The memory it looks for isn't around your DLL, but around the hooked function's DLL
And non-image stuff shouldn't ™️ be allocated in the same region as DLLs, so even if somehow allocating some memory would magically fix the memory layout, it wouldn't be in the right range anyway
Ohh right, so if I'm hooking UE's function, that'll be harder to employ a workaround, even if there's a workaround
Yeah I know at least in Windows they're completely separated, but you already mentioned addresses looking weirdly low and no ASLR, I though there might be a chance, but I agree that the chance is probably low.
Would loading a "fake" DLL and unloading it before hooking have a chance, then? Or it'll sill be too far away from the original function's address?
Quite unlikely
I can try replicating this after I finish updating stuff to 1.1, and I'll check what the actual memory layout is with vmmap
Thanks Mircea!
Solution
Update, their environment were deprecated and they were able to solve the issue by switching to ProtonGE from WineGE.
I was able to fix the problem 🙂 Your comment about the environment let me try out a few more things. Before I was running Satisfactory with Wine-GE-Proton8-26. But WineGE is deprecated in favor of ProtonGE. So I switched to GE-Proton9-27 with the umu-launcher. With that I had no problem running the latest version of your mod.