window.draw() hangs in GDB

[jalf86]

Well here's what I have.

Fedora 25 (uses wayland emulating X)
build from source (debug and release), SFML 2.4.2 (using CMake, Code::Blocks, and gcc version 6.3 ) (afraid to update gcc)
using gdb version 7.12 (the latest update)
have updated Intel graphics driver (i915)
compiled test file using the C++14 standard
updated the lib path
applied the Git patch (the one that makes changes to CMake)

I'm compiling and running one of the tutorial codes found in the Learning Section of this web site.  I compile with 0 errors 0 warnings. I can run both debug and release versions with no problems.

However, when trying to use GDB (on the debug version), the program hangs at window.draw().  I'm not sure if it actually hangs or if I haven't waited long enough for GDB to come out of window.draw().  The longest I've waited was probably 3 minutes.  I've stepped into the function and I seem to go into an endless loop of the same called functions that make up window.draw().

I was getting the segmentation fault until I did the Git patch. I don't know what else to do. I checked the web, the answer was to update gdb or my graphics driver. both are up to date.  I want to be able to use GDB.  I haven't tried another debugger yet.

The following is the test code I used.

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);

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

        window.clear();
        window.draw(shape);
        window.display();
    }

    return 0;
}

[eXpl0it3r]

It hangs there how exactly?
Like when you step through the application or when you just call run or ...?

[jalf86]

if use the run command in GDB, it runs fine.  If I put a break point at anywhere except on the line with window.draw().  The GDB command continue functions as I would expect.  If the break point is at window.draw(), the continue command instigates  the OS into popping a message saying "SFML works!" is not responding.

If I input the next command on window.draw().  The program "seemingly" hangs.  Program execution seems to halt.  However, nothing on the screen is locked.  Using the Code Blocks Debug menu, I can stop the debugger and even call up a watch window, stack window, and memory dump window.  However, these windows are blank.

If I am using just plain old GDB. Nothing execpt Cntrl^Z does anything. After Cntrl^Z, the executable has been stopped and I can input any GDB command.

If i input the step command on window.draw().  I step into it seemly well, but I never get out.  The attachment is the debugger output of me stepping.  basic_string.h seems to be the favorite file that keeps getting cycled back to.

Let me know if I can give you more info.

[eXpl0it3r]

Looking at your output, you're never getting past the first line where the window is created.
This doesn't mean that GDB "hangs" but it just means that all these operations go very deep. The STL is not a fun place to debug in. If you step into each and every operation, it can take very, very long time till you get back to your own code.

If i input the step command on window.draw().  I step into it seemly well, but I never get out.  The attachment is the debugger output of me stepping.  basic_string.h seems to be the favorite file that keeps getting cycled back to.

There's no string handling happening when calling draw on a shape, so it's impossible that you end up in basic_string.h. Instead, I think it's more likely that you're misinterpreting the results and probably how the GDB commands work.

[jalf86]

I thought it was weird too.  As stated before, I am a newb.

The output I sent you started from window.draw().  The GDB overran the text clipboard.

When I first started debugging.  I was using a GUI front end (Code Blocks) to GDB.  When I used the step-into button, I was repeatedly (visually) sent to the following file.  /usr/include/c++/6.3.1/bits/basic_string.h.  So I figured I should run GDB by itself and step through window.draw().  After stepping through the SFML files, the following output (or similar output) pops up, repeatedly.

After stepping through the SFML files, folllowing (or similar) happens:
[debug]> step
[debug]std::__cxx11::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::_M_local_data (this=0x7fffffffe480) at /usr/include/c++/6.3.1/bits/basic_string.h:142
[debug]/usr/include/c++/6.3.1/bits/basic_string.h:142:4747:beg:0x7ffff76f6404
[debug]>>>>>>cb_gdb:

The text file I sent is the output GDB gives me as I repeatedly input the step command.

Was just thinking.  I probably don't have debug versions of the standard c++ library/STL.  Judging from your last reply, do you think this is a GDB error or my own?

[jalf86]

Sorry send post button too soon.  In another post that you replied to me.  You mentioned Fedora 25 having SFML.  I checked and was overjoyed for a while.  So I reformatted my hard drive and re-installed Fedora 25 and installed SFML.  However, the repository only have release versions of SFML.  No debug versions.  I did try GDB on it, but it would continually cause "blah, blah, blah is not responding ... (Force quit or Wait)".  So I'm going to take a break for a bit.  I'll come back later, unless you think I should go to a Code Blocks, or GDB, or gcc type forum.