"Frame not in module" when using glTexImage2D

Question

I have never come across this error before and I use glTexImage2D elsewhere in the project without error. Below is a screenshot of what error Visual Studio shows, and a view of the disassembly:

Given the line has ptr in it I assume there's a pointer error but I don't know what I'm doing wrong. Below is the function I use to convert from an SDL_surface to a texture.

void surfaceToTexture(SDL_Surface *&surface, GLuint &texture) {
    glEnable(GL_TEXTURE_2D);
    glGenTextures(1, &texture);
    glBindTexture(GL_TEXTURE_2D, texture);

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, surface->w, surface->h, 0, GL_BGRA, GL_UNSIGNED_BYTE, surface->pixels);
    glDisable(GL_TEXTURE_2D);
}

This function succeeds elsewhere in the program, for example when loading text:

SDL_Surface *surface; 
surface = TTF_RenderText_Blended(tempFont, message.c_str(), color);
if (surface == NULL)
    printf("Unable to generate text surface using font: %s! SDL_ttf Error: %s\n", font.c_str(), TTF_GetError());
else {
    SDL_LockSurface(surface);
    width = surface->w;
    height = surface->h;
    if (style != TTF_STYLE_NORMAL)
        TTF_SetFontStyle(tempFont, TTF_STYLE_NORMAL);
    surfaceToTexture(surface, texture);
    SDL_UnlockSurface(surface);
}
SDL_FreeSurface(surface);

But not when loading an image:

SDL_Surface* surface = IMG_Load(path.c_str());
if (surface == NULL)
    printf("Unable to load image %s! SDL_image Error: %s\n", path.c_str(), IMG_GetError());
else{
    SDL_LockSurface(surface);
    width = (w==0)?surface->w:w;
    height = (h==0)?surface->h/4:h;
    surfaceToTexture(surface, texture);
    SDL_UnlockSurface(surface);
}
SDL_FreeSurface(surface);

Both examples are extracted from a class where texture is defined. The path to the image is correct. I know it's glTexImage2D that causes the problem as I added a breakpoint at the start of surfaceToTexture and stepped through the function. Even when it doesn't work, texture and surface do have seemingly correct values/properties.

Any ideas?

Are you sure your image's pixel format is BGRA (or at least it is 4 bytes per pixel?) — keltar, Apr 02 '17 at 14:38
@keltar Good shout I hadn't checked that, I will do so when I get back home. I recall changing BGRA to RGBA which resulted in a different error, some pdb didn't load, thoughts?. — jaunt, Apr 02 '17 at 15:04
BGRA/RGBA is different order so yes it will result in deformed colour. Bytes per pixel is the same though. But if your image is RGB/BGR but you told GL it is BGRA - it is quite different thing; it will either get garbage data or crash. — keltar, Apr 02 '17 at 15:14
@keltar I have now confirmed it was the image format that was incorrect! Thank you for your help — jaunt, Apr 02 '17 at 16:33

score 6 · Accepted Answer · answered Apr 02 '17 at 14:47

6

The error you're getting means, that the procress crashed within a section of code for which the debugger could not find any debugging information (association between assembly and source code) whatsoever. This is typically the case for anything that's part of a/your program's debug build.

Now in your case what happens is, that you called glTexImage2D with parameters that "lie" to it about the memory layout of the buffer you pointed it to with the data parameter. Pointers don't carry any meaningful meta information (as far as the assembly level is concerned, they're just another integer, with special meaning). So you must make sure, that all the parameters you pass to a function along with a pointer do match up. If not, somewhere deep in the bowles of that function, or whatever it calls (or that calls, etc.) the memory might be accessed in a way that violates constraints set up by the operating system, triggering that kind of crash.

Solution to your problem: Fix your code, i.e. make sure that what you pass to OpenGL is consistent. It crashes within the OpenGL driver, but only because you lied to it.

answered Apr 02 '17 at 14:47

datenwolf

159,371
13
185
298

1

Wow thanks for the insight, but why does it work with a text surface? Surely that wouldn't work either? – jaunt Apr 02 '17 at 15:00
2

@jaunt: You're calling `glTexImage2D` with a format parameter of `GL_RGBA`, i.e. 4 channels per pixel. If the loaded font surface matches that it will work; another important part are the pixel store unpack parameters set with `glPixelStorei`, which are effectively another set of parameters that go into `glTexImage`. You really have to make sure that everything that goes into that function matches up. If it doesn't it may crash. And default parameters may by happenstance match with what is passed. Just because it works at some point doesn't mean that it works because everything is done right. – datenwolf Apr 02 '17 at 15:51
1

That makes sense, so it turns out the image pixel format wasn't actually `GL_BGRA` and was in some bizarre format. I'm surprised an error wasn't thrown by that. Thank you for your help – jaunt Apr 02 '17 at 16:36
2

@jaunt: A format mismatch toward `glTexImage` can not generate errors. `glTexImage` will just interpret the bits in the `data` buffer as if they were in the format specified no matter if that makes sense semantically or not. You can throw literally anything into it, as long as the buffer itself is compatible (which essentially boils down to "larger") with what's specified as image format and layout parameters. For what it's worth you could pass it an executable binary file. Case in point: This is my volume rasterizer's test program rendering its very own executable:. http://imgur.com/a/4qKdn – datenwolf Apr 02 '17 at 17:07

"Frame not in module" when using glTexImage2D

1 Answers1