Godotsteam: Getting segfault in SteamApi_RunCallbacks after lobby_match_list in mingw compiled version with patch

[MichaelBelousov]

I'll compile with msvc and compare.

Here's the gdb stack trace for the segfault:

[Thread 5620.0x62bc exited with code 0]

Thread 1 "MainThrd" received signal SIGSEGV, Segmentation fault.
0x00007ffb7dabc444 in steamclient64!hid_write_output_report ()
   from D:\Programs\Steam\steamclient64.dll
(gdb) bt
#0  0x00007ffb7dabc444 in steamclient64!hid_write_output_report ()
   from D:\Programs\Steam\steamclient64.dll
#1  0x00007ffb7da694e3 in steamclient64!hid_write_output_report ()
   from D:\Programs\Steam\steamclient64.dll
#2  0x000000000065abe8 in Steam::_lobby_match_list (this=0x41e748a0,
    callData=0x2d73ceb0, bIOFailure=false)
    at modules/godotsteam/godotsteam.cpp:3656
#3  0x0000000002212d3e in CCallResult<Steam, LobbyMatchList_t>::Run (
    this=0x41e75890, pvParam=0x2d73ceb0)
    at modules/godotsteam/sdk/public/steam/steam_api_internal.h:132
#4  0x00007ffbce474079 in steam_api64!SteamAPI_servernetadr_t_SetQueryPort ()
   from D:\gamedev\debt-civ\godot\bin\steam_api64.dll
#5  0x00007ffbce473e04 in steam_api64!SteamAPI_servernetadr_t_SetQueryPort ()
   from D:\gamedev\debt-civ\godot\bin\steam_api64.dll
#6  0x00007ffbce473bb7 in steam_api64!SteamAPI_servernetadr_t_SetQueryPort ()
   from D:\gamedev\debt-civ\godot\bin\steam_api64.dll
#7  0x00007ffbce473ae9 in steam_api64!SteamAPI_servernetadr_t_SetQueryPort ()
   from D:\gamedev\debt-civ\godot\bin\steam_api64.dll
#8  0x00007ffbce4773b9 in steam_api64!SteamAPI_RunCallbacks ()
   from D:\gamedev\debt-civ\godot\bin\steam_api64.dll
#9  0x00000000029bc175 in Steam::run_callbacks (this=0x41e748a0)
    at modules/godotsteam/godotsteam.h:949
#10 0x0000000002249f88 in MethodBind0::ptrcall (this=0x41db22d0, p_object=
    0x41e748a0, p_args=0x0, r_ret=0x0) at ./core/method_bind.gen.inc:66
#11 0x000000000071dd94 in godot_icall_0_13 (method=0x41db22d0, ptr=0x41e748a0)
    at modules/mono/glue/mono_glue.gen.cpp:120
#12 0x00000000479500da in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Perhaps SteamApi_RunCallbacks needs to be wrapped similarly to GetSteamID? iirc the backtrace seemed similar, but I'll experiment with that after I confirm it does work with VS and I'm not just running into something else.

[MichaelBelousov]

I would definitely call mingw support "not recommended", at least until godotsteam can test a decent portion of the SteamAPI with it. I am somewhat unfortunately determined to use mingw so I will see if I can find a way to test this stuff and if the currently known hacks we have can fix it, then hopefully mingw usage could be normal.

[Gramps]

Hmm, MinGW rears its ugly head again, eh? Sounds like a plan. I'll update the necessary documents.

[MichaelBelousov]

Doesn't appear to be happening in msvc compiled build, so yeah I think it's a mingw issue. I'll look into using what we know so far to fix it.

[MichaelBelousov]

And it looks like I also ran into a (potentially separate issue worthy) segfault without mingw, in the getLobbyDataByIndex function, but it's peculiar so maybe I should look into if I'm misusing the steam api.

EDIT: something weird is going on, the counter i in the loop of Steam::getLobbyDataByIndex() is 1651461189, dataCount is 7602297 (which also sounds wrong, why would a lobby have 7 million metadata fields set?), so clearly the counter shouldn't have entered the loop, for getting why the loop bound is so high in the first place.

[Gramps]

Definitely sounds like MinGW. And yes, getLobbyDataByIndex causes a crash and is on my to-do list.

That is really strange. A valid lobby definitely wouldn't have that many fields; in a lot of cases 1, 2, or even 0. I'll have to dig into it more this week.

[MichaelBelousov]

just reporting, I'm close to giving up today, so far I haven't been able to wrap SteamAPI_RunCallbacks sufficiently to get it to work with the open steamworks inline trick. I will try one more thing and then probably give up on mingw support until I get some progress on other stuff I need, and perhaps eventually I'll do more research into getting it to work.

[MichaelBelousov]

Alright, I don't feel like digging into mingw's msvc interop features and I'm lost for now. I guess no mingw yet :(, I hope to return to it soon. You can close this issue to indicate that there will be no official mingw support for now, and maybe we should rid the script for now and reintroduce it if I ever get back to it (or someone else does).

[Gramps]

Hmm, sounds like quite the circus, sir. Noted on the patch file. I will get it pulled tonight and make other minor updates to text where appropriate.

That being said, if it isn't on my to-do list, I'll add it on and we can revisit it later! And thank you very much for taking a stab at it!

[MichaelBelousov]

I'm actually not quite done for tonight anyway (don't reopen the issue though), I did manage to confirm with gdb that the inline hack I applied does actually call into the steam dll, but it doesn't seem to do anything, definitely not cause the emit_signal I'm looking for which works when using msvc for this lobby request logic. Either steamlib or the debugger is throwing an exception which I'm trying to read.

[MichaelBelousov]

yeah looks like it is called, and there may be some kind of exception in my debugger or handled internally, my build or gdb isn't configured to inspect it unfortunately. With further research I could probably learn more but for now it's not worth the effort, I'll go do something useful.

[Gramps]

Definitely sounds like a time sink so probably wise to let it lie for now. Like I said, we'll get back to it at a later time and figure it out. Thanks again for all the efforts, sir!