Messages

1

Graphics / Re: Invalid pointer error when setting fonts

« on: April 01, 2017, 07:00:57 pm »

Hmm. Deleted all links to external headers and it still compiled. It gets them from somewhere else and I have no idea where from. Only deleting links to internal headers or sfml object files gives me errors. Maybe a quirk of the IDE, but the global include section is also empty.

2

Graphics / Re: Invalid pointer error when setting fonts

« on: April 01, 2017, 12:23:26 pm »

Reduced the code to the following:

                    sf::Font f2;
                    if (!f2.loadFromFile("DejaVuSans.ttf"))
                        {
                            condition=false;
                            owner->setdbgstr("error");
                        }
                    else
                        {
                            owner->setdbgstr("no error");
                            sf::Text tx;
                            tx.setFont(f2);
                            tx.setString("i run");
                            draw(tx);
                        }
 

Still got the crashes. Then I tried to get individual glyphs from the texture, but at this line:

sf::Glyph glyph = f2.getGlyph(codePoint, characterSize, bold);

I got the following error:

undefined reference to `sf::Font::getGlyph(unsigned int, unsigned int, bool, float) const

The function seems to not be implemented.

3

Graphics / Invalid pointer error when setting fonts

« on: March 30, 2017, 11:24:14 pm »

I use the following system to manage drawing text:

// header
        std::map<std::string, sf::Font> fonts;
        std::map<std::string, bool> fontsdbg;

//where text drawing takes place
                fontData * fd = (fontData *)drawnShape->getPropertyByName("font");
                if (fd==nullptr)
                    break;
                if (fd->getData().size()<5)
                    break;

                std::string fontpath = fd->getData();

                if (fonts.find(fontpath)==fonts.end())
                    {
                        fonts[fontpath] = sf::Font();
                        fontsdbg[fontpath]=fonts[fontpath].loadFromFile(fontpath);
                        debug="success! "+fontpath;
                    }
                else if(fontsdbg[fontpath])
                    {
                        debug=std::to_string(fonts.size())+ ">"+fontpath+"< is loaded properly";
                        sf::Text txt; //break; // it doesn't crash if this break statement is uncommented
                        txt.setFont(fonts[fontpath]); //it crashes when it reaches this command.
....
 

Here's the error I get:

*** Error in `....`: double free or corruption (out): 0x08c77200 ***
Aborted

Process returned 134 (0x86)

Other times I get this error:

*** Error in `....`:  free(): invalid pointer
Aborted

Process returned 134 (0x86)

Note that analogous code works just fine for setting textures onto sprites and drawing them. Therefore I suspect it might have more to do with C++ than SFML, but I'm asking here just in case.

4

General / Re: WxWidgets/SFML program crashes with an X window system error (BadAccess)

« on: March 23, 2017, 04:53:58 pm »

I get this output on the console when opening the SFML window under version 2.1., maybe has something to do with the other issue:

libGL error: dlopen /usr/lib/i386-linux-gnu/dri/i915_dri.so failed (/usr/lib/i386-linux-gnu/dri/i915_dri.so: undefined symbol: _glapi_tls_Dispatch)
libGL error: unable to load driver: i915_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i915
libGL error: dlopen /usr/lib/i386-linux-gnu/dri/swrast_dri.so failed (/usr/lib/i386-linux-gnu/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

However, it doesn't crash or anything. Infact, it behaves normally just as expected and I was unaware of this until I made the console appear for when dealing with the crash issue.
A quick search on the internet shows that this is due to custom build opengl drivers or mesa, but I didn't custom build them. The search continues.

5

General / Re: WxWidgets/SFML program crashes with an X window system error (BadAccess)

« on: March 15, 2017, 10:37:42 pm »

Spent some time on studying the five SFML functions in the back trace:

sf::priv::getAtom(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool)
sf::priv::WindowImplX11::setProtocols()
sf::priv::WindowImplX11::WindowImplX11(unsigned long)
sf::priv::WindowImpl::create(unsigned long)
sf::Window::create(unsigned long, sf::ContextSettings const&)

Compared version 2.1, which works for certain, and version 2.3.2, which gives the error for certain. Both sf::priv::WindowImpl::create(unsigned long) and sf::Window::create(unsigned long, sf::ContextSettings const&) are the same in both versions - there are no changes there.
There's some differences in sf::priv::WindowImplX11::WindowImplX11(unsigned long), although only one seems relevant - the newer one makes a call to sf::priv::WindowImplX11::setProtocols(), which exists only in 2.3.2, but not in 2.1.
The first thing setProtocols does, on its side, is xcb_atom_t wmProtocols = getAtom("WM_PROTOCOLS");, and according to the backtrace, the non-SFML function, in which the error occurs is exactly there. However, I couldn't find getAtom in the 2.3.2 source. I wonder what it does. Is it essential?


It'd be a good idea to read on the system functions further above in the backtrace:

#0  0x00007ffff4ec7770 in gdk_x_error (display=0x75d000, error=0x7fffffffdec0) at gdkmain-x11.c:458
#1  0x00007fffeff476fd in _XError (dpy=dpy@entry=0x75d000, rep=rep@entry=0x9c3db0) at XlibInt.c:1434
#2  0x00007fffeff44627 in handle_error (dpy=0x75d000, err=0x9c3db0, in_XReply=<optimized out>) at xcb_io.c:199
#3  0x00007fffeff446e5 in handle_response (dpy=0x75d000, response=0x9c3db0, in_XReply=<optimized out>)
    at xcb_io.c:311
#4  0x00007fffeff455f8 in _XReply (dpy=dpy@entry=0x75d000, rep=rep@entry=0x7fffffffe0a0, extra=extra@entry=0, discard=discard@entry=1) at xcb_io.c:621
#5  0x00007fffeff302ff in XInternAtom (dpy=dpy@entry=0x75d000, name=0x7fffffffe1c0 "WM_PROTOCOLS", onlyIfExists=onlyIfExists@entry=0) at IntAtom.c:181

gdk_x_error, _XError and handle_error seem to be only for error handling and reporting. This leaves us with only handle_response, _XReply and XInternAtom to investigate.
I don't really know how to interpret the data in the brackets, but looking at name=0x7fffffffe1c0 "WM_PROTOCOLS", onlyIfExists=onlyIfExists@entry=0, it seems like WM_PROTOCOLS is some entry that is missing. This further feeds my gut feelings that it's about gtk2 incompability and need to upgrade to gtk3. The latter, however, had proven troublesome in the past.

Searches like "WM_PROTOCOLS X window system error" don't turn up anything immediately seeming relevant.

Here's what Linux man page has to say about XInternAtom:

Atom XInternAtom(Display *display, char *atom_name, Bool only_if_exists);

atom_name
Specifies the name associated with the atom you want returned.

display
Specifies the connection to the X server.

only_if_exists
Specifies a Boolean value that indicates whether the atom must be created.

The XInternAtom function returns the atom identifier associated with the specified atom_name string. If only_if_exists is False, the atom is created if it does not exist. Therefore, XInternAtom can return None. If the atom name is not in the Host Portable Character Encoding, the result is implementation-dependent. Uppercase and lowercase matter; the strings ''thing'', ''Thing'', and ''thinG'' all designate different atoms. The atom will remain defined even after the client's connection closes. It will become undefined only when the last connection to the X server closes.

XInternAtom can generate BadAlloc and BadValue errors.

From what I can understand, a BadValue error is returned only when only_if_exists is true and the atom indentifier with such atom_name doesn't exist. But only_if_exists in this case is false, so this leaves BadAlloc as the only option. This is the trace to begin with next time. That, and reading the links I've posted above.

6

General / Re: WxWidgets/SFML program crashes with an X window system error (BadAccess)

« on: March 15, 2017, 06:10:42 pm »

I don't know why I was so blinded out, i got the exact same problem. My code works up until SFML 2.2, but from 2.3 it causes this error (tested for 2.3.2, but pretty sure it starts from 2.3). Might be worth checking the code difference between these two versions.

Here are some similar cases and relevant pages I gathered:
http://stackoverflow.com/questions/34384253/with-a-simple-code-the-sfml-window-crashes-all-the-time
https://bugzilla.mozilla.org/show_bug.cgi?id=1271100
https://github.com/SFML/SFML/issues/936
http://stackoverflow.com/questions/34844966/sfml-sfrenderwindowcreatewindow-crashes-program
https://github.com/atom/atom/issues/6496
https://www.sfml-dev.org/faq.php (has some entries on errors)

It will take a while going through all of this. I got the feeling it's a compatibility issue, not directly a linking issue between SFML and WxW. Also it'd be worth checking if other already compiled SFML 2.4.2 programs run fine.

7

General / Re: Is there anything I need to know before migrating my project to SFML 2.4.2?

« on: March 13, 2017, 03:48:12 pm »

Did you do it differently (i.e. different than writing directly the command line in a terminal)?

Yes, I assumed you meant to write it in that file again. Removed any modifications and relogged so that the behaviour is now same as before.

When now I execute that from the command line in the folder of the executable, I still get the same behaviour as if I've written it in the file - no reaction when clicking the button in Release (the button is meant to open the SFML window), and the following error message in Debug:

(click to show/hide)

The program 'speccer' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
  (Details: serial 52 error_code 10 request_code 2 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

8

General / Re: Is there anything I need to know before migrating my project to SFML 2.4.2?

« on: March 13, 2017, 02:12:39 pm »

Are you sure I meant to write that? As soon as I logged back in, I got an error message how that isn't a valid path (yes, I did change 'your_executable' to the name of my executable) and how the environment variables aren't configured properly and I should fix that as soon as feasible. Tried to copy the message, but for some reason the copy buffer was emptied after that.

When I recompiled the program and tried to run the debug version from the console, I got this message:

The program 'speccer' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
  (Details: serial 52 error_code 10 request_code 2 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Or should I have written the absolute path to the executable instead of just the executable name?

9

General / Re: Is there anything I need to know before migrating my project to SFML 2.4.2?

« on: March 13, 2017, 01:26:07 pm »

I first added export PATH=$PATH:/usr/local/lib to ~/.profile, logged out and then in, made some changes to the code, compiled it and ran it, only to get the exact same behaviour. Repeated the same with export PATH=$PATH:/usr/local to no avail.

I thought maybe moving the files to where they used to be installed by default would help, but then I recalled I already tried that with no success.

10

General / Re: WxWidgets/SFML program crashes with an X window system error (BadAccess)

« on: March 12, 2017, 10:33:43 pm »

Here's my experience with SFML + WxWidgets: http://en.sfml-dev.org/forums/index.php?topic=21373.0 It runs on Ubuntu 14.04 with gtk2, and should work on Windows, too. Do make sure to read my second post in there. 

11

General / Re: Is there anything I need to know before migrating my project to SFML 2.4.2?

« on: March 12, 2017, 10:22:45 pm »

Deleted everything, downloaded 2.4.2 anew, compiled and installed it. Search directories → Compiler points to /usr/local/include/SFML, which contains the .hpp files and Search directories → Linker points to /usr/local/lib, which contains the .so files.

Same story. When I recompile everything and run it, the first window opens just fine. When I click the button to open the SFML subwindow, everything closes on the spot. Both in debug and release.
When I run the release in the console, the button for the SFML subwindow doesn't do anything, it's as if it doesn't contain any code. Nothing happens.
When I try to run the debug version from the console, I get this without anything opening:

error while loading shared libraries: libsfml-graphics.so.2.4: cannot open shared object file: No such file or directory

even though libsfml-graphics.so.2.4 is in /usr/local/lib.

12

General / Re: Undefined references when using manually downloaded SFML version

« on: March 12, 2017, 10:14:29 pm »

You're using Linux, why won't you simply recompile SFML and install it

That's what I was doing before that, with no success.

Btw if you're using Ubuntu 16.04 or newer you can install SFML 2.4.1 from .deb prepared by me, it's packaged with QSFML releases.

On 14.04.

13

General / Re: Undefined references when using manually downloaded SFML version

« on: March 11, 2017, 01:42:01 pm »

I tried to, but hit a brickwall. I'm trying to install 2.1 from another location with the idea that it'll help me infer why 2.4.2 doesn't work for me.

Before 2.1 I tried installing 2.3.2, but it behaves the same way as 2.4.2.

14

General / Undefined references when using manually downloaded SFML version

« on: March 11, 2017, 01:17:47 pm »

When I install sfml 2.1 from the repo (on ubuntu), it works just fine. But when I download the same version from the download page, it throws out these errors:

(click to show/hide)

||=== Build: Debug in speccer (compiler: GNU GCC Compiler) ===|
||warning: libGLEW.so.1.7, needed by /home/foo/bar/sfml21/lib/libsfml-graphics.so, not found (try using -rpath or -rpath-link)|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewGetHandleARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewActiveTextureARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__GLEW_ARB_texture_non_power_of_two'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewUniform1iARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewGetObjectParameterivARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewUniform4fARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewFramebufferTexture2DEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewCreateProgramObjectARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `glewGetErrorString'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewGetInfoLogARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewShaderSourceARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewFramebufferRenderbufferEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__GLEW_ARB_shading_language_100'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewCheckFramebufferStatusEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewCreateShaderObjectARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewRenderbufferStorageEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewBlendFuncSeparateEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewDeleteObjectARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__GLEW_ARB_shader_objects'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewGenRenderbuffersEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewAttachObjectARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewBindRenderbufferEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewDeleteFramebuffersEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__GLEW_ARB_vertex_shader'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewGenFramebuffersEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewGetUniformLocationARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewDeleteRenderbuffersEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewUseProgramObjectARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewBindFramebufferEXT'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__GLEW_ARB_fragment_shader'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewCompileShaderARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__GLEW_EXT_blend_func_separate'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewUniform1fARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__GLEW_EXT_framebuffer_object'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewUniform3fARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewLinkProgramARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `glewInit'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewUniformMatrix4fvARB'|
/home/foo/bar/sfml21/lib/libsfml-graphics.so||undefined reference to `__glewUniform2fARB'|
||=== Build failed: 39 error(s), 1 warning(s) (0 minute(s), 2 second(s)) ===|

I copied all the glew files into the lib folder, but the problem persists (I found out I don't have libGLEW.so.1.7 on my system btw). How to fix this problem?

15

General / Re: Is there anything I need to know before migrating my project to SFML 2.4.2?

« on: March 09, 2017, 10:09:22 pm »

Actually, are there any requierments for SFML 2.4.2? I certainly haven't seen any in the main page, but IIRC it uses OpenGL under the hood and my system only supports 1.4 or 2.1, can't remember exactly which.