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?

LogWith0.8.3.zip86.34KB

LogWith0.9.0.zip96.63KB

LogWith1.0.0.zip74.38KB

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.

Jump to solution

Yyeshjho I got a crash report from a Cartograph user that they're keep getting a crash af...

FICSIT-Fred•4/6/25, 9:37 PM

Abridged_FactoryGame_c633db54_Local_Stable_WindowsClient.log3.53KB

Abridged_FactoryGame_c633db54_Local_Stable_WindowsClient.log3.52KB

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
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.

Robb•4/6/25, 10:06 PM

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

Robb•4/6/25, 10:07 PM

@Mircea (Area Actions) understands far more about the hooking system and can probably give some more insight

Mircea•4/6/25, 10:23 PM

Those addresses look weirdly low, but maybe that's just where wine places the dlls (probably no ASLR)

Mircea•4/6/25, 10:23 PM

I think the option should still exist in the SML.cfg

Mircea•4/6/25, 10:24 PM

It will generate a or something in the same logs dir as the game

yeshjhoOP•4/6/25, 10:45 PM

Thanks 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.

yeshjhoOP•4/6/25, 10:55 PM

Looked at the 's code, I'm not good at reading C code, but it looks like it's finding within 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...

Beef•4/6/25, 10:58 PM

My assumption is this is a Linux-emulation-related problem at its core unfortunately

yeshjhoOP•4/6/25, 11:02 PM

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

yeshjhoOP•4/6/25, 11:04 PM

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...

Beef•4/6/25, 11:04 PM

It would be hard to try the theories thru 3rd person, without setting yourself up a test environment with similar conditions

yeshjhoOP•4/6/25, 11:07 PM

True... I might put it in the backlog (and never come back like how backlogs work

)

MMircea I think the `enableFunchookLogging` option should still exist in the SML.cfg

Mircea•4/6/25, 11:09 PM

This would be a very good way to tell what actually causes that

Yyeshjho Yeah I agree... 😔 But I wonder if there's any workaround. Like allocating some...

Mircea•4/6/25, 11:10 PM

The memory it looks for isn't around your DLL, but around the hooked function's DLL

Mircea•4/6/25, 11:11 PM

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

MMircea The memory it looks for isn't around your DLL, but around the hooked function's ...

yeshjhoOP•4/6/25, 11:13 PM

Ohh right, so if I'm hooking UE's function, that'll be harder to employ a workaround, even if there's a workaround

MMircea And non-image stuff shouldn't ™️ be allocated in the same region as DLLs, so eve...

yeshjhoOP•4/6/25, 11:15 PM

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.

yeshjhoOP•4/6/25, 11:16 PM

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?

Mircea•4/6/25, 11:19 PM

Quite unlikely

Mircea•4/6/25, 11:20 PM

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

yeshjhoOP•4/6/25, 11:28 PM

Thanks Mircea!

Solution

yeshjho•4/21/25, 10:46 PM

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.