Crash [build 2015-08-14.b22b7db]

Problems and solutions for installing or running FreeOrion, including discussion of bugs if needed before posting a bug report on GitHub. For problems building from source, post in Compile.

Moderator: Oberlus

Message
Author
AndrewW
Juggernaut
Posts: 791
Joined: Mon Feb 04, 2013 10:15 pm

Crash [build 2015-08-14.b22b7db]

#1 Post by AndrewW »

Crashes with a segmentation fault.

Repeatable:

Load save game. (Linux)
Click on Odin (black hole to the lower right).
Click on Production
Add 4 Battleship I's to the que. (probably variable but that works).
Change each one to build 5, before you get to all of them crash. (I did this with just clicking and not using the scroll wheel).

https://drive.google.com/file/d/0Bxa-B6 ... sp=sharing

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Crash [build 2015-08-14.b22b7db]

#2 Post by Dilvish »

Hmm, ok I can confirm that is repeatable for me as well; crashed as I adjusted the second one. I'll look into it.

Thanks much! A repeatable crash like this helps tremendously for tracking down bugs.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

AndrewW
Juggernaut
Posts: 791
Joined: Mon Feb 04, 2013 10:15 pm

Re: Crash [build 2015-08-14.b22b7db]

#3 Post by AndrewW »

Dilvish wrote:Hmm, ok I can confirm that is repeatable for me as well; crashed as I adjusted the second one. I'll look into it.

Thanks much! A repeatable crash like this helps tremendously for tracking down bugs.
Usually the second one for me as well, though have had it be the third one. Doesn't seem to matter which one I start on.

Yup, if I have a crash I always try and repeat it.

Glad it worked for you as well, never know if it's just my system doing it.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Crash [build 2015-08-14.b22b7db]

#4 Post by Dilvish »

Just to note what I've figured out so far-- adding some extra logging statements has revealed that the crash is occurring during the

Code: Select all

queue_lb->Clear(); 
call within ProductionWnd::UpdateQueue().

Additionally, running with valgrind / memcheck revealed that when the blocksize dropdown list is changed there is an invalid write caused by the call to ModalListPicker::LBSelChangedSlot()

Code: Select all

==21104== Invalid write of size 1
==21104==    at 0x5C2B852: ModalListPicker::LBSelChangedSlot(std::set<std::_List_iterator<GG::ListBox::Row*>, GG::ListBox::RowPtrIteratorLess, std::allocator<std::_List_iterator<GG::ListBox::Row*> > > const&) (in /home/FO/programs/freeorion_git1/freeorion/cmake_build/kdev/libGiGi.so)
==21104==    by 0x5CA326A: boost::signals2::detail::signal1_impl<void, std::set<std::_List_iterator<GG::ListBox::Row*>, GG::ListBox::RowPtrIteratorLess, std::allocator<std::_List_iterator<GG::ListBox::Row*> > > const&, boost::signals2::optional_last_value<void>, int, std::less<int>, boost::function<void (std::set<std::_List_iterator<GG::ListBox::Row*>, GG::ListBox::RowPtrIteratorLess, std::allocator<std::_List_iterator<GG::ListBox::Row*> > > const&)>, boost::function<void (boost::signals2::connection const&, std::set<std::_List_iterator<GG::ListBox::Row*>, GG::ListBox::RowPtrIteratorLess, std::allocator<std::_List_iterator<GG::ListBox::Row*> > > const&)>, boost::signals2::mutex>::operator()(std::set<std::_List_iterator<GG::ListBox::Row*>, GG::ListBox::RowPtrIteratorLess, std::allocator<std::_List_iterator<GG::ListBox::Row*> > > const&) (in /home/FO/programs/freeorion_git1/freeorion/cmake_build/kdev/libGiGi.so)
This method is also connected to the SelChangedSignal from the dropdowns. It looks to me like this connection *should* be getting fully processed *before* the ProductionWnd connection that eventually leads to ProductionWnd::UpdateQueue() but if somehow they were proceeding in parallel I could see trouble ensuing, or perhaps it could be cause by our listbox-within-a-listbox stacked structure we have here, and the 'inner' listboxes are perhaps not getting cleanup up properly when the 'outer' listbox is cleared.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Crash [build 2015-08-14.b22b7db]

#5 Post by Geoff the Medio »

Dilvish wrote:...if somehow they were proceeding in parallel...
I don't think there is any threading occurring relevant to this situation. It's possible a network event (turn update) could cause the UI to get updated in the middle of the user doing something on another thread, but I don't think that's relevant here.
...it could be cause by our listbox-within-a-listbox stacked structure we have here, and the 'inner' listboxes are perhaps not getting cleanup up properly when the 'outer' listbox is cleared.
Not sure what you mean by listbox-within-a-listbox. A DropDownList is not a ListBox, though it does contain one...

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Crash [build 2015-08-14.b22b7db]

#6 Post by Dilvish »

Geoff the Medio wrote:
...it could be cause by our listbox-within-a-listbox stacked structure we have here, and the 'inner' listboxes are perhaps not getting cleanup up properly when the 'outer' listbox is cleared.
Not sure what you mean by listbox-within-a-listbox. A DropDownList is not a ListBox, though it does contain one...
** I'm editing this message because it now crosses my mind that perhaps you failed to connect the first part of my post to the second part; so you might have simply been genuinely confused, and I should give you the benefit of that doubt. I am a bit harried at my end of things this day, so please excuse the momentary crankiness. **

I mention the outer listbox (the main production queue listbox) because that's the thing being cleared when the crash happens. I mention the inner listbox (the one used by the the blocksize dropdownlist) because although I can't make total sense of that write error, it seems to me to perhaps indicate that the inner ListBox is sending a SelChangedSignal (still connected to it's enclosing ModalListPicker::LBSelChangedSlot method) at a point when some involved object has already been freed.

And let me emphasize that's just my current best guess. I haven't chased down enough detail to make a clear assertion of what is happening. But I thought I had enough information to make note of this in case anyone else is looking into this also (or just for myself if I have to come back to this later)-- I'm not sure I'll be able to take the time to chase it down all the way right now.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Crash [build 2015-08-14.b22b7db]

#7 Post by Geoff the Medio »

Dilvish wrote:
Geoff the Medio wrote:Not sure what you mean by listbox-within-a-listbox. A DropDownList is not a ListBox, though it does contain one...
I mention the outer listbox (the main production queue listbox)...
Ah, I didn't think of / realize you were also talking about the production queue listbox... was just considering the droplist control itself, as that seemed to be causing the crashes earlier for me without need for any substantial interaction with containing Wnds.

AndrewW
Juggernaut
Posts: 791
Joined: Mon Feb 04, 2013 10:15 pm

Re: Crash [build 2015-08-14.b22b7db]

#8 Post by AndrewW »

Dunno if it'll help but found another way to crash the same saved game.

Code: Select all

*** Error in `./freeorion': free(): invalid next size (fast): 0x0000000009098a30 ***
Though sometimes it'll be the Segmentation fault.

Load saved game.
Click on Odin.
Add one Battleship I to the que.
Change to 5.
Click on an unoccupied planet.

Found this on a new game actually, clicking around a little trying to avoid the same crash and found a new one, works on the same save as here though.

Also when clicking on an AI planet (with the new game) after doing this had it lock up, finally had to kill -9 it. But haven't been able to duplicate this one.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Crash [build 2015-08-14.b22b7db]

#9 Post by Vezzra »

Am I right assuming that this is an issue recently introduced in master, and not present in the release branch?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Crash [build 2015-08-14.b22b7db]

#10 Post by Geoff the Medio »

Vezzra wrote:...this is an issue recently introduced in master, and not present in the release branch?
Yes.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Crash [build 2015-08-14.b22b7db]

#11 Post by Dilvish »

Geoff the Medio wrote:
Vezzra wrote:...this is an issue recently introduced in master, and not present in the release branch?
Yes.
And just to be sure, I double checked the the repeatable crash here indeed does not happen with 0.4.5.

I'm willing to keep poking at this now and then, adding logging, trying things, but my FO time is going to be in precious short supply for the near future and I have no idea if/when I'd be able to sort this out. Perhaps we should consider putting the repetition/blocksize dropdowns back to requiring left-clicks (until someone has time to really dig into and solve this), since that change seemed to be what triggered this problem.

AndrewW wrote:Dunno if it'll help but found another way to crash the same saved game.
Load saved game.
Click on Odin.
Add one Battleship I to the que.
Change to 5.
Click on an unoccupied planet.
This crash is not repeatable for me. Which unoccupied planet were you clicking on?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Crash [build 2015-08-14.b22b7db]

#12 Post by Geoff the Medio »

Dilvish wrote:Perhaps we should consider putting the repetition/blocksize dropdowns back to requiring left-clicks (until someone has time to really dig into and solve this), since that change seemed to be what triggered this problem.
Seems reasonable.

AndrewW
Juggernaut
Posts: 791
Joined: Mon Feb 04, 2013 10:15 pm

Re: Crash [build 2015-08-14.b22b7db]

#13 Post by AndrewW »

Dilvish wrote:This crash is not repeatable for me. Which unoccupied planet were you clicking on?
Hmmm, did it before with both Khonvoum and Dyson, doesn't do it now though...

But still did it if I did that, then went out of production, clicked a few things at random, went back in added another group of 5 then clicked on Khonvoum.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Crash [build 2015-08-14.b22b7db]

#14 Post by MatGB »

I think the crashes I'm getting are related to this, three different crashes today, 2 within the production window when changing a multiplier (the second was on a fresh load, but when I did the exact same thing on the next load it didn't crash so not always happening, queued a ship, set it to 5, set it to repeat 3 times, crash).

Second was a very simple focus change, I'd accidentally left a planet on logistics for an extra turn, noticed just before hitting end turn, changed it from the system sidepanel and it crashed on me. Logs aren't helpful:
freeoriond.log wrote: 2015-08-18 13:01:11.886101 [debug] Server : Server received message from player id: 1 of type Request New Object ID and size 8
2015-08-18 13:01:35.274871 [debug] Server : Server received message from player id: 1 of type Request New Object ID and size 8
2015-08-18 13:06:15.812091 [debug] Server : ServerNetworking::DisconnectImpl : disconnecting player 1
2015-08-18 13:06:15.813264 [debug] Server : ServerFSM::HandleNonLobbyDisconnection : Lost connection to player #1, named "Mat"; server terminating.
2015-08-18 13:06:15.813666 [debug] Server : ServerFSM::HandleNonLobbyDisconnection : All human players disconnected; server terminating.
2015-08-18 13:06:17.813868 [debug] Server : Initiating Exit (code 1 - error termination)
2015-08-18 13:06:17.813957 [debug] Server : ServerApp::CleanupAIs() telling AIs game is ending
2015-08-18 13:06:17.814279 [debug] Server : ServerApp::CleanupAIs() waiting 1 second for AI processes to clean up...
2015-08-18 13:06:18.814503 [debug] Server : ServerApp::CleanupAIs() killing 9 AI clients.
freeorion.log wrote: 2015-08-18 13:06:12.685115 [debug] Client : PlotFleetMovement
2015-08-18 13:06:15.395917 [debug] Client : SidePanel::PlanetPanel::FocusDropListSelectionChanged
2015-08-18 13:06:15.395991 [debug] Client : Got temporary Ptr.
2015-08-18 13:06:15.396010 [debug] Client : Got resource center.
2015-08-18 13:06:15.396027 [debug] Client : Got selected index (0)
2015-08-18 13:06:15.396931 [debug] Client : Finished checking focus.
2015-08-18 13:06:15.396949 [debug] Client : About to send focus-changed signal.
2015-08-18 13:06:15.504505 [debug] Client : Issue times: planet species: 0.474 ship species: 0.643 specials: 4.451 techs: 19.81 buildings: 0.676 hulls/parts: 4.987 fields: 0.126
2015-08-18 13:06:15.504589 [debug] Client : Evaluation time: 314.577 reorder time: 0.784
2015-08-18 13:06:15.508021 [debug] Client : Universe::ExecuteEffects time: 1.815
2015-08-18 13:06:15.508170 [debug] Client : Universe::UpdateMeterEstimatesImpl on 11 objects time: 320.97
2015-08-18 13:06:15.542971 [debug] Client : Tech Tree Layout Preparing Tech Data
2015-08-18 13:06:15.574452 [debug] Client : Tech Tree Layout Doing Graph Layout
2015-08-18 13:06:15.574498 [debug] Client : TechTreeLayout::DoLayout creaing place holder nodes...
2015-08-18 13:06:15.574664 [debug] Client : Tech Tree Layout Creating Panels
2015-08-18 13:06:15.575166 [debug] Client : Tech Tree Layout Done
2015-08-18 13:06:15.575598 [debug] Client : ========= Production Update for empire: 1 ========
2015-08-18 13:06:15.586684 [debug] Client : ProductionQueue::Update: Simulating future turns of production queue
2015-08-18 13:06:15.591536 [debug] Client : ProductionQueue::Update: Projections took 3330 microseconds with 974.572 total Production Points
2015-08-18 13:06:15.592031 [debug] Client : MapWnd::InitStarlaneRenderingBuffers
2015-08-18 13:06:15.652432 [debug] Client : MapWnd::InitStarlaneRenderingBuffers time: 61.032
2015-08-18 13:06:15.653015 [debug] Client : ProductionWnd::UpdateQueue()
Only thing I note is crash was immediately I hit selected the focus I wanted, and I wasn't in the Production Window.

Turning on verbose logging now as I suspect we need more data.

Edit: forgot, compiled last night from cbf687c
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

AndrewW
Juggernaut
Posts: 791
Joined: Mon Feb 04, 2013 10:15 pm

Re: Crash [build 2015-08-14.b22b7db]

#15 Post by AndrewW »

I've had a few crashes when moving things in the production que, but nothing I've been able to repeat.

Post Reply