Ok, I got rid of the stinky SuSE SDL rpm and downloaded the source (version
1.2.3) so I could trace through it and see exactly where it’s crashing.
Well, the program is actually crashing on line 1241 of SDL_video.c. That
line is this (and the comment before it):
/* Clean up the system video */
video->VideoQuit(this);
There are no surfaces locked and it does this if I free the main surface
before calling SDL_Quit or not.
My other thought is this: I use a Matrox G450 dual head, using both heads
(without using xinerama). Could that have anything to do with it? I can
try disabling the second head and trying the program if anyone thinks
that’ll help any.–
- Mik Mifflin
.doog era syeknoM
Mik Mifflin wrote:
Ok, I got rid of the stinky SuSE SDL rpm and downloaded the source
(version 1.2.3) so I could trace through it and see exactly where it’s
crashing.
Well, the program is actually crashing on line 1241 of SDL_video.c. That
line is this (and the comment before it):
/* Clean up the system video */
video->VideoQuit(this);
There are no surfaces locked and it does this if I free the main surface
before calling SDL_Quit or not.
My other thought is this: I use a Matrox G450 dual head, using both heads
(without using xinerama). Could that have anything to do with it? I can
try disabling the second head and trying the program if anyone thinks
that’ll help any.
oops, and that bit of code (line 1241) is in SDL_VideoQuit(). Should of
said that the first time around.–
- Mik Mifflin
.doog era syeknoM
“Mik Mifflin” wrote in message
news:a1ocq5$frk$1 at ftp.lokigames.com…
Ok, I got rid of the stinky SuSE SDL rpm and downloaded the source
(version
1.2.3) so I could trace through it and see exactly where it’s crashing.
Well, the program is actually crashing on line 1241 of SDL_video.c. That
line is this (and the comment before it):
/* Clean up the system video */
video->VideoQuit(this);
There are no surfaces locked and it does this if I free the main surface
before calling SDL_Quit or not.
For the record, you are not supposed to free the main surface.
This whole thing smells of corrupted memory to me.–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Rainer Deyke wrote:
“Mik Mifflin” wrote in message
news:a1ocq5$frk$1 at ftp.lokigames.com…
Ok, I got rid of the stinky SuSE SDL rpm and downloaded the source
(version
1.2.3) so I could trace through it and see exactly where it’s crashing.
Well, the program is actually crashing on line 1241 of SDL_video.c. That
line is this (and the comment before it):
/* Clean up the system video */
video->VideoQuit(this);
There are no surfaces locked and it does this if I free the main surface
before calling SDL_Quit or not.
For the record, you are not supposed to free the main surface.
This whole thing smells of corrupted memory to me.
–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
OK, so I take that part out again, and it still crashes for the record.–
- Mik Mifflin
.doog era syeknoM
Mik Mifflin wrote:
Rainer Deyke wrote:
“Mik Mifflin” wrote in message
news:a1ocq5$frk$1 at ftp.lokigames.com…
Ok, I got rid of the stinky SuSE SDL rpm and downloaded the source
(version
1.2.3) so I could trace through it and see exactly where it’s crashing.
Well, the program is actually crashing on line 1241 of SDL_video.c.
That line is this (and the comment before it):
/* Clean up the system video */
video->VideoQuit(this);
There are no surfaces locked and it does this if I free the main surface
before calling SDL_Quit or not.
For the record, you are not supposed to free the main surface.
This whole thing smells of corrupted memory to me.
–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
OK, so I take that part out again, and it still crashes for the record.
OH MY GOD! Sorry for all the useless posts. I had traced through ALL of
my code and seen nothing at all wrong with it. Then I decided to take a
look at my header file (where no code is walked through by the debugger),
and damn it, it was sitting right there! I was storing my coords for my
polygons in ints, and allocating for Uint16’s. That teaches me to use old
code of mine without checking it all over good. Well, guess you were
right, corrupted memory, I was writing out past the array. Wouldn’t that
have crashed when I tried to write out past the array? Or does it only
crash when I write over mem not owned by the process?–
- Mik Mifflin
.doog era syeknoM
Mik Mifflin wrote:
OH MY GOD! Sorry for all the useless posts. I had traced through ALL of
my code and seen nothing at all wrong with it. Then I decided to take a
look at my header file (where no code is walked through by the debugger),
and damn it, it was sitting right there! I was storing my coords for my
polygons in ints, and allocating for Uint16’s. That teaches me to use old
code of mine without checking it all over good. Well, guess you were
right, corrupted memory, I was writing out past the array. Wouldn’t that
have crashed when I tried to write out past the array? Or does it only
crash when I write over mem not owned by the process?
Depends on the OS. Under Windows 95/98/nt/2000/me/xp/lsmft, Linux, UNIX,
and all other OSes that use hardware memory protection the OS will crash
your
code if you step out side of your allocated memory. On older OSes such
as
Windows 1.0 - 3.x, classic MacOS, and DOS (yes you can have multiple
processes
under DOS) the OS will not crash you even when you write over memory
that
belongs to some other process. Aside from that, as long as you stay
inside
the lines you can write anywhere and you just get really strange
behavior.
Some languages, including Java and pretty much all the scripting
languages
I’ve ever looked at check all memory accesses and will give you an error
if
you do what you did. But, all those checks do slow down your code.
Bob P.>
–
- Mik Mifflin
.doog era syeknoM
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------+
- Bob Pendleton is seeking contract +
- and consulting work. Find out more +
- at http://www.jump.net/~bobp +
±-----------------------------------+
right, corrupted memory, I was writing out past the array. Wouldn’t that
have crashed when I tried to write out past the array? Or does it only
crash when I write over mem not owned by the process?
(It happens, it happens…)
If you write a memory page you don’t own, you get a segfault. Memory pages
in Linux are (I think) 4096 bytes, which may or may not hold other
variables besides the array in question. It may not hold anything
specific, either, but if it’s in that page, it doesn’t cause a segfault.
This is how overrun detectors like ElectricFence work; they make sure
every allocation lands on the edge of a page, and that the page right
after it is flagged as forbidden, so you get a very clear sign when you’ve
overflowed a buffer.
Frequently, array overruns will not crash a program in Linux that crashes
win32, and vice versa. Another good argument for porting: code quality
increases.
Anyhow.
–ryan.