slajerek
Command line arguments not working on Linux?
I've tried to start RetroDebugger with various command line options to load a PRG file (ex.: "retrodebugger -c64 build/test.prg", "retrodebugger -c64 -prg build/test.prg", "retrodebugger -prg build/test.prg", etc.). RD starts without error, but it never loads the PRG.
I can load the same PRG fine if I load it from the menus after startup.
BTW: Testing just "retrodebugger build/test.prg" on Linux results in "*** buffer overflow detected ***: terminated". This is using the latest retrodebugger compiled from source on Linux - which seems to work fine in every other way.
Is there just some simple formatting thing that I'm missing?
I did a little debugging into the buffer overflow that occurs when trying to start RetroDebugger with a single .prg path parameter:
On my system, it aborts when parsing the avahi process. proc_find_other_instance gets to line 222 and ends up thinking the fileName should be "avahi-daemon:" since it's not a real path in the command. This leads to MTEngineSDL's SYS_Funct/SYS_GetFileNameWithExtensionFromFullPath trying to do a strcpy (line 346) of the filename to a return buffer.
It looks like there wouldn't be room for the null terminating character since the array was created to be the exact length of the string - causing the buffer overflow.
Confirmed. I added a +1 to the length declaration and I can now load from the command line. I'll fork and submit a pull request, if that works for you.
https://github.com/slajerek/MTEngineSDL/pull/8
@slajerek v0.64.70h2 does not work with command line switches in Ubuntu 24.10. Testing v0.64.68 works fine.
I am using the command:
retrodebugger68 -wait 3000 -jmp x0818 -prg chill_compiled.prg
I tested this on Linux Debian, works on latest correctly 0.64.70h2, I tested these exact command line arguments. Are you sure the path and jmp address are correct? Could you please post more details?
Running the application from the command line generates a buffer overflow. If I click on the icon to launch its fine. So its not the commandline options, its just running from the command line. v0.64.68 doesnt have this issue.
Just built from source and can confirm segfault. It's unrelated to original issue, though.
I took a quick look and found it's happening when MTEngingSDL's CRenderBackendOpenGL3:ReBindTexture is being called with a null image pointer.
I just added a null check on that as a quick hackaround and it now starts properly again. I'm sure you'll want to find the root cause as to why it is being called that way.
That ReBindTexture with argument NULL should never happen. It is literally called in only one place in CSlrImage:
gRenderBackend->ReBindTexture(this);
I will run this through valgrind. But it is really strange edge case. It of course does not happen on my Debian. Might be some memory overwritten or some async race condition error.
Is this still happening? I've not been able to reproduce this, neither on Valgrind. Please confirm.