Closed andy5995 closed 7 years ago
next time you get this with git version, please do the following to get a proper stacktrace ( in linux ):
go to a console ( ctrl+alt+1 or somehting like this ) in the console get the PID ( Process ID ) of the megaglest process
cd to mk/linux
and then run:
gdb -q -n -ex "bt" -batch megaglest
this should give you a stacktrace which helps us find the problem.
What is done her is, to attach the debugger to a running process and see whats the current state of the process.
Just to put this into perspective: The graphics chipset used here is that of the Intel Core i5 650 CPU, a Clarkdale CPU, Intels first "Core i" generation (2010). http://ark.intel.com/products/43546/Intel-Core-i5-650-Processor-4M-Cache-3_20-GHz
This fifth generation Intel integrated graphics chip is the first one titled "HD Graphics" (following up to Intel GMA (Graphics Media Accelerator). https://en.wikipedia.org/wiki/Intel_HD_and_Iris_Graphics#Westmere https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Fifth_generation
The current (ninth) Core i / Intel integrated graphics generation provides (depending on the exact model) an average ten-fold floating point operations (per second) performance.
That freeze happened once more after I submitted this ticket.
Yes, I can use gdb to get a stacktrace next time that happens.
I have a question about your instructions.
I can get the PID, but what do I do with it? I see that the gdb command line and arguments you gave me don't include the PID.
On my eye on the end of titi's command you should add -p <PID>
So it should be:
PID=$(pidof megaglest | head -n1)
sudo gdb -q -n -ex bt -batch -p $PID
I just tested this and it works on Ubuntu 16.04. It will not work reliably if you run more than one copy of MegaGlest at the same time, though.
I was playing a scenario. I had loaded a previously saved game. I hit exit to end a running game (I was losing horribly). The results screen appeared. I clicked "exit" and the freeze happened. stacktrace attached.
5451.1621e56 stacktrace-5451.1621e56-01.zip
The freeze at the results exit screen may be unrelated to the freeze during the game (mentioned in post # 1. The one gives me error output at the console, and writes to ~/.megaglest/error.log
It's happened to me ~3 times in the last few days. Again, I have to kill with signal 9, 15 won't do it.
[2016-06-08 10:01:15] Runtime Error information:
======================================================
In [/home/andy/src/megaglest-3.12.0/source/glest_game/main/main.cpp::handleSIGSEGV Line: 5862] Error detected: signal 11:
Stack Trace:
megaglest:Glest::Game::ExceptionHandler::handleRuntimeError(char const*, bool)address [0x7f57594d0eb2] line: 0
megaglest:Glest::Game::handleSIGSEGV(int)address [0x7f57594d1223] line: 0
/lib/x86_64-linux-gnu/libc.so.6:()address [0x7f57547c20e0] line: 0
/usr/lib/x86_64-linux-gnu/libstdc++.so.6:()address [0x7f57550c4564] line: 0
/usr/lib/x86_64-linux-gnu/libstdc++.so.6:std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)address [0x7f57550c4841] line: 0
megaglest:std::_Rb_tree<std::string, std::pair<std::string const, Shared::Platform::Mutex*>, std::_Select1st<std::pair<std::string const, Shared::Platform::Mutex*> >, std::less<std::string>, std::allocator<std::pair<std::string const, Shared::Platform::Mutex*> > >::_M_insert_unique_(std::_Rb_tree_const_iterator<std::pair<std::string const, Shared::Platform::Mutex*> >, std::pair<std::string const, Shared::Platform::Mutex*> const&)address [0x7f57592ff07c] line: 0
megaglest:std::map<std::string, Shared::Platform::Mutex*, std::less<std::string>, std::allocator<std::pair<std::string const, Shared::Platform::Mutex*> > >::operator[](std::string const&)address [0x7f57594789f1] line: 0
megaglest:std::map<std::string, unsigned int, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > >& Shared::PlatformCommon::CacheManager::getCachedItem<std::map<std::string, unsigned int, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned int> > > >(std::string)address [0x7f5759967a67] line: 0
megaglest:Shared::PlatformCommon::getFolderTreeContentsCheckSumRecursively(std::vector<std::string, std::allocator<std::string> >, std::string, std::string const&, Shared::Util::Checksum*, bool)address [0x7f5759960700] line: 0
megaglest:Shared::PlatformCommon::FileCRCPreCacheThread::execute()address [0x7f57599706f6] line: 0
megaglest:Shared::Platform::Thread::beginExecution(void*)address [0x7f57599b90fd] line: 0
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0:()address [0x7f5758d06cfc] line: 0
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0:()address [0x7f5758d509c9] line: 0
/lib/x86_64-linux-gnu/libpthread.so.0:()address [0x7f5758a7b0a4] line: 0
/lib/x86_64-linux-gnu/libc.so.6:clone()address [0x7f575487587d] line: 0
Ah sorry for my mistake, I was using 3.12 at the time of the last few occurrences, not git.
@titiger , I'll update this ticket with the more recent information that I included with my email to you.
Using the git version, MG froze about 16 minutes into a multiplayer game. Same symptoms as mentioned above. After the freeze, In full screen, alt+enter did not work, but alt+tab did. I could kill MG with signal 9, but not 15.
I restarted MG but only got the music, the MG splash screen didn't display. I had to reboot to get MG working properly again.
In your email from yesterday, you said you think it's a driver issue, and asked for my specs. That information is near the top of this thread, and you'll see @tomreyn's comments, who also suggested a driver/hardware issue.
I can't say with 100% certainty, but this problem hasn't happened with 3.12-stable, only on the git version that followed. I'll definitely make a note right away if it happens on 3.12-stable.
Another thing I can't say with absolute certainty, is that I think it only happens when I use alt+enter at some point. Not that it happens the first time I switch back and forth, but if I NEVER use alt+enter, I don't think the freeze ever happens. Not 100% sure about that though.
Here is the same stacktrace I emailed you 2 days ago,. which I got from using the gdb
command above, after the freeze but before I killed the MG process.
[New LWP 16588]
[New LWP 16587]
[New LWP 16586]
[New LWP 16585]
[New LWP 16584]
[New LWP 16583]
[New LWP 16582]
[New LWP 16581]
[New LWP 16303]
[New LWP 16293]
[New LWP 16160]
[New LWP 16159]
[New LWP 16158]
[New LWP 16156]
[New LWP 16155]
[New LWP 16153]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fd20f243aed in poll () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
#0 0x00007fd20f243aed in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007fd20bae3252 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007fd20bae4b6f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007fd20bae4c81 in xcb_wait_for_reply () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4 0x00007fd212a5a327 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007fd2131cb7e3 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
#6 0x00007fd2131c8ee9 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
#7 0x00007fd20541ba09 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#8 0x00007fd20541bf25 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#9 0x00007fd20541094d in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#10 0x00007fd21404de84 in Glest::Game::Renderer::renderUnitsFast (this=this@entry=0x7fd2149a9a40 <Glest::Game::Renderer::getInstance()::renderer>, renderingShadows=renderingShadows@entry=false, colorPickingSelection=colorPickingSelection@entry=true) at /home/andy/src/megaglest-source/source/glest_game/graphics/renderer.cpp:7785
#11 0x00007fd2140501c2 in Glest::Game::Renderer::selectUsingColorPicking (this=this@entry=0x7fd2149a9a40 <Glest::Game::Renderer::getInstance()::renderer>, units=std::vector of length 0, capacity 0, obj=@0x7ffc9ee6ba88: 0x0, withObjectSelection=withObjectSelection@entry=true, posDown=..., posUp=...) at /home/andy/src/megaglest-source/source/glest_game/graphics/renderer.cpp:7249
#12 0x00007fd214050a46 in Glest::Game::Renderer::computeSelected (this=0x7fd2149a9a40 <Glest::Game::Renderer::getInstance()::renderer>, units=std::vector of length 0, capacity 0, obj=@0x7ffc9ee6ba88: 0x0, withObjectSelection=withObjectSelection@entry=true, posDown=..., posUp=...) at /home/andy/src/megaglest-source/source/glest_game/graphics/renderer.cpp:7035
#13 0x00007fd21407a017 in Glest::Game::Gui::computeSelected (this=this@entry=0x7fd21e070b98, doubleClick=doubleClick@entry=true, force=force@entry=true) at /home/andy/src/megaglest-source/source/glest_game/gui/gui.cpp:1141
#14 0x00007fd21407a6f8 in Glest::Game::Gui::mouseDoubleClickLeftGraphics (this=0x7fd21e070b98, x=<optimized out>, y=<optimized out>) at /home/andy/src/megaglest-source/source/glest_game/gui/gui.cpp:350
#15 0x00007fd213f956b5 in Glest::Game::Game::mouseDoubleClickLeft (this=0x7ffc9ee6b390, x=1, y=-1) at /home/andy/src/megaglest-source/source/glest_game/game/game.cpp:4358
#16 0x00007fd21408b9eb in Glest::Game::MainWindow::eventMouseDoubleClick (this=<optimized out>, x=<optimized out>, y=367, mouseButton=Shared::Platform::mbLeft) at /home/andy/src/megaglest-source/source/glest_game/main/main.cpp:991
#17 0x00007fd21459df6b in Shared::Platform::Window::handleMouseDown (this=0x7fd2157da5f0, event=...) at /home/andy/src/megaglest-source/source/shared_lib/sources/platform/sdl/window.cpp:697
#18 0x00007fd21459eadd in Shared::Platform::Window::handleEvent () at /home/andy/src/megaglest-source/source/shared_lib/sources/platform/sdl/window.cpp:235
#19 0x00007fd2140cd5fe in Glest::Game::glestMain (argc=<optimized out>, argv=<optimized out>) at /home/andy/src/megaglest-source/source/glest_game/main/main.cpp:5621
#20 0x00007fd2140d42a2 in Glest::Game::glestMainSEHWrapper (argc=1, argv=0x7ffc9ee71a38) at /home/andy/src/megaglest-source/source/glest_game/main/main.cpp:5972
#21 0x00007fd20f185b45 in __libc_start_main (main=0x7fd213ec2500 <main(int, char**)>, argc=1, argv=0x7ffc9ee71a38, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc9ee71a28) at libc-start.c:287
#22 0x00007fd213ec949a in _start ()
aurel reported a similar problem, but hasn't had the problem after using git on Debian stretch.
As for myself, after many games on MG git using Debian stretch over the last 2 weeks, the freeze has not happened to me one time.
No freeze since last post (28 days ago). afaik, no other users have reported a freeze
I have the feeling when i fixed the font issue i corrected code that may have caused this too i will close it for now and if anyone gets this issue again we can reopen or create a new bug report.
I ran a user-submitted scenario for ~1 minute (to preview it), clicked to exit it. The results screen showed, and when I clicked exit, the mouse froze, the screen froze. I had to kill MG with a signal of 9.
One difference here is that I was using Steam, but because the symptoms are so similar to what happened before, I think that I was on Steam is irrelevant.
This is very similar to what I described in my June 3rd post (above).
Regrettably, because this hasn't happened for so long, I forgot to do a stacktrace on the running process as described by @titiger and @tomreyn (above). And I had no terminal output because I was running through Steam.
I tried reproducing this 3 times afterward, using a self-build of v3.13.0 and also through Steam, but I could not reproduce it.
I was playing a game from the 'custom' menu.
Conflict map, me against 1 Mega CPU.
about 20 minutes into the game, it suddenly froze.
I was in full-screen. I couldn't switch to windowed mode. I was able to use Alt-Tab to get back to my GUI terminal window, and saw that MG didn't spit out any error info.
I ran 'top' and couldn't kill with signal 15, so I used signal 9, which worked, but then my whole desktop froze. I couldn't even use Ctrl-Alt-F2 to get to a console prompt.
I was able to ssh in from another PC and kill Xorg, so I didn't have to reboot or do a cold shut-down.
I don't know how to reproduce this. I thought it should be documented though.
I wouldn't even mention it, except that it happened twice in the last 2 weeks, and normally I don't play local games from the 'custom' or 'scenario' menu.
As I mentioned, the last time I was playing a scenario. I didn't think much of it at the time because I was using the GIT version at the time, and had 3.12.0 connected to the lobby (using a different user Data path for each instance of MG).
Both were 'self-builds' which run fine otherwise, I usually play network games. system_report.zip