Extension dev issue - VSCode debug
3 Attachment(s)
Hi friends,
I have an important issue on a SM extension I'm developing which seems to be caused by Linux environment reasons and not by a MM/SM bug, but I only can conceive it's better to first ask here, hoping any advanced guy has any clue. Here's my setup:
My problem is that, while both running normally the server (not GDB debugging) and with GDB manually on command line only, SourceMod correctly loads using HL2DM files (e.g. sourcemod.2.hl2dm.so, gamedata and such), and my extension and everything works great. but, when I debug via VSCode (which uses a native GDB integration tool, https://code.visualstudio.com/docs/c...json-reference), then SM detects it as wrong game/mod instead (concretely SSDK2013), causing it to complain about missing gamedata for instance (which is normal for base SSDK2013 mods; some gamedata files have been missing for it for long). The left picture shows the affected execution when debugging from VSCode, and the right one reflects an stable launch with command line GDB debugging, highlighting the HL2DM SM binary being correctly loaded. I guess VSCode messes up symbols somehow, but my debugging JSON script doesn't apparently contain anything wrong (which I attach below if anyone is used to the same IDE and tools, containing few minor edits to expand some variables from dependent base configs), so I don't know what could be different from debugging from command line, which works fine. Would anyone happen to know what this wrong game detection could be caused for? Or even anything in general terms, really. Overall the issue limits me in that I wish to work with breakpoints while I'm developing, and due to this limitation I can only print debug with logging as an alternative. Many thanks |
Re: Extension dev issue - VSCode debug
Alright. So, I came with the cause of the problem from the server view -which is not a MM fault itself, but a concrete environment difference-. By analyzing the Metamod source code I reached the game/mod detection part which allows the concrete binary selection, and could then analyze the case.
First off, for reference, the loader does this under Linux: https://github.com/alliedmodders/met...oader.cpp#L247. So I investigated what the contents of the cmdline file for the SRCDS process were. It turns out that under the two aforementioned correct run setup alternatives, the cached arguments stored in the descriptor are split by null terminators (\0s), which MM exactly uses to parse the cached startup arguments and eventually detect the -game one. Example: Code:
adrian@PC-Adrian:~/Source/metamod$ cat /proc/26584/cmdline Code:
adrian@PC-Adrian:~/hl2rp_server$ cat /proc/27479/cmdline EDIT: Upon recently realizing the fault was potentially mine (was filling JSON array-like arguments as a whole string rather than by one argument per item) and fixing the space separators issue, the same SDK2013 misdetection problem is still happening. Currently investigating what else may be wrong. |
Re: Extension dev issue - VSCode debug
Alright, here's the final full solution. When configuring your .vscode/launch.json (for debugging), don't set the SRCDS arguments like this:
Code:
"args": [ Instead, wrap at least each of the two game argument tokens into a single array element: Code:
"args": [ Hope this helps anyone. |
All times are GMT -4. The time now is 18:33. |
Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.