SDLQuake Segfault??

[Knappster]

Hi,

As a little project I'm trying to get SDLQuake to run on my Raspberry Pi.

I've grabbed the code from here: http://www.libsdl.org/projects/quake/

So far I've got the thing to compile but when trying to start a new game from the in game menu I get a segmentation fault. I'm not a wizz at this but using gdb I've got the following info:

Program received signal SIGSEGV, Segmentation fault.
0xb6def284 in fread () from /lib/arm-linux-gnueabihf/libc.so.6

Is it simply the case that I'm linking to the wrong libs or something stranger?

Here's the Makefile I've hacked up to get it to compile: http://pastebin.com/LWQDLyms

[Mechduino]

I believe segmentation faults are usually issues with a lack of ram.

[Knappster]

Well googling this thing to death still hasn't got me anywhere. Obviously it's an issue reading a file of some kind. I've checked that the pak files are ok, it's either a problem in the code itself or /lib/arm-linux-gnueabihf/ is the wrong lib to be using on the RPi. I don't think it is.

Anyone know of a way of finding where in the code this error might be occuring?

It certainly doesn't seem to be lack of ram.

[Knappster]

OK I've learned a bit more about using gdb and have the traced whereabouts the error is.

This is part of the trace from gdb:

#0 0xb6def284 in fread () from /lib/arm-linux-gnueabihf/libc.so.6
#1 0x000475e0 in Sys_FileRead (handle=115, dst=<optimized out>, count=413116) at sys_sdl.c:218
#2 0x00010f5c in COM_LoadFile (path=0x51c6c "progs.dat", usehunk=<optimized out>) at common.c:1583
#3 0x0002e004 in PR_LoadProgs () at pr_edict.c:995

PR_LoadProgs() calls COM_LoadHunkFile() like this:

Code: Select all

progs = (dprograms_t *)COM_LoadHunkFile ("progs.dat");

This is the COM_LoadFile function:

Code: Select all

cache_user_t *loadcache;
byte    *loadbuf;
int             loadsize;
byte *COM_LoadFile (char *path, int usehunk)
{
	int             h;
	byte    *buf;
	char    base[32];
	int             len;

	buf = NULL;     // quiet compiler warning

// look for it in the filesystem or pack files
	len = COM_OpenFile (path, &h);
	if (h == -1)
		return NULL;
	
// extract the filename base name for hunk tag
	COM_FileBase (path, base);
	
	if (usehunk == 1)
		buf = Hunk_AllocName (len+1, base);
	else if (usehunk == 2)
		buf = Hunk_TempAlloc (len+1);
	else if (usehunk == 0)
		buf = Z_Malloc (len+1);
	else if (usehunk == 3)
		buf = Cache_Alloc (loadcache, len+1, base);
	else if (usehunk == 4)
	{
		if (len+1 > loadsize)
			buf = Hunk_TempAlloc (len+1);
		else
			buf = loadbuf;
	}
	else
		Sys_Error ("COM_LoadFile: bad usehunk");

	if (!buf)
		Sys_Error ("COM_LoadFile: not enough space for %s", path);
		
	((byte *)buf)[len] = 0;

	Draw_BeginDisc ();
	Sys_FileRead (h, buf, len);                     
	COM_CloseFile (h);
	Draw_EndDisc ();

	return buf;
}

And finally the Sys_FileRead function where the call to fread is:

Code: Select all

int Sys_FileRead (int handle, void *dst, int count)
{
	char *data;
	int size, done;

	size = 0;
	if ( handle >= 0 ) {
		data = dst;
		while ( count > 0 ) {
			done = fread (data, 1, count, sys_handles[handle]);
			if ( done == 0 ) {
				break;
			}
			data += done;
			count -= done;
			size += done;
		}
	}
	return size;
		
}

Hopefully this will help .

[Knappster]

I asked a few folks on a Quake forum about the issue. They suggested I tried to compile it with optimisation set to -O0 and it now works. Something goes horribly wrong when gcc tries to optimise it :/. They also suggested I try fteqw, which has a gles support, I'll let you know how it goes.

[pjtpjt]

I ran into this one myself when I turned optimization on. And it sure isn't gcc's fault. This is the caller code:

Code: Select all

	progs = (dprograms_t *)COM_LoadHunkFile ("progs.dat");
	if (!progs)
		Sys_Error ("PR_LoadProgs: couldn't load progs.dat");

And gcc says the first string constant "progs.dat" is practically the end of "PR_LoadProgs: couldn't load progs.dat", so we'll only use one, so the first string points into the longer one.

And COM_FileBase starts to search backwards from the dot "." to the beginning of the path (which is only "progs.dat") and since there's no '/' character in it it will search till the end of the longer string. And it's 33 characters, which will overwrite the the handle variable to 115 (lowercase 's').

Code: Select all

void COM_FileBase (char *in, char *out)
{
	char *s, *s2;
	s = in + strlen(in) - 1;
	while (s != in && *s != '.')
		s--;
	
-->  for (s2 = s ; *s2 && *s2 != '/' ; s2--)
	;
	
	if (s-s2 < 2)
		strcpy (out,"?model?");
	else
	{
		s--;
		strncpy (out,s2+1, s-s2);
		out[s-s2] = 0;
	}
}

The fix is, change

Code: Select all

for (s2 = s ; *s2 && *s2 != '/' ; s2--)[

to

Code: Select all

for (s2 = s ; s2 > in && *s2 != '/' ; s2--)