Adhesive.dll crashes about fivem

[YasinY]

Holy shit. Spot on. In the config there is:
x = -934.0, y = 6670.0, z = -27.0,
I'm going to remove the script and see how we go.

What do you mean by GTA script handler, by the way? Is that something, I can implement? What is its responsibility?

How did you figure out the coordinates? I can't seem to find them in the crash dumps? Teach me please, so the next time I don't have to annoy you (guys).

[PappaNiels]

Can you provide a crash dump so the team can diagnose the issue?

[YasinY]

Sure thing, here are some of many
CfxCrashDump_2024_04_18_06_48_54.zip
CfxCrashDump_2024_04_18_05_51_13.zip
CfxCrashDump_2024_04_19_22_20_16.zip

[YasinY]

I have to add ontop of that, it's not for every player. It's random, for selected players.

[gottfriedleibniz]

Crash is identical to #1919 (comment) but w/ 2944. Are you doing anything special at the coordinates: -934.000000, 6670.00000, -27.0000000? Crash logs are a bit interesting since they are showing multiple exceptions due to a lack of a GTA script handler.

(Adhesive is likely showing up due to stack scanning as that script command is obfuscated).

[YasinY]

So will there be no way to understand where exactly it comes from and instead be a trial-and-error thing?

Yeah, nice catch. I guess, something is happening there.

A script spawns cases nearby, which you can pick up when nearby and give you an item when you open them. (at that coordinates).

But crashes are not happening there. It's really just when either a blip is created or when you go 'off-duty'.

Unfortunately I am not allowed to redistribute the code, so I can't share the exact code here. But it's called 'kuz_diving' from KQ and is not obfuscated.

Why these coords, though? What is your assumption / what is your thought process? Could you please elaborate so I may either can provide more information around that or help

And also, the same behaviour was on build 2802 (I've tested it with my comm)

[gottfriedleibniz]

But crashes are not happening there. It's really just when either a blip is created or when you go 'off-duty'.

In the three provided dumps the game is crashing with calls to ADD_BLIP_FOR_COORD at -934.000000, 6670.00000, -27.0000000. In this case SEH is not capturing this null-deref (obfuscated nature of that code?).

Much earlier in your logs (almost near script initialization), we see a similar error:

__Lua_InvokeNative: execution failed: Error executing native 0x963d27a58df860ac at address FiveM_b2944_GTAProcess.exe+D73A93.

Which seems like you guys are doing something to cause the script thread state to be corrupt early on.

[gottfriedleibniz]

I wouldn't expect removing that script to help much, unfortunately. From your logs things already look like they are in a weird state much earlier:

// One dump.
[   1961594] [b2944_GTAProce]             MainThrd/ __Lua_InvokeNative: execution failed: Error executing native 0x963d27a58df860ac at address FiveM_b2944_GTAProcess.exe+D73A93.
[   1961594] [b2944_GTAProce]             MainThrd/ ^1SCRIPT ERROR: Execution of native 963d27a58df860ac in script host failed: Error executing native 0x963d27a58df860ac at address FiveM_b2944_GTAProcess.exe+D73A93.^7

// Another
[   4639297] [b2944_GTAProce]             MainThrd/ ^3Warning: [entity] GetNetworkObject: no object by ID 199^7
[   4639297] [b2944_GTAProce]             MainThrd/ (FÜR PENG) RequestNamedPtfxAsset called with assetName:	core
[   4639297] [b2944_GTAProce]             MainThrd/ __Lua_InvokeNative: execution failed: Error executing native 0xb80d8756b4668ab6 at address FiveM_b2944_GTAProcess.exe+D90D59.
[   4639297] [b2944_GTAProce]             MainThrd/ ^1SCRIPT ERROR: Execution of native b80d8756b4668ab6 in script host failed: Error executing native 0xb80d8756b4668ab6 at address FiveM_b2944_GTAProcess.exe+D90D59.^7

The issue at play being ADD_BLIP_FOR_COORD may not throw "SCRIPT ERRROR:" messages like 0x963d27a58df860ac and 0xb80d8756b4668ab6 will.

[YasinY]

Crash is still occuring! Here is a new log.
CfxCrashDump_2024_04_22_19_54_45.zip

Yes, I don't get why it throws an error. For once it'S RequestNamedPtfxAsset, although core is being loaded, it still fails the native execution. Hence the 'FÜR PENG', I've overriden the native to throw a print WHAT exactly is passed when the native fails. Can't figure out why.

Same with RequestModel (0x963d27a58df860ac )

[gottfriedleibniz]

A script handler is essentially a game class that helps script threads manage script resources (e.g., models, blips, etc) and do networking - something required by each resource. For some unknown reason your dump is showing an attempt to run code in a cleaned up resource (e.g., stopped; in the link above they are using onResourceStop) or some other state corruption is happening (more likely).

More information is required I think (e.g., Fulldump). Minidumps don't provide enough information and looking through the affected code-paths for race conditions and the sorts is a bit annoying.

[YasinY]

How do I acquire such a full dump? Is there any reference you can give me? Sorry for the belated answer, I wasn't home due to my job requiring so.

And I'd kindly ask again, how did you manage to figure out the coordinates above?
Do I have to load the dump in VS?

Edit:
It's really just for some players. These errors are not occuring on my side, neither obfuscated nor locally (deobfuscated)
Idk. I guess minidumps are all we got.

Only way to think of is now overriding the global so I can tell what parameter is passed. Not sure if that'd help out though.

[YasinY]

another crash dump
CfxCrashDump_2024_04_27_16_04_40.zip

CfxCrashDump_2024_04_27_19_36_07 (1).zip

[YasinY]

.bump

[ook3D]

How do I acquire such a full dump?

https://forum.cfx.re/t/enabling-and-uploading-full-client-dumps/1138940