Random crashes while loading textures

[MBee]

Hi,

I have a program that loads ~15 sprites from my hard drive, from predetermined paths.

for (std::string path : textures_to_load)
{
     sf::Texture texture;
     if (!texture.loadFromFile(path))
     {
          return 1;
     }
     //other stuff
}
 

This code crashes at some point during the 'for' loop.
Sometimes is successfully parses 4 textures, sometimes 12.
"other stuff" never causes a crash.

The program exits with code -1073741819.

Debugger crashes at GLContext.cpp, line 283. output:

Exception thrown: read access violation.
extensionString was nullptr.

I'm using Visual Studio 2022, compiled SFML from source (for VS2022, Debug, 64).

[eXpl0it3r]

Run it through VS in debug mode and the debugger should trigger and allow you to retrieve the call stack.

Not sure what you do with //other stuff, but I do hope you're saving said texture somewhere.

[MBee]

Run it through VS in debug mode and the debugger should trigger and allow you to retrieve the call stack.

>   sfml-window-d-3.dll!`anonymous namespace'::GlContextImpl::loadExtensions() Line 283   C++
    sfml-window-d-3.dll!sf::priv::GlContext::initResource() Line 365   C++
    sfml-window-d-3.dll!sf::GlResource::GlResource() Line 38   C++
    sfml-graphics-d-3.dll!sf::Texture::Texture() Line 78   C++
    Project2.exe!main(int argc, char * * argv) Line 41   C++
    [External Code]   

Not sure what you do with //other stuff, but I do hope you're saving said texture somewhere.

Hahah, of course. //other stuff's main purpose is filling map<string, sf::Texture> textures

[kojack]

What graphics hardware do you have? It seems the crash is in code that checks for opengl extensions, so that might be a driver missing or low hardware.

[MBee]

What graphics hardware do you have? It seems the crash is in code that checks for opengl extensions, so that might be a driver missing or low hardware.

1050ti, Updated its drivers just now. No difference.

I forgot to mention - I used to compile my SFML projects with gcc/MinGW, one of them included textures (https://github.com/MarvellousBee/plane-trails). They worked fine.

[eXpl0it3r]

Can you provide a complete and compileable example that reproduces the problem?

[MBee]

Can you provide a complete and compileable example that reproduces the problem?

Here's my VS project (don't worry, it's tiny)
https://drive.google.com/file/d/1wN1deYhYuigxo9vcFzrHSXVeLqnumkjB/view?usp=sharing

Note that the minimal example i provided is a bit different and cleaned up for readibility.

The equivalent of our for-each loop begins at line 30 of main.cpp.
sprites_to_load.txt contains the list of paths.

Let me know if you can make sense of it - if not, I will clean it up for you when i finish work in a few hours 

[eXpl0it3r]

Ah, you're using SFML 3, there might be some undetected issue.

Just to try something, can you move the Window to the top, i.e. before you initiate any of the textures?

Also for those who don't want to download the zip:

#include <iostream>
#include <vector>
#include <map>
#include <memory>
#include <fstream>
#include <regex>

#include <SFML/Graphics.hpp>

#include "Misc.h"
#include "Entity.h"



int main(int argc, char * argv[])
{
    std::vector<std::unique_ptr<Entity>> game_entities;
    // game_entities.push_back(std::make_unique<Outpost>(100.f, 200.f));
    // game_entities.push_back(std::make_unique<Entity>(600.f, 200.f));

    // Load all of the used sprites
    // We'll read from a file called Sample.txt
    std::ifstream inf{ "resources/sprites_to_load.txt" };
    if (!inf)
    {
        std::cerr << "[ERROR] sprites_to_load.txt could not be opened for reading.\n";
        return 1;
    }
    std::map<std::string, sf::Texture> textures;
    while (inf)
    {
       
        std::string texture_path;
        std::getline(inf, texture_path);
        std::cout << texture_path << '\n';

        // lines that are empty or start with '#' are ignored
        if (texture_path == "" || texture_path.front() == '#')
            continue;
       
        sf::Texture texture;
        if (!texture.loadFromFile(texture_path))
        {
            std::cerr << "[ERROR] Failed while loading texture: " << texture_path << '\n';
            return 1;
        }
        std::cout << texture_path << '\n';

        //std::regex regexp("\\/[a - zA - Z0 - 9] * \\.png");

        // flag type for determining the matching behavior (in this case on string objects)
        //std::smatch m;
       
        // regex_search that searches pattern regexp in the string mystr  
        //regex_search(texture_path, m, regexp);
        //textures[m.end()] = texture;
    }
    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);
   
    sf::ContextSettings settings;
    settings.antialiasingLevel = 8;
    sf::RenderWindow window(sf::VideoMode(1200, 700), "Supply chain", sf::Style::Default, settings);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
            window.close();
        }

        window.clear();
        for (auto& e : game_entities)
        {
            window.draw(*e);
        }
        window.draw(shape);

        window.display();
    }
    return 0;
}
 

[MBee]

Just to try something, can you move the Window to the top, i.e. before you initiate any of the textures?

IT WORKED

THANK YOU

BUT WHY DID THAT WORK?!
AREN'T THESE SUPPOSED TO BE TECHNICALLY INDEPENDENT?!

[eXpl0it3r]

Yeah, we'll need to have a closer look why this is causing issues.
There's some magic going on at global scope, which might have been "damaged" during the changes for SFML 3.

[Bambo_Borris]

I managed to reproduce this with your project, but I'm really not certain what's going on here. So I tried the following two approaches and it resulted in 2 different outcomes. Both scenarios I was using Visual Studio 2022 to build the project.

1). Use lib & dll files produced from the snapshot build of master. This fails to produce any crash for me, and I don't need to move the window creation to the beginning of main. I ran it around 20~ times and it always loaded all textures.

2). Build master from source locally through command-line, and another build done through Visual Studio's CMake integration. Both of these builds produced the nullptr crash on 75-80% of runs. As said in the initial post you can get the odd occasion where all textures load with no problem.

[kojack]

How recently did you grab the repo? I'm using the latest master branch (pulled today) with VS2022, debug, 64bit and I'm not seeing the crash. I even expanded the texture list file to have over 500 entries.

Although I didn't use the supplied project file directly, just the code. Maybe there's a project setting that's different...

[Bambo_Borris]

How recently did you grab the repo? I'm using the latest master branch (pulled today) with VS2022, debug, 64bit and I'm not seeing the crash. I even expanded the texture list file to have over 500 entries.

Although I didn't use the supplied project file directly, just the code. Maybe there's a project setting that's different...

I grabbed the snapshot yesterday, and made sure my local SFML was up to date with master yesterday. I did use the supplied project file. When I tried to force it to happen by loading textures in my own project I had no success.

[kojack]

Fascinating. I used Mbee's project file (but same source files, same sfml files) and I get the crash!
It must be some project file setting.
The detective work begins...

[kojack]

A little progress: I've so far tracked it down to having the Linker setting: Link Library Dependencies enabled.
With it off, works fine. With it on, crashes.

Good texture setup pass:
   glGetIntegervFunc(GL_MAJOR_VERSION, &majorVersion) is 4.
   glGetError is valid
   glGetIntegerv is valid
   glGetString is valid
   glGetStringi is valid.

Crashing texture setup pass:
   glGetIntegervFunc(GL_MAJOR_VERSION, &majorVersion) is 0.
   glGetError is valid
   glGetIntegerv is valid
   glGetString is valid
   glGetStringi is null.  (makes sense, glGetStringi is for GL 3+. But the major version is 0)