SDL Crashes on Irix

I’m a student at Bournemouth University, UK. We have a few Computer
Animation & Visualization courses down here, along with hundreds of SGI
O2’s. For my major, I wanted to write an OpenGL game and was hoping I
could use the SDL library to make life easier.

I managed to get SDL compiled, once I found a machine with the dmedia
libs on it (lots don’t have it installed, strange). Managed to get the
everything linked in ok, but test program crashes as soon as I call
SDL_Init(SDL_INIT_VIDEO); I get a big seg. fault. Any ideas?

I sorry this is a bit vague, but I really don’t know the specs of our
O2’s, although I’ve tried several. And the line above is literally the
first thing in the main(){

Thanks in advance,

Arthur.

I’m a student at Bournemouth University, UK. We have a few Computer
Animation & Visualization courses down here, along with hundreds of SGI
O2’s. For my major, I wanted to write an OpenGL game and was hoping I
could use the SDL library to make life easier.

I managed to get SDL compiled, once I found a machine with the dmedia
libs on it (lots don’t have it installed, strange). Managed to get the
everything linked in ok, but test program crashes as soon as I call
SDL_Init(SDL_INIT_VIDEO); I get a big seg. fault. Any ideas?

I sorry this is a bit vague, but I really don’t know the specs of our
O2’s, although I’ve tried several. And the line above is literally the
first thing in the main(){

I’ve heard this but I haven’t been able to reproduce it. Is there any
way I can log into your box to check it out? In any case, as soon as I
can figure out the linking problems on my test IRIX box, I should be able
to sort this out.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Sam Lantinga wrote:

I managed to get SDL compiled, once I found a machine with the dmedia
libs on it (lots don’t have it installed, strange). Managed to get the
everything linked in ok, but test program crashes as soon as I call
SDL_Init(SDL_INIT_VIDEO); I get a big seg. fault. Any ideas?

I’ve heard this but I haven’t been able to reproduce it. Is there any
way I can log into your box to check it out? In any case, as soon as I
can figure out the linking problems on my test IRIX box, I should be able
to sort this out.

Don’t think you’d be able to log into our machines, the Uni has a big
firewall. Is there any information I can give you that would help in finding
the problem?

I don’t suppose you’d be able to give any time scale on when we may get this
problem fixed? You see I was intending to use SDL in my degree major
project, and well it’s pretty crucial I get my game running under Irix…
:frowning:

Regards,

Arthur Yarwood.

Don’t think you’d be able to log into our machines, the Uni has a big
firewall. Is there any information I can give you that would help in finding
the problem?

I don’t suppose you’d be able to give any time scale on when we may get this
problem fixed? You see I was intending to use SDL in my degree major
project, and well it’s pretty crucial I get my game running under Irix…
:frowning:

Well, yesterday I built SDL on our IRIX box, and tested it with remote
display and it worked fine. My IRIX box doesn’t have a monitor, so I
can’t tell if it’s a specific problem with the IRIX visuals.

What’s the output of xdpyinfo for your system?
If you could find somebody there who knows how to use a debugger and step
through the code to see where it crashes, that would be ideal. Otherwise
you can start inserting printf() statements into the code in SDL_video.c
to see how far it gets before crashing.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Sam Lantinga wrote:

If you could find somebody there who knows how to use a debugger and step
through the code to see where it crashes, that would be ideal. Otherwise
you can start inserting printf() statements into the code in SDL_video.c
to see how far it gets before crashing.

Right I’ve done this. I don’t think I properly recompiled it when I tried it
last. Anyways I’ve got some feedback now…
This is how far it got in the SDL_VideoInit() function in SDL_video.c.

/* Initialize the video subsystem */
printf(“init the video subsystem\n”); fflush(stdout);

memset(&vformat, 0, sizeof(vformat));
printf(“done memset\n”); fflush(stdout);
if ( video->VideoInit(video, &vformat) < 0 ) {
printf(“If was true.\n”); fflush(stdout);
SDL_VideoQuit();
return(-1);
}

It doesn’t get past the memset. Not sure why, I’ll leave that up to you guys…

Hope that helps,

Arthur Yarwood.

Sam Lantinga wrote:

If you could find somebody there who knows how to use a debugger and step
through the code to see where it crashes, that would be ideal. Otherwise
you can start inserting printf() statements into the code in SDL_video.c
to see how far it gets before crashing.

Right I’ve done this. I don’t think I properly recompiled it when I tried it
last. Anyways I’ve got some feedback now…
This is how far it got in the SDL_VideoInit() function in SDL_video.c.

/* Initialize the video subsystem */
printf(“init the video subsystem\n”); fflush(stdout);

memset(&vformat, 0, sizeof(vformat));
printf(“done memset\n”); fflush(stdout);
if ( video->VideoInit(video, &vformat) < 0 ) {
printf(“If was true.\n”); fflush(stdout);
SDL_VideoQuit();
return(-1);
}

It doesn’t get past the memset. Not sure why, I’ll leave that up to you guys…

Well, from past messages I’ve seen - could you try
"bzero(&vformat, sizeof(vformat)" instead of “memset(…)”?

Some architectures (PowerPC comes to mind) do not allow memset or
equivalent operations to run on videomemory…
(now I could be off in left base - actually if I remember rightly
"memcpy" was the offending operation but still)

G’day, eh? :slight_smile:
- TeunisOn Fri, 17 Nov 2000, Arthur Yarwood wrote:

memset(&vformat, 0, sizeof(vformat));
printf(“done memset\n”); fflush(stdout);
if ( video->VideoInit(video, &vformat) < 0 ) {
printf(“If was true.\n”); fflush(stdout);
SDL_VideoQuit();
return(-1);
}

It doesn’t get past the memset. Not sure why, I’ll leave that up to you guys…

Well, from past messages I’ve seen - could you try
"bzero(&vformat, sizeof(vformat)" instead of “memset(…)”?

Some architectures (PowerPC comes to mind) do not allow memset or
equivalent operations to run on videomemory…

Actually, you just have to worry about the alignment.
In this particular case, the destination of memset is an object allocated
on the stack, so I have no idea why it would crash trying to memset() it.

I probably won’t have access to an IRIX box until after my vacation next
week, so I don’t know when I’ll be able to look at this more. If anyone
is able to follow up, please let me know. I’ll definitely check it again
before releasing the next version of SDL.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

memset(&vformat, 0, sizeof(vformat));
printf(“done memset\n”); fflush(stdout);
if ( video->VideoInit(video, &vformat) < 0 ) {
printf(“If was true.\n”); fflush(stdout);
SDL_VideoQuit();
return(-1);
}

It doesn’t get past the memset. Not sure why, I’ll leave that up to you guys…

Please post the generated assembly for that function, preferrably commented
with the original source code (as objdump -S dumps it). Did you build it
as a 32-bit or 64-bit binary?

Mattias Engdeg?rd wrote:

memset(&vformat, 0, sizeof(vformat));
printf(“done memset\n”); fflush(stdout);
if ( video->VideoInit(video, &vformat) < 0 ) {
printf(“If was true.\n”); fflush(stdout);
SDL_VideoQuit();
return(-1);
}

It doesn’t get past the memset. Not sure why, I’ll leave that up to you guys…

Please post the generated assembly for that function, preferrably commented
with the original source code (as objdump -S dumps it). Did you build it
as a 32-bit or 64-bit binary?

You’ll have to help me here. How do I go about getting the generated
assembly?

As for 32 or 64 bit, I think it is 32. I remember having trouble with
the older O2’s making o32 objects while the newer ones (which I’m using
at the mo) were building n32 objects.

Arthur

You’ll have to help me here. How do I go about getting the generated
assembly?

I’m not really familiar with Irix, nor with MIPS, but we could make an
educated guess. If you have GNU objdump, try objdump -S thefile.o. It will
be large so please either post an url to where we can find the output,
or edit it so only the relevant function is present. Or you could try
compiling that file with assembly output (usually -S as an option to the
compiler). Or you could find the corresponding Irix utility to dump
the assembly code (maybe “dis” or “objdump”). Read the man pages.
As a last ditch, try disassembling the function from your debugger

Some architectures (PowerPC comes to mind) do not allow memset or
equivalent operations to run on videomemory…

Why?

Some architectures (PowerPC comes to mind) do not allow memset or
equivalent operations to run on videomemory…

Why?

Sorry - as described sorta earlier I might as well clean up here…

It’s a problem not with the memset or the like but that access to videoram
on these beasties (PowerPC) needs to be aligned - usually on 4-byte
boundaries (possibly) - at all times.

Most of the info I got on these things is hearsay though.

Could be Irix is the same way…

For the PowerPC (and old Alpha systems IIRC) is that the memory that’s
from the PCI bus doesn’t have any special handling to allow byte-access or
shortword-access but only buswidth-sized block accesses. Basically this
means if your bus is 4 bytes wide all accesses have to be in that
size.

The long and the short of it is -> try accessing like
unsigned int* p = (address of memory) [hmmm… 32 bit access here]
for (unsigned int q=(size of memory)/4; q; q–) *p++=0;

I think this might work but it’s just a guess from my head on the spot
without looking at anything like a compiler.

Well, hopefully this explanation makes more sense to you than me :slight_smile:
G’day, eh? :slight_smile:
- TeunisOn Mon, 20 Nov 2000, Mattias Engdeg?rd wrote:

It’s a problem not with the memset or the like but that access to videoram
on these beasties (PowerPC) needs to be aligned - usually on 4-byte
boundaries (possibly) - at all times.

Really? I cannot find anything in the architecture that mandates that.
Not that there would be a good idea to use unaligned accesses anyway,
since they are likely to be (especially if they cross a page or BAT
boundary). I’m trying to learn the PPC architecture, so I would be
grateful for an explanation.

Could be Irix is the same way…

No way, MIPS processors always trap on unaligned accesses as far as I
know

For the PowerPC (and old Alpha systems IIRC) is that the memory that’s
from the PCI bus doesn’t have any special handling to allow byte-access or
shortword-access but only buswidth-sized block accesses. Basically this
means if your bus is 4 bytes wide all accesses have to be in that
size.

That can’t be right. I know about the problems with pre-EV5 alphas,
but it was architected that way. For the PPC it sounds more like an
implementation bug^H^H^Hissue to me. I have a hard time believing it,
since so many complained about it on the Alpha so that Digital changed
their mind

It’s a problem not with the memset or the like but that access to videoram
on these beasties (PowerPC) needs to be aligned - usually on 4-byte
boundaries (possibly) - at all times.

Really? I cannot find anything in the architecture that mandates that.

I can verify that. You can’t use memset() on video memory on PPC
without checking the alignment first. :slight_smile:

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Sam Lantinga wrote:

If you could find somebody there who knows how to use a debugger and step
through the code to see where it crashes, that would be ideal. Otherwise
you can start inserting printf() statements into the code in SDL_video.c
to see how far it gets before crashing.

Right I’ve done this. I don’t think I properly recompiled it when I tried it
last. Anyways I’ve got some feedback now…

Good news, I’ve been able to reproduce this problem here.

I’ll look into it.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

I can verify that. You can’t use memset() on video memory on PPC
without checking the alignment first. :slight_smile:

Why?

It’s a problem not with the memset or the like but that access to videoram
on these beasties (PowerPC) needs to be aligned - usually on 4-byte
boundaries (possibly) - at all times.

Really? I cannot find anything in the architecture that mandates that.
Not that there would be a good idea to use unaligned accesses anyway,
since they are likely to be (especially if they cross a page or BAT
boundary). I’m trying to learn the PPC architecture, so I would be
grateful for an explanation.

If it helps any I remember it being something specific to graphic devices
:slight_smile:
This is from ummm prolly 2 years ago on the GGI development…
It’s related to the PCI/memory bus if that helps - not really part of the
core architecture.

From messages I’ve seen even here I’d suspect that unaligned accesses on
powerpc graphical devices is still not permitted.
iirc there’s other systems too - though I’d be quite surprised if Irix
were that way. Could depend on the video hardware too - although PCI page
alignment is handled by the bus controller…

G’day, eh? :slight_smile:
- TeunisOn Mon, 20 Nov 2000, Mattias Engdeg?rd wrote:

I wrote:

I can verify that. You can’t use memset() on video memory on PPC
without checking the alignment first. :slight_smile:

Why?

Sorry for replying to my own message, but a reasonable explanation could
be that the PPC memset() implementation is using a dcbz instruction
to directly zero cache blocks without reading them first. This is of
course only the case if memset() is passed zero as the value.
Since video memory is marked as uncacheable, an alignment exception
is generated.

I found this nugget in SDL_surface.c:

	for ( y=dstrect->h; y; --y ) {

#ifdef powerpc /* SIGBUS when using memset() ?? */
if ( color ) {
Uint8 *rowp = row;
int left = x;
while ( left-- ) { *rowp++ = color; }
} else {
Uint8 *rowp = row;
int left = x;
while ( left-- ) { *rowp++ = 0; }
}
#else
memset(row, color, x);
#endif

This looks overly conservative. A more efficient implementation would
be:

if powerpc AND hwsurface AND colour == 0
do it manually, but still store entire words (not bytes)
else
memset()

I can whip up a patch that fixes this when I get some free time, but if
any PPC hacker wants to do it right away then that’s great.
Oh, and please post a disassembly of the PPC memset() – it would be
interesting to see if it actually uses dcbz

Cheers,

Mattias
ppc newbie

Mattias Engdeg?rd wrote:

You’ll have to help me here. How do I go about getting the generated
assembly?

I’m not really familiar with Irix, nor with MIPS, but we could make an
educated guess. If you have GNU objdump, try objdump -S thefile.o. It will
be large so please either post an url to where we can find the output,
or edit it so only the relevant function is present. Or you could try
compiling that file with assembly output (usually -S as an option to the
compiler). Or you could find the corresponding Irix utility to dump
the assembly code (maybe “dis” or “objdump”). Read the man pages.
As a last ditch, try disassembling the function from your debugger

I’ve done an assembly dump of the SDL_video.o object. You can find it
and the source file I edited at:

http://fubaby.com/SDL_video.objectdump.txt
http://fubaby.com/SDL_video.c

Hope that’s of some help. I did a ‘dis -S’ in the end. objdump didn’t
seem to be installed on these machines.

Regards,

Arthur Yarwood.

I’ve done an assembly dump of the SDL_video.o object. You can find it
and the source file I edited at:

http://fubaby.com/SDL_video.objectdump.txt
http://fubaby.com/SDL_video.c

Hope that’s of some help. I did a ‘dis -S’ in the end. objdump didn’t
seem to be installed on these machines.

By the way, the IRIX crash was fixed in CVS a week ago.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software