Colour bar glitch, possibly with loading BMPs

SDL Development
1

In this code I initially created the phase scope object (which uses SDL_LoadBitmap) after the wave surface, however this caused strange horizontal colour bars at the top of the scope (see uploaded pic). Changing the order fixed it (though I’ve no idea why, the scope doesn’t depend on the wave surface creation).

Also, with the glitch the program ran fine until I exited and SDL_FreeSurface was called, which made it exit with a bad value.

txs glitch

Even though this fixed that particular glitch, now I’ve brought in a fader UI class that I made last year (and has always worked perfectly) - every now and then the same glitch happens with the fader. It’s by no means every time, about 1 in 6 times. This class uses SDL_LoadBitmap too, so I was wondering if I was doing something wrong with calling that. Must I create a surface before loading a BMP into it, or will SDL_LoadBitmap do that for me?

XY_scope = new TXS_phase_scope (scr_scanner, dest_window_surface);      // If this is done after wave_surface creation, weird glitch happens.

    wave_surface = SDL_CreateRGBSurface
    (
        SDL_SWSURFACE,

        TXS_WAVE_WIDTH,
        TXS_WAVE_HEIGHT,

        TXS_SCREEN_BPP,

        main_window_format->Rmask,
        main_window_format->Gmask,
        main_window_format->Bmask,
        main_window_format->Amask
    );
3

Possibly, but I was aware of SDL’s load BMP function, so used it. Regardless as to the format’s relevance, SDL supports it, Photoshop supports it, so I thought I’d use BMP, even if just for now.

But do you know of anything BMP-specific that might cause this glitch?

5

With all due respect, I didn’t start this thread to discus the obsolescence of image formats. SDL loads BMPs, it’s a ubiquitous format so I thought I’d use it, at least for now.

However, I do believe the bug to be related to loading images (maybe it’s just BMPs, maybe not) because it’s only ever manifested itself in those situations. Here’s a pic I took of the fader glitch (the one that only happens now and then).

txs glitch 2

Now, the fader comes in 3 segment types, left end, right end and midsection (which is repeated depending on how long you want the fader to be). As you can see, the left segment is fine (as it the fader knob, which is also a BMP) - but the mid and right segments are showing that same colour bar glitch.

In this example the program is still perfectly usable, but sometimes the glitch is with the fader knob itself. When that happens the program crashes instantly.

I will look into other formats but for now, can anyone offer any insight into this?

1 Like
6

I’d also like to add that, obsolete format or not, the glitch reported in my opening post really shouldn’t be dependent on the order of the two statements in my code. Or should it? As I say if anyone can shed any light I’d be eternally grateful.

I’ll also experiment with the various BMP export parameters Photoshop offers, in case that helps.

EDIT: I did that - “Flip Row Order” seemed to fix it but it glitched again after about 3 runs :frowning:

7

I just moved the code that creates and initialises faders much earlier in the initialisation process and that seemed to fix it. Again, it seems that order of execution was a major factor here (but I can’t see how).

Could this be a bug in SDL?

8

Can you post a minimal example reproducing the error? Patterns/color glitches like that tend to happen if you draw surfaces that have uninitialized pixels and similar things.

SDL_LoadBMP creates a ready to use surface-or null on error. Always check for null!

9

Given that order in which TXS_phase_scope and SDL_CreateRGBSurface are called matters for the repro, I suspect there’s some buffer overrun. As for the original question about SDL_LoadBMP:

Must I create a surface before loading a BMP into it, or will SDL_LoadBitmap do that for me?

The SDL_LoadBMP api is returning fresh surface that you must at some point (typically on exit) release.

SDL_Surface *surface = SDL_LoadBMP(file);
// do stuff with the surface
SDL_FreeSurface(surface);

Also, with the glitch the program ran fine until I exited and SDL_FreeSurface was called, which made it exit with a bad value.

If at some point in the lifetime of your app SDL_FreeSurface is failing, it’s likely that the surface handle is incorrect. You should track where it’s used as it’s likely that it was released twice (hence the bug).

As for what @mkalte said:

SDL_LoadBMP creates a ready to use surface-or null on error. Always check for null!

True, always check for null. But even if you got null from SDL_LoadBMP (or anywhere else where surface is being created), I’d expect no drawing to happen whenever you call some API that takes surface as an argument. All such functions internally should start with:

    if (!surface) {
        SDL_SetError("Passed NULL surface");
        return NULL;
    }

So if that’s not the case, it’s a bug. I strongly suspect, however, that you’re stomping on a memory in a completely different place and cause all sorts of problems to appear at random. You should run your code through address sanitizer or valgrind, @stereogram.

Yes but it probably isn’t. :slight_smile: Likelihood of bugs goes like this: obscure libraries nobody uses, your code, well established libraries, compiler, OS.

10

What’s the “repro”?

Also, as for the minimal example, the code at the start was the best I could think of. It seems that anything that loads BMPs may glitch unless it’s called as early as possible (at least in my code). Which is odd because it’s usually the other way around - calling things too early before other things have been initialised is an obvious bug trap.

And LoadBMP seems to be “atomic”, plus it depends on nothing except a surface pointer (which technically you don’t even need if you don’t take LoadBMP’s return value - although you’d never do that in practice).

I’ll see if I can come up with a better, minimal example (just like Bjarne Stroustoup says, if I do that the bug might become clear to me).

11

It ran fine, as in it was usable but the colour glitch was present. I checked and it was only released once, on exit - whereas this glitch was during runtime. Despite the glitch, the surface was usable, displayable, etc, and only crashed on the (one) release call on exit.

12

Repro is short for reproduction.

Your initial code is not a minimal example - you’re calling TXS_phase_scope which we know nothing about and is the most likely source of problem. It has to be a reasonably complete code, not a snippet.

I checked and it was only released once, on exit - whereas this glitch was during runtime. Despite the glitch, the surface was usable, displayable, etc, and only crashed on the (one) release call on exit.

How did you check that it was only released once?
Are you sure data behind the handle wasn’t corrupted?
How did you verify that?
Just because you can read data (surface was displayable) doesn’t mean that memory it’s pointing to isn’t corrupted.