Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: [Possible Bug Report] Event.Poll Crashing if Texture is initialised before  (Read 1521 times)

0 Members and 1 Guest are viewing this topic.

Hurlu

  • Newbie
  • *
  • Posts: 2
    • View Profile
Hi !

I'm currently trying out the SFML, and found out this strange undefined behaviour while trying to make a first test program.
It may or may not be a valid bug report, in which case, i'll be glad for you to enligthen me with why is this short code snippet crashing !

Here is the responsible code :

#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>

void event_conditions(sf::RenderWindow *window)
{
  sf::Event event;
  // sf::Texture text; /* Declaring it here works fine */

  while (window->pollEvent(event))
    {
      if (event.type == sf::Event::Closed ||
          (sf::Keyboard::isKeyPressed(sf::Keyboard::Escape)))
        window->close();
      window->display();
    }
}

int main ()
{
  sf::RenderWindow window(sf::VideoMode(900, 600), "Test_sfml");
  sf::Texture text; // If I remove this line, the Event.poll does not Segfault anymore.
 
  window.clear(sf::Color::Black);
  while (window.isOpen())
    {
      event_conditions(&window);
    }
  return 0;
}
 

Here is the linked valgrind output :
==25892== Invalid read of size 8
==25892==    at 0x5095DE6: sf::Window::filterEvent(sf::Event const&) (in /usr/lib/libsfml-window.so.2.4.1)
==25892==    by 0x400D94: event_conditions(sf::RenderWindow*) (main.cpp:9)
==25892==    by 0x400EDB: main (main.cpp:26)
==25892==  Address 0x19 is not stack'd, malloc'd or (recently) free'd
==25892==
==25892==
==25892== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==25892==  Access not within mapped region at address 0x19
==25892==    at 0x5095DE6: sf::Window::filterEvent(sf::Event const&) (in /usr/lib/libsfml-window.so.2.4.1)
==25892==    by 0x400D94: event_conditions(sf::RenderWindow*) (main.cpp:9)
==25892==    by 0x400EDB: main (main.cpp:26)
 

Version of SFML is 2.4.1, running on ArchLinux, recompiled multiple times with no more luck :(

Thanks for your time !

korczurekk

  • Full Member
  • ***
  • Posts: 150
    • View Profile
    • Email
Coincidence. How's that supposed to work?
while (window->pollEvent(event))
    {
      if (event.type == sf::Event::Closed ||
      (sf::Keyboard::isKeyPressed(sf::Keyboard::Escape)))
    window->close();
      window->display();
    }

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10914
    • View Profile
    • development blog
    • Email
Coincidence. How's that supposed to work?
It works fine, it's simply bad formatted and misuse of isKeyPressed and display() inside the event loop.

while (window->pollEvent(event))
{
    if (event.type == sf::Event::Closed || (sf::Keyboard::isKeyPressed(sf::Keyboard::Escape)))
    {
        window->close();
    }

    window->display();
    }

I don't see a particular issue. Since there seems to be a problem with reading an event, I feel like this is either a memory corruption or your WM does something really strange. What Window Manager (WM) do you use?
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Hurlu

  • Newbie
  • *
  • Posts: 2
    • View Profile
Checking back after a good night of sleep, tried back again on xfce as I did before testing again this morning and tried back on xfce and i3, still crashing .

I guess I'll just keep my sf::Event object instantiated before my first sf::Event, as everything seems to work fine in this case .
I'll check back again if I find something new !

Midnight edit :

After some late night tries, and testing downgrader to 2.3.2, sounds like the problem comes from my OPENGL / LibMesa install, as it works flawlessly on other computers.
Will update if I find the precise problem / fix.
« Last Edit: January 17, 2017, 12:13:32 am by Hurlu »

 

anything