I'm getting a inconsistant error

[justsomeguy]

Hello

I'm sorry about bothering you guys, but I keep getting an error that is intermittent. About half of the time it compiles and runs with no problem, the other half it core dumps with the following error.
 [ You are not allowed to view this attachment ]  

Code: QB64: [Select]

1. [xcb] Unknown sequence number while processing reply
2. [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
3. [xcb] Aborting, sorry about that.
4. RougeLike_1_1: ../../src/xcb_io.c:639: _XReply: Assertion `!xcb_xlib_threads_sequence_lost' failed.
5. Aborted (core dumped)

I'm currently using the 2.1 Dev build. I'm not using multi-threading my code.
I am running Linux Mint 19.1 (Yes, It is up to date). My computer specs should be more than enough. I have tried it on my Windows machine and it seems to work fine with crashing.

I have enclosed the project, so you can test it on your end.  [ You are not allowed to view this attachment ]  

[George McGinn]

It ran fine for me.

I compiled it on Linux (Ubuntu 20.04) and the screen shot shows that I get the main menu.

What is your system?

[justsomeguy]

 [ You are not allowed to view this attachment ]  

Yea, Like I said it will compile and run fine about half of the time.

[SMcNeill]

Intermittent issues like this are often caused by race conditions with multi-threaded programs.

In Windows, we see this a lot with use of _WINDOWHANDLE at the start of a program.  _WindowHandle returns a result, before windows has even finished fully registering and creating the handle, and then all sorts of bad stuff happens when we try and use that invalid handle.  Usually, in these cases, the fix is as simple as adding a _DELAY 0.2 after the SCREEN statement and before the call to _WindowHandle to make certain that race condition has time to complete before it glitches out.

For Linux, I don't have a clue where and how it can run into the same situation.  My coding anymore is basically just 100% Windows based.

My suggestion would be to try adding a few _Delay statements into your code at various points (especially at initialization) and see if the issue goes away.  If so, then you can narrow down on the *exact* line that's causing the glitch, and just add a single _Delay before it and resolve the issue.

Best of luck on finding/fixing the problem.  Nothing is worse to debug that a glitch that only appears intermittently!

[George McGinn]

I tried to run your code on the PI with a 32bit OS using GDB, as I cannot repeat your error (I've run it 10 times on my system, which is an x86_64 64Bit QB64) and on the PI it gets a "SIGBUS - Bus error" which I'm assuming has to do with how freeglut works on the PI (probably related to the issue I am having with my other post on installing qb64 on the PI - same error).

Which makes me wonder if this is also a sometimes problem on an x86 architecture?

You should recompile your program with the -g compiler option and run it in GDB to see if you can trap the specific error you are getting.

To do this, go into "makeline_lnx.txt" in the "internal/c" subfolder of qb64, and add the -g after "gcc". Recompile then in the terminal, run "gdb RougeLike_1_1" to load it.

Since I am unable to reproduce it on my system, that is the best I can do.  (While typing this in I ran your code 5 more times and it worked every time).

[George McGinn]

I will look into this for the issue I am having running on a PI - it is the same issue - the error I am getting "Bus error" happens when the program starts thread 2! Thanks.

Intermittent issues like this are often caused by race conditions with multi-threaded programs.

In Windows, we see this a lot with use of _WINDOWHANDLE at the start of a program.  _WindowHandle returns a result, before windows has even finished fully registering and creating the handle, and then all sorts of bad stuff happens when we try and use that invalid handle.  Usually, in these cases, the fix is as simple as adding a _DELAY 0.2 after the SCREEN statement and before the call to _WindowHandle to make certain that race condition has time to complete before it glitches out.

For Linux, I don't have a clue where and how it can run into the same situation.  My coding anymore is basically just 100% Windows based.

My suggestion would be to try adding a few _Delay statements into your code at various points (especially at initialization) and see if the issue goes away.  If so, then you can narrow down on the *exact* line that's causing the glitch, and just add a single _Delay before it and resolve the issue.

Best of luck on finding/fixing the problem.  Nothing is worse to debug that a glitch that only appears intermittently!

[justsomeguy]

I ran it in a debugger and I got the same error message. So I did a little bit of googling and came across this https://github.com/SFML/SFML/issues/1696 It pertains to SFML -Simple and Fast Multimedia Library, which I can only assume that QB64 is using. The Reply to the question was:

When using threads on Linux you need to be calling XInitThreads as the error messages suggests.
Keep in mind that you should not be using globally initialized SFML resources.
And when you do multi-threading, you have to properly synchronize the shared resources (the sprite and boolean in your case).

I did not plan on digging into the inner workings of QB64, but It seems the issue is coming from that side.

[justsomeguy]

It appears @SMcNeill suggestion was correct.

My suggestion would be to try adding a few _Delay statements into your code at various points (especially at initialization) and see if the issue goes away.  If so, then you can narrow down on the *exact* line that's causing the glitch, and just add a single _Delay before it and resolve the issue.

I put a delay before initializing the screen and I was able to restart multiple times without issue.

Thanks for your help guys!