A few glSDL crashes

SDL Development
1

Hi! I’ve been learning to use SDL for about the last week or so, and
yesterday I discovered glSDL 0.6. For the most part it’s working
great, but I’ve encountered a couple of things that cause it to crash.

First, using the default glsdl.c and glsdl.h, I noticed that my program
would always crash during the cleanup on exit. I traced this to line
562 of glsdl.c, which looks like:

free(fake_screen);

However, because fake_screen is an SDL_Surface*, SDL_FreeSurface()
should be used, right? I changed it to:

SDL_FreeSurface(fake_screen);

With that, it works fine for me. I thought it was very odd, though,
that there was a bug this prominent; has nobody else encountered that
problem? Or is there a reason why free() was used? Also, I would bet
that the package maintainer reads this list, but if somebody can tell
me for certain that he doesn’t, let me know and I’ll forward that to
him.

Second, I’ve encountered another reproducible crash that I haven’t
found a fix for yet. The program crashes any time I blit from the
framebuffer to another surface; for a quick example:

SDL_Surface* screen, target_surface;
screen = SDL_SetVideoMode(800, 600, 32,
SDL_HWSURFACE|SDL_ANYFORMAT|SDL_DOUBLEBUF|SDL_GLSDL);
target_surface = SDL_DisplayFormat(screen);
SDL_BlitSurface(screen, NULL, target_surface, NULL);

If I run this on my WinXP box with Visual Studio .NET 2003, it crashes
every time. However, it appears to work fine on my PowerBook G4 with
OS X 10.3.4 (but there might be bad things going on in the background
that I can’t see). Both have SDL 1.2.7 installed. Any ideas?–
P. J. Reed
"If you aren’t voiding the warranty, you aren’t even trying."
http://sakabatou.net/
Hi! I’m a .sig virus! Copy me into yours and join in the fun!

2

Hi! I’ve been learning to use SDL for about the last week or so,
and yesterday I discovered glSDL 0.6. For the most part it’s
working great, but I’ve encountered a couple of things that cause
it to crash.

First, using the default glsdl.c and glsdl.h, I noticed that my
program would always crash during the cleanup on exit. I traced
this to line 562 of glsdl.c, which looks like:

free(fake_screen);

However, because fake_screen is an SDL_Surface*, SDL_FreeSurface()
should be used, right? I changed it to:

SDL_FreeSurface(fake_screen);

Oops… hehe

With that, it works fine for me. I thought it was very odd,
though, that there was a bug this prominent; has nobody else
encountered that problem?

Well, it would normally just cause a memory leak, so no one noticed
it, simply because it normally doesn’t cause a crash.

Not sure what’s going on on your system… Does the SDL version and/or
backend you’re using have strings attached to all surfaces created?
That could result in a double free when closing SDL or something…

Or is there a reason why free() was
used?

Nope, it’s just a typo. That surface is created with
SDL_CreateRGBSurface(), and there’s nothing special about it; it’s
just a s/w surface. (It’s used when simulating display surface
locking, and as a buffer when blitting from the OpenGL frame buffer.)

Also, I would bet that the package maintainer reads this
list, but if somebody can tell me for certain that he doesn’t, let
me know and I’ll forward that to him.

The bug is now fixed in my 0.7 tree.

Second, I’ve encountered another reproducible crash that I haven’t
found a fix for yet. The program crashes any time I blit from the
framebuffer to another surface; for a quick example:

SDL_Surface* screen, target_surface;
screen = SDL_SetVideoMode(800, 600, 32,
SDL_HWSURFACE|SDL_ANYFORMAT|SDL_DOUBLEBUF|SDL_GLSDL);
target_surface = SDL_DisplayFormat(screen);
SDL_BlitSurface(screen, NULL, target_surface, NULL);

I’m not sure about 0.6, but in my 0.7 tree, I found this:On Wednesday 02 June 2004 01.09, P.J.Reed wrote:

    if(srcrect)
            sr = *srcrect;
    else
    {
            sr.x = sr.y = 0;
            sr.w = dst->w;

  •           srcrect = &sr;
  }

  if(dstrect)
          dr = *dstrect;
  else

  •   {
          dr.x = dr.y = 0;

  •           dstrect = &dr;

  •   }

The marked lines were missing, so passing NULL for one or both
rectangles when blitting from the screen would most likely cause a
segfault.

Rather weird that it doesn’t crash on OS X, actually. Are you sure
you’re actually compiling and/or using the glSDL layer?

Please try this snapshot and see if that works better - or rather, if
it works at all: :wink:

http://www.olofson.net/download/glSDL-20040602.tar.gz

(There are a number of other changes in this one as well, such as
dynamic GL lib loading, two-way tiling/“huge surface” support, some
minor optimizations, a few other fixes, and a new test program for
the two-way tiling.)

Thanks a lot for reporting these bugs! :slight_smile:

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

3

Not sure what’s going on on your system… Does the SDL version and/or
backend you’re using have strings attached to all surfaces created?
That could result in a double free when closing SDL or something…

Actually, I think it may have done that because of some debugging code
I have in VS.NET that causes it to raise an exception whenever
something isn’t freed with a program closes.

> The marked lines were missing, so passing NULL for one or both > rectangles when blitting from the screen would most likely cause a > segfault.

Hmm, that makes sense. With that change, it no longer crashes when I
do a blit, but it still doesn’t do the blit properly; it seems to only
copy a black square. I get the same result when I specify rectangles,
too. Here’s a small sample file I put together:
http://speed.sakabatou.net/test.cpp

It creates a 800x600 SDL_Surface named screen, then loads a 800x600
image named “shodan.png” and blits it to screen (feel free to use your
own 800x600 image); it blits a 60x60 square from near the middle of
screen to another surface, then blits that surface back to the
upper-left corner of screen. It works properly without SDL_GLSDL set,
but with it set, I just get a black square in the corner.

Rather weird that it doesn’t crash on OS X, actually. Are you sure
you’re actually compiling and/or using the glSDL layer?

Yes, I’m pretty sure; the frame rate jumps very noticeably from 40 fps
to about 460 fps. :wink: I also get messages from glSDL to stdout and
stderr. It seems like stdout just prints out the size of the main
surface, but stderr prints out a “Leaked TexInfo” message every time I
load an image, followed by the image’s resolution.

Please try this snapshot and see if that works better - or rather, if
it works at all: :wink:

Well, it compiles, but doesn’t quite work; it runs fine under OS X, but
the blitting behaves like I said above. Also, under WinXP it crashes
on startup. VS.NET’s debugger offers the following call stack trace:

experiment.exe!UnloadTexture(glSDL_TexInfo * txi=0x003e5e98) Line 2077

  • 0x21 C
    experiment.exe!FreeTexInfo(unsigned int handle=1) Line 338 + 0x12
    C
    experiment.exe!glSDL_FreeTexInfo(SDL_Surface * surface=0x003b6aa0)
    Line 360 + 0xc C
    experiment.exe!glSDL_FreeSurface(SDL_Surface * surface=0x003b6aa0)
    Line 919 + 0x9 C
    experiment.exe!init_formats() Line 592 + 0x9 C
    experiment.exe!glSDL_SetVideoMode(int width=800, int height=600, int
    bpp=32, unsigned int flags=1342177283) Line 835 C
    experiment.exe!SDL_main(int argc=1, char * * argv=0x0012fe7c) Line 16
  • 0x16 C++
    experiment.exe!_main() + 0xd9 C
    experiment.exe!_WinMain at 16() + 0x1ca C
    experiment.exe!WinMainCRTStartup() Line 390 + 0x39 C
    kernel32.dll!77e814c7()

And it gives the error message, “Run-Time Check Failure #0 - The value
of ESP was not properly saved across a function call. This is usually
a result of calling a function declared with one calling convention
with a function pointer declared with a different calling convention.”

Does that mean anything to you? It could be something wrong I’m doing
in VS.NET, since OS X doesn’t seem to have a problem.

Thanks a lot for reporting these bugs! :slight_smile:

No problem!On Jun 1, 2004, at 8:14 PM, David Olofson wrote:

P. J. Reed
"If you aren’t voiding the warranty, you aren’t even trying."
http://sakabatou.net/
Hi! I’m a .sig virus! Copy me into yours and join in the fun!