bugBattle for Wesnoth - Bugs: bug #22250, Using no_leader=yes causes 100%...

Show feedback again

bug #22250: Using no_leader=yes causes 100% CPU usage

Submitted by:  Dan Gerhards <beetlenaut>
Submitted on:  Mon Jun 30 07:28:30 2014  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Artificial Intelligence
Status: FixedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: 1.11.15Operating System: Linux

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Wed Jul 16 08:16:49 2014, comment #4:

In 1.11.16 I can't reproduce this bug any more. It seems to be fixed. Also rather puzzling, unless you made some progress.

Dan Gerhards <beetlenaut>
Project Member
Sun Jul 13 15:49:11 2014, comment #3:

Hmm, it is very strange that no_leader=yes would be related to that backtrace, I didn't find any reference to that (or leaders) in those functions...

The only thing in display that I could think would be relevant is when we are trying to scroll to the leader?

Very puzzling.

Chris Beck <involution>
Project Member
Fri Jul 11 02:05:14 2014, comment #2:

(Sorry for the slow response--I've been out of town with no Internet.)

I did what you suggested. The backtrace looks like this every time:

So, the loop seems to be in SDL. (The exact memory location in #0 varies, but not by much.) With that in mind, I tried running at a lower resolution, and the problem did not occur. The CPU was not overloaded, and stopping the program with gdb always gave me a location in nanosleep, which sounds normal.

All I do to reproduce this is to load the scenario, but I usually run BfW at 2560 x 1440, and apparently that's part of the problem.

Dan Gerhards <beetlenaut>
Project Member
Mon Jul 7 20:24:30 2014, comment #1:

I could reproduce this the first time but only after I was defeated, then the game locked up and I had to kill it from the OS.

I tried three more times to reproduce the same way and I couldn't get it, all of those times I ran the program through gdb.

If you can reproduce it while running from gdb, then you can kill it with ctrl+c in the gdb terminal, then run "bt" to get a backtrace from the spot where you interrupted it. I think you can also do "continue" to continue execution, so with a few backtraces you can get a good idea what the loop is.

But I can't seem to reproduce in gdb, so I'm not sure I have the reproduction method down.

Tested on Ford of Abez.

Chris Beck <involution>
Project Member
Mon Jun 30 07:28:30 2014, original submission:

Five scenarios in HttT (for example) cause the CPU usage to peg at 100%. They are all the ones that have a side with no_leader=yes. Removing that side fixes the problem. The problem is immediately apparent in The Ford of Abez, The Dwarven Doors, Cliffs of Thoria, and Underground Channels. Plunging into Darkness has the problem too, but only if you remove the shroud and highlight a unit, so there may be some complexities involved.

(I'm not sure that the Item Group for this bug is AI, but that seems probable.)

Dan Gerhards <beetlenaut>
Project Member


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by mattsc (Updated the item)
  • -unavailable- added by involution (Posted a comment)
  • -unavailable- added by beetlenaut (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Oct 6 18:34:22 2014mattscStatusNone=>Fixed
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup