bugBattle for Wesnoth - Bugs: bug #20385, Using subnamespaces with...

Show feedback again

bug #20385: Using subnamespaces with [set_global_variable] causes invalid memory access

Submitted by:  Ignacio R. Morelle <shadowmaster>
Submitted on:  Mon Dec 24 21:09:57 2012  
Category: BugSeverity: 5 - Blocker
Priority: 5 - NormalItem Group: WML
Status: FixedPrivacy: Public
Assigned to: Jody Northup <upthorn>Open/Closed: Closed
Release: 1.10.x, 1.11.xOperating System: Linux, Mac OS X

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

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


Sat Apr 13 15:56:25 2013, comment #2:

Just committed Upthorn's patches for master and 1.10 to deal with this issue.

Ignacio R. Morelle <shadowmaster>
Project Administrator
Wed Apr 3 09:37:26 2013, comment #1:

Here is a persistence file resulting from an unknown number of runs of the test campaign.

(file #17663)

Alexander van Gessel <ai0867>
Project Member
Mon Dec 24 21:09:57 2012, original submission:

Using subnamespaces like "Namespace.Subnamespace" with the [set_global_variable] WML action (http://wiki.wesnoth.org/PersistenceWML) causes a series of invalid memory access operations that may result in a segmentation fault either immediately, or after a while (even when running unrelated code).

I had first spotted this issue in my add-on After the Storm on Linux, and vultraz confirmed that the issue also affects Mac OS X. The only known workaround (which I have been using since then) is to not use real subnamespaces, e.g. by replacing the above with "Namespace_Subnamespace". This issue affects current 1.10.x versions, as well as 1.11.x/trunk.

I have published a single-file add-on with the minimum code necessary to trigger the issue on a Wesnoth-UMC-Dev branch:


Click on "Download GNU Tarball" after the file listing on that page to download the add-on. The instructions and triggering WML can be found inside the _main.cfg file.

I have run this code with a debug build on Valgrind and encountered a flood of invalid memory access warnings after the point at which the [set_global_variable] action is executed. The triggering code is in fact the PersistenceWML implementation, but it is too dense for me to try to find the cause.

I have attached the relevant portion of the Valgrind output to this bug report.

Ignacio R. Morelle <shadowmaster>
Project Administrator


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

Attach File(s):

Attached Files
file #17663:  PersistenceWML.cfg added by ai0867 (1kB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by ai0867 (Updated the item)
  • -unavailable- added by shadowmaster (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 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Aug 18 04:51:20 2013shadowmasterOpen/ClosedOpen=>Closed
    Sat Apr 13 15:56:25 2013shadowmasterStatusNone=>Fixed
    Wed Apr 3 09:37:26 2013ai0867Attached File-=>Added PersistenceWML.cfg, #17663
    Mon Dec 24 21:12:50 2012shadowmasterItem Group None of the others=>WML
    Mon Dec 24 21:12:01 2012shadowmasterAssigned toNone=>upthorn
    Mon Dec 24 21:09:57 2012shadowmasterAttached File-=>Added persistencewml_memcheck_portion.log.gz, #16870
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup