SDL in XP

Alright, I’m kinda curious now.

I started work on my first SDL game in XP, and well… I’m having a bit of
trouble with the blit.
Now, I compiled the program, and I got a seg fault, for reasons which
completely boggle my mind. Feeling a bit curious, I sent the same exact
program that seg faulted on my machine over to my friend who is running
Windows 98.

It ran fine.
So I rebooted, Powered Off, everything I could think of to make sure I had
all 320 megs of ram back, and still nada.

Is it just some kinda crazy problem in XP?

My friend has a TNT2 (Same card as me) and 128 megs of RAM, and a 500 mhz.
I have TNT2 320, and 450mhz

-Bryan Arant

Now, I compiled the program, and I got a seg fault, for reasons which
completely boggle my mind. Feeling a bit curious, I sent the same exact
program that seg faulted on my machine over to my friend who is running
Windows 98.

It ran fine.

This doesn’t actually mean there’s no bugs in the program. I had something
similar to this happen not long ago, only with linux and WinMe. All worked
fine under linux, cross-compiled it and ran it on the Windows machine, and
it crashed straight away. “Stupid lousy Windows!” I declared, and proceded
to litter the program with debugging messages (no debugger)

Turned out I was overflowing an array, and quite severely too. My guess as
to why Windows refused to let it run and linux let it happily trappled over
chunks of unallocated memory is that this memory wasn’t allocated to other
programs, so it just let it keep going. This could be a load of crap tho :slight_smile:

So my advice would be, if you can’t run it under a debugger on XP, print out
a whole bunch of messages and see where it dies. I like to have a function
or macro that will open a file (e.g. debug.log) in append mode, write a line
out, and close the file again, just to be sure that it gets written to disc
before the crash. This might be overkill, but better safe then sorry…

Is it just some kinda crazy problem in XP?

It’s possible, but I doubt it – my game works fine for me (now that I’ve
fixed that bug) on Windows XP and Me.

Make sure you’re checking the return status of everything - perhaps your
image isn’t being loaded properly on XP for some reason, or something like
that.On Sun, 30 Dec 2001, Bryan Arant wrote:


Mike.

Mike wrote:

Turned out I was overflowing an array, and quite severely too. My
guess as to why Windows refused to let it run and linux let it happily
trappled over chunks of unallocated memory is that this memory
wasn’t allocated to other programs, so it just let it keep going. This
could be a load of crap tho :slight_smile:

Under Windows, if you’re building a debug build, then every time you
allocate memory, it’s initialized to a hex value of #CCCCCC so you’ll know
you haven’t done anything with it yet. Likewise, there are other codes for
whether you just deallocated memory, if the memory you’re looking at’s a
pointer or not, etc. You can see this in Visual C++ by throwing in a break-
point and checking the values.

Linux just gives you a blank (zerod-out) memory address when you allocate
memory. You can get similar functionality to windows, though, with some
add-on development libraries which replace the new and delete calls with
their own implementations.

James–
James Helferty
@jhelfert_at_chat.car

jhelfert at chat.carleton.ca wrote:

Linux just gives you a blank (zerod-out) memory address when you allocate
memory.

the kernel always zeroes newly allocated pages (from anon mappings), but
malloc() and the default operator new make no such guarantees.
Use calloc() or memset() for zeroed allocations