And for debugging for both the codelldb extension which is shown.  It uses the usual Microsoft debugging keys: F5 to start F10 to step over, F11 to step into and F9 to toggle a breakpoint.

Below is an example of debugging a Rust program.

In the end it was a really silly bug, I was trying to load masks but had left the masks/ folder out of the filename.

How did I find it? I sprinkled a few fprintf(stderr,”message”); throughout the program changing “message” to something appropriate and launched it from a terminal. I’d thought it was in a function LoadTextures() so added a call before and after but you can see that worked and the segmentation fault happened after LoadTextures().

So I added it before and after LoadMasks() and my second run it happened before it reached the After LoadMasks message.

Note, I used stderr as the output path because, unlike stdout which is buffered and can be cleared, anything sent to stderr appears immediately.  More about this in this offsite article.

The using SDL part of the title is just to show that you can find bugs even in programs that use SDL.

The version of Code::Blocks on the 18.04LTS Ubuntu  was 16.01 and on Ubuntu 20.04 LTS it’s Code::Blocks 20.03. I keep my Ubuntus up to date but the 18.04 LTS hasn’t switched to the newer Code::Blocks which surprised me. I’m guessing that the maintainers of the 18.04 LTS Ubuntu repositories just haven’t updated their copy of Code::Blocks.

One thing I hadn’t explored in Code::Blocks is the debugging and this seems a lot more powerful than what you get in Visual Studio Code.   This screenshot below from version 20 shows it is more akin to Visual Studio debugging rather than Visual Studio Code debugging what with CPU registers, stack, memory dump and threads.

I’d had a similar bug in this chapter when working on the original Ebook.

Stupidly I’d put the fix in the sources for the next chapter (44) but hadn’t applied it to the sources in the chapter where it had occurred (42). So I fired up my favourite code comparison tool (Devart Code Compare) and looked for differences between the source files for each chapter.

This was in the function AddObjectToCells and is part of the collision detection. It’s when an asteroid or player ship is partly on screen and calculating the cell coordinates that the object lies over. The fix was just adding these two lines so it doesn’t try and access the cells array with negative indices.

if (cellx < 0) cellx = 0;
if (celly < 0) celly = 0;

I’m up to chapter 42 in the Linux e-book. The rest have gone very smoothly though I’m still unable to debug either on my Hyper-V Ubuntu or my Ubuntu running laptop. Both still have the same problem XDG_RUNTIME_DIR not set in the environment.

I’ve been reading up on that and it seems if you switch into root and the value of the environment variable $XAUTHORITY is blank then that is the problem.

My error logging is picking up problems with sound channels not playing. I think the problem is, when I hit the b key to make lots of asteroids explode, it uses up all available sound channels and there’s still explosions happening.  Not really a problem.

But to cap it all, there is a segmentation error happening with a core dump. A segfault which kills the program. But it’s not related to the sound problem. I’ve proved that by commenting out the entire PlayASound function. It now looks like this which I call the sound of silence.

void PlayASound(int soundindex) {
	//int success=Mix_PlayChannel(-1, sounds[soundindex], 0);
	//if (success == -1) {
	//	LogError2("Mix_PlayChannel failed to play audio sound #",SDL_ltoa(soundindex,buffer,10));
	//}
}

So without being able to run the program in a debugger, I’m forced to start putting in lots of logging calls and figure out where the segfault happens that way. It’s an effective way of finding bugs BUT it’s not the fastest! I have also enabled apport to try and get the crash files created in /var/crash so that may be a faster way forward.

Once I have fixed the segmentation fault, I’ll upload the fixed code to Github. It’ll be somewhere in the new code added between chapter 37 and chapter 42, to do with collision detection. Time to put on a deerstalker hat!

It’s slightly different in Windows. There’s a built in function called OutputDebugString(LPCWSTR str) that you can call from anywhere in your program. It dumps the string str into the Output window if you are debugging it in Visual Studio.

If you are running this outside of a debugger, the output is lost unless you can capture it with a suitable utility. DebugView from SysInternals.com (it redirects to Microsoft) is one such utility. That’s a screenshot of it below.

Just run DebugView and leave it there. It might catch other stuff from Windows, but when you run your program from the command line or double click on it, it will execute quickly and you’ll see any strings captured like this one.

This is the program that I ran. In Release it compiles to a 9 KB exe! Because OutPutDebugString needs a LPCWSTR  (Long Pointer to a WideString), I declared the text as wchar_t.

#include <Windows.h>

int main()
{
    wchar_t * text=L"Hello World!\n";
    OutputDebugString(text);
}

At work I developed a very large program that only worked running on another computer. I used OutputDebugString extensively and without it, debugging would have been much harder.

I’m a great fan of logging; it helps you find out what’s happening in a program even if you can’t debug it. Linux, well Ubuntu has a service (sorry Daemon!)  called rsyslog that logs messages from all sorts of processes and it’s quite easy to use in our programs as well.

If we don’t do the next steps all the log messages will go into a file called syslog in /var/log and as this gets a lot of stuff it can grow reasonably quickly. But if you do the following steps, all logged output will instead go into

/var/log/asteroids.log.

From a terminal type the following command:

sudo gedit /etc/rsyslog.d/30-debugging.conf

Type this in and then save it (click the Save button) and close gedit.

if $programname == 'asteroids' then /var/log/asteroids.log
& ~

Now run this command:

sudo service rsyslog restart

It should return immediately and means that any logging to syslog from a program called asteroids will from now on be redirected to /var/log/asteroids.log.

Using rsyslog in a C program

Here’s a short C Program that puts a message in the asteroids file.

#include <syslog.h>
#include <stdio.h>

int main() {
    openlog("asteroids",LOG_CONS | LOG_PID | LOG_NDELAY, LOG_USER);    
    syslog(LOG_INFO,"Test Message %d",1);
    closelog();
}

In a typical program you’d put the openlog statement in main() near the start and the closelog() near the end of main, and uses as many syslog() calls throughout your program as you need.

Now what I suggest you do is open another terminal and run this command before you run your main program. This will just sit there printing out each message line as it appears in asteroids.log. You can stop tail by hitting ctrl-c.

tail -f /var/log/asteroids.log

H/T to this StackExchange answer from almost 8 years ago and answer by giuspen.

void InitSetup() {
	srand((int)time(NULL));
	SDL_Init(SDL_INIT_EVERYTHING);
	SDL_CreateWindowAndRenderer(WIDTH, HEIGHT, SDL_WINDOW_SHOWN, &screen, &renderer);
	if (!screen) {
		LogError("InitSetup failed to create window");
	}
	SetCaption("Example Two");
	LoadTextures();
}

And in the Debug Console I can see two of these:

@”error: XDG_RUNTIME_DIR not set in the environment.\r\n”

followed by my error message InitSetup failed to create window.

I’ve looked online and there’s one or two mentions. Now possibly it might be because I’m running Ubuntu 18.04 LTS under Hyper-V Manager.  I’ll try this on a laptop where I’ve installed the same version of Ubuntu on and see if the same thing happens.