Rare xcb_io assertion error while retreating

[kamiccolo]

Once couple of times I get the following while fighting the same darn ghost in the graveyard and trying to retreat:

[New Thread 0x7fffefadd700 (LWP 3174)]
02:45:18 AM: [ERROR]    SetLangEnvPath:  translation not found: en.po
[xcb] Unknown sequence number while appending request
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
fheroes2: ../../src/xcb_io.c:161: append_pending_request: Assertion `!xcb_xlib_unknown_seq_number' failed.

Thread 1 "fheroes2" received signal SIGABRT, Aborted.
0x00007ffff666c428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff666c428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff666e02a in __GI_abort () at abort.c:89
#2  0x00007ffff6664bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7ffff5a5397f "!xcb_xlib_unknown_seq_number", 
    file=file@entry=0x7ffff5a5392b "../../src/xcb_io.c", line=line@entry=161, function=function@entry=0x7ffff5a53dc0 "append_pending_request") at assert.c:92
#3  0x00007ffff6664c82 in __GI___assert_fail (assertion=0x7ffff5a5397f "!xcb_xlib_unknown_seq_number", file=0x7ffff5a5392b "../../src/xcb_io.c", line=161, 
    function=0x7ffff5a53dc0 "append_pending_request") at assert.c:101
#4  0x00007ffff59e0eef in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007ffff59e19c8 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007ffff59dd48d in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007ffff7b6ddca in SDL_UpdateRect () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#8  0x00007ffff7b6dfe6 in SDL_Flip () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#9  0x000000000040d7e3 in Display::Flip (this=0x9761c0 <Display::Get()::inside>) at /home/zilvinas/Compile/fheroes2enh/src/engine/display.cpp:62
#10 0x00000000004888d1 in Battle::Arena::Arena (this=0x7fffffffd4b0, a1=..., a2=..., index=1699, local=true)
    at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/battle/battle_arena.cpp:314
#11 0x00000000004ced3c in Battle::Loader (army1=..., army2=..., mapsindex=1699) at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/battle/battle_main.cpp:76
#12 0x00000000005a7a03 in BattleHeroWithMonster (hero=..., army=..., dst_index=1699) at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/heroes/heroes_action.cpp:778
#13 0x00000000005b3dc8 in ActionToCaptureObject (hero=..., obj=192, dst_index=1699) at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/heroes/heroes_action.cpp:2334
#14 0x00000000005b34b9 in ActionToAbandoneMine (hero=..., obj=192, dst_index=1699) at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/heroes/heroes_action.cpp:2249
#15 0x00000000005a7642 in Heroes::Action (this=0xd6cb50, dst_index=1699) at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/heroes/heroes_action.cpp:652
#16 0x00000000005ce4b4 in Heroes::MoveStep (hero=..., index_from=1698, index_to=1699, newpos=true)
    at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/heroes/heroes_move.cpp:489
#17 0x00000000005ce747 in Heroes::MoveStep (this=0xd6cb50, fast=false) at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/heroes/heroes_move.cpp:533
#18 0x00000000005cf982 in Heroes::Move (this=0xd6cb50, fast=false) at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/heroes/heroes_move.cpp:849
#19 0x000000000057782b in Interface::Basic::HumanTurn (this=0x976ac0 <Interface::Basic::Get()::basic>, isload=true)
    at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/game/game_startgame.cpp:912
#20 0x000000000057643e in Interface::Basic::StartGame (this=0x976ac0 <Interface::Basic::Get()::basic>)
    at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/game/game_startgame.cpp:585
#21 0x00000000005739dc in Game::StartGame () at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/game/game_startgame.cpp:72
#22 0x00000000005594ae in main (argc=1, argv=0x7fffffffe128) at /home/zilvinas/Compile/fheroes2enh/src/fheroes2/game/fheroes2.cpp:307

[callykitten99]

I have the same 'append_pending_request' assertion problem as described above. Still trying to work out where my problem is coming from XD I'll get back to you as soon as I have any further insights.

I must ask - when you say 'retreating' do you mean when the program attempts to exit? This is also where I get the problem. Do you use Code::Blocks?

[callykitten99]

Hi.

I traced my problem to a buggy initialiser - I recently moved my program initialisation to a class I call 'Engine' which I place in global scope (my modules can extern ref them). My goal was that the EventHandler (another class I made) could reference the X11 'Display *' and 'Window' members of the Video class (all inside the Engine) as a 'friend', instead of passing those two by value (or reference) to the EventHandler initialiser. I deem it unnecessary to copy variables I can reference globally (overhead is unarguably reduced).

My problem was - my old code had the EventHandler initialiser (called init()) take parameters 'Display *' and 'Window' passed in (by value copy) with the intention that the class destructor would call 'init' again, passing NULL in both parameters, in order for init() to do the appropriate clean-up.

My developing (and solved problem) therefore became - my init() function was being called sneakily from the destructor I forgot about, but no longer cleaned up on behalf of the destructor. Worse, it actually tried to register another atom that already existed (WM_DELETE_WINDOW).

I haven't looked at your code yet - try looking for any part of your code that uses functions XInternAtom() or XSetWMProtocols() and try looking for odd circumstances or behaviour surrounding when they're called (are you calling them when you're destructing, like I did? That's probably a no-no).

I hope this helps.

[kamiccolo]

Blocks

I meant "retreating" from the game battle.