Running the test suite

Discussion of all aspects of the game engine, including development of new and existing features.

Moderators: Forum Moderators, Developers

Running the test suite

Postby dedObed » October 3rd, 2016, 7:43 pm

Hi all,
I would like to get into the project. So I cloned the repository, set up all the libraries needed, compiled (scons + gcc). I've even picked a bug to fix! (http://gna.org/bugs/?25106)
The compiled version seems to run nicely: few turns of a random campain, test scenario, even the bug occurs as described at gna.

So I've pulled my sleeves up and run the tests. With a rather disappointing result:
Code: Select all
$ ./test-debug
$ echo $?
200

Nothing on stdout, nothing on stderr.

I have zero experience with boost.test and Google was not very instructive on the issue, so I would appreciate any suggestions. I guess I'm missing something essential, so if you could point me to some reading, it would be magnificent.
dedObed
 
Posts: 2
Joined: October 3rd, 2016, 6:50 pm

Re: Running the test suite

Postby Tad_Carlucci » October 3rd, 2016, 11:06 pm

Sorry, I can't help with 'test-debug' because I don't see the command in the Wesnoth project.

The important parts of the bug report are: wesnoth/src/units/map.hpp:186 ... : Assertion `valid()' failed.

That tells us WHERE the failure occurred. But, when we look, it's inline code so we need to check the stack backtrace .. which is all that Boost stuff. Unfortunately, the backtrace shown does not give filenames. So, since we can reproduce it, let's fire up gdb and do so. This gives me the following backtrace (I'll skip stuff which isn't important) ...

Code: Select all
#4  0x0000000001893a77 in unit_map::iterator_base<unit_map::const_iter_types>::operator* (this=0x7fffffffaf00) at /home/lundberg/wesnoth/src/units/map.hpp:186
#5  0x0000000001ec4d8a in pathfind::vision_path::vision_path (this=0x7fffffffafc0, view_costs=..., slowed=false, sight_range=7, loc=..., jamming_map=std::map with 0 elements) at /home/lundberg/wesnoth/src/pathfind/pathfind.cpp:592
#6  0x00000000018ba79a in actions::shroud_clearer::clear_unit (this=0x7fffffffb180, view_loc=..., view_team=..., viewer_id=18, sight_range=7, slowed=false, costs=..., real_loc=..., known_units=0x0, enemy_count=0x7fffffffb020, friend_count=0x7fffffffb018, spectator=0x0, instant=true) at /home/lundberg/wesnoth/src/actions/vision.cpp:362
#7  0x00000000018bac12 in actions::shroud_clearer::clear_unit (this=0x7fffffffb180, view_loc=..., view_team=..., viewer=..., instant=true) at /home/lundberg/wesnoth/src/actions/vision.cpp:444
#8  0x00000000018ace84 in actions::undo_list::apply_shroud_changes (this=0x7fffbe3e9cc0) at /home/lundberg/wesnoth/src/actions/undo.cpp:473
#9  0x00000000018ab6f4 in actions::undo_list::commit_vision (this=0x7fffbe3e9cc0) at /home/lundberg/wesnoth/src/actions/undo.cpp:247


So, the inllined operator* conversion was called from wesnoth/src/pathfind/pathfind.cpp:592 which reads:

find_routes(loc, view_costs, slowed, sight_range, sight_range, 0,
destinations, &edges, &*u, nullptr, nullptr, &viewing_team, &jamming_map, nullptr, true);

And we're looking for a map iterator using operator* .. the &*u part.

Now we know where things went wrong (the iterator was created on the line just above). So the question is why was it not valid?

Have fun ...
I forked real life and now I'm getting merge conflicts.
Tad_Carlucci
Developer
 
Posts: 178
Joined: April 24th, 2016, 4:18 pm

Re: Running the test suite

Postby iceiceice » October 4th, 2016, 12:08 am

Can you show a little more detail of how you are building? And confirm the really basic stuff like, the test executable actually was built, the executable exists, it is named `test_debug` and not `test` etc.?

In the past, I've seen things like, the test suite crashing with an assertion failure or segfault. And that would produce a large return code like 200. But there will also be some more text on stderr if that happens. The console log you posted looks pretty strange to me.

You could also try running,

Code: Select all
gdb ./test_debug


and see what it reports, if it's not giving you sufficient info? `gdb` is the gnu debugger.

Edit:

For comparison, I just cloned wesnoth and build using scons, this is what I get.

Code: Select all
$ git clone https://github.com/wesnoth/wesnoth
$ scons ccache=true
$ scons test
$ ./test
Running 159 test cases...
error gui/layout: tgrid [] place: Failed to place a grid, we have 392,38 space but we need 421,38 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'scenario_settings_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui210tgeneratorINS_6policy17minimum_selection5tnoneENS1_17maximum_selection9tinfiniteENS1_9placement12tindependentENS1_13select_action5tshowEEE' with the id '_content_grid' in a 'N4gui25tgridE' with the id '' in a 'N4gui215tstacked_widgetE' with the id 'pager' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'game_stats'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 392,38 space but we need 421,38 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'scenario_settings_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui210tgeneratorINS_6policy17minimum_selection5tnoneENS1_17maximum_selection9tinfiniteENS1_9placement12tindependentENS1_13select_action5tshowEEE' with the id '_content_grid' in a 'N4gui25tgridE' with the id '' in a 'N4gui215tstacked_widgetE' with the id 'pager' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'game_stats'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 392,38 space but we need 421,38 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'scenario_settings_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui210tgeneratorINS_6policy17minimum_selection5tnoneENS1_17maximum_selection9tinfiniteENS1_9placement12tindependentENS1_13select_action5tshowEEE' with the id '_content_grid' in a 'N4gui25tgridE' with the id '' in a 'N4gui215tstacked_widgetE' with the id 'pager' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'game_stats'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 392,38 space but we need 421,38 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'scenario_settings_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui210tgeneratorINS_6policy17minimum_selection5tnoneENS1_17maximum_selection9tinfiniteENS1_9placement12tindependentENS1_13select_action5tshowEEE' with the id '_content_grid' in a 'N4gui25tgridE' with the id '' in a 'N4gui215tstacked_widgetE' with the id 'pager' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'game_stats'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 0,30 space but we need 46,30 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'sides_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'mp_change_control'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 0,30 space but we need 94,30 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'nicks_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'mp_change_control'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 0,30 space but we need 46,30 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'sides_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'mp_change_control'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 0,30 space but we need 94,30 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'nicks_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'mp_change_control'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 0,30 space but we need 46,30 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'sides_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'mp_change_control'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 0,30 space but we need 94,30 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'nicks_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'mp_change_control'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 0,30 space but we need 46,30 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'sides_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'mp_change_control'.
error gui/layout: tgrid [] place: Failed to place a grid, we have 0,30 space but we need 94,30 space. This happened at a grid with the id '' in a 'N4gui28tlistboxE' with the id 'nicks_list' in a 'N4gui25tgridE' with the id '' in a 'N4gui25tgridE' with the id '_window_content_grid' in a 'N4gui25tgridE' with the id '_content_grid' in a 'N4gui216tscrollbar_panelE' with the id '' in a 'N4gui25tgridE' with the id '' in a 'N4gui27twindowE' with the id 'mp_change_control'.


Edit:

Okay, I tried building in debug mode like you did, and now I can reproduce:

Code: Select all
$ scons build=debug test
$ ./test-debug
$


When I run through gdb, I get an actual segfault and backtrace:
Code: Select all
$ gdb ./test-debug
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test-debug...done.
(gdb) run
Starting program: /home/chris/wesnoth/wesnoth/test-debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe875a700 (LWP 21470)]

Thread 1 "test-debug" received signal SIGSEGV, Segmentation fault.
0x000000000043585a in __gnu_cxx::__exchange_and_add (__mem=0x59, __val=-1)
    at /usr/include/c++/5/ext/atomicity.h:49
49     { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
(gdb) bt
#0  0x000000000043585a in __gnu_cxx::__exchange_and_add (__mem=0x59, __val=-1)
    at /usr/include/c++/5/ext/atomicity.h:49
#1  0x00000000004358ba in __gnu_cxx::__exchange_and_add_dispatch (__mem=0x59,
    __val=-1) at /usr/include/c++/5/ext/atomicity.h:82
#2  0x000000000043931b in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x51) at /usr/include/c++/5/bits/shared_ptr_base.h:147
#3  0x0000000000438e29 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x2145508, __in_chrg=<optimized out>)
    at /usr/include/c++/5/bits/shared_ptr_base.h:659
#4  0x00000000009a1408 in std::__shared_ptr<t_string_base const, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x2145500, __in_chrg=<optimized out>)
    at /usr/include/c++/5/bits/shared_ptr_base.h:925
#5  0x00000000010b43a4 in std::shared_ptr<t_string_base const>::~shared_ptr (
    this=0x2145500, __in_chrg=<optimized out>)
    at /usr/include/c++/5/bits/shared_ptr.h:93
#6  0x00000000010b3d40 in t_string::~t_string (this=0x2145500,
    __in_chrg=<optimized out>) at src/tstring.cpp:568
#7  0x00000000007bfdd4 in gui2::ttip::~ttip (this=0x21454d0,
    __in_chrg=<optimized out>) at src/gui/dialogs/tip.cpp:68
#8  0x0000000000859083 in std::_Destroy<gui2::ttip> (__pointer=0x21454d0)
    at /usr/include/c++/5/bits/stl_construct.h:93
#9  0x0000000000857d2f in std::_Destroy_aux<false>::__destroy<gui2::ttip*> (
    __first=0x21454d0, __last=0x2145508)
#10 0x0000000000855934 in std::_Destroy<gui2::ttip*> (__first=0x21454d0,
    __last=0x2145508) at /usr/include/c++/5/bits/stl_construct.h:126
#11 0x0000000000853efb in std::_Destroy<gui2::ttip*, gui2::ttip> (
    __first=0x21454d0, __last=0x2145508)
    at /usr/include/c++/5/bits/stl_construct.h:151
#12 0x0000000000ce4b66 in std::vector<gui2::ttip, std::allocator<gui2::ttip> >::_M_emplace_back_aux<gui2::ttip>(gui2::ttip&&) (this=0x7fffffffd260)
    at /usr/include/c++/5/bits/vector.tcc:436
#13 0x0000000000ce46eb in std::vector<gui2::ttip, std::allocator<gui2::ttip> >::emplace_back<gui2::ttip>(gui2::ttip&&) (this=0x7fffffffd260)
    at /usr/include/c++/5/bits/vector.tcc:101
#14 0x0000000000ce44f6 in std::vector<gui2::ttip, std::allocator<gui2::ttip> >::push_back(gui2::ttip&&) (this=0x7fffffffd260,
    __x=<unknown type in /home/chris/wesnoth/wesnoth/test-debug, CU 0x47db4a4, DIE 0x47f4695>) at /usr/include/c++/5/bits/stl_vector.h:932
#15 0x0000000000ce4037 in gui2::tips::load (cfg=...)
    at src/gui/core/tips.cpp:43
#16 0x000000000084f626 in gui2::tgui_definition::read[abi:cxx11](config const&)
    (this=0x7fffffffd5f0, cfg=...) at src/gui/widgets/settings.cpp:413
#17 0x0000000000850810 in gui2::load_settings ()
    at src/gui/widgets/settings.cpp:529
#18 0x00000000007fdd48 in gui2::init () at src/gui/widgets/helper.cpp:43
---Type <return> to continue, or q <return> to quit---
#19 0x000000000048331a in wesnoth_global_fixture::wesnoth_global_fixture (
    this=0x1d11bf0) at src/tests/main.cpp:82
#20 0x0000000000484026 in boost::unit_test::ut_detail::global_fixture_impl<wesnoth_global_fixture>::test_start (this=0x1cde110 <gf_wesnoth_global_fixture>)
    at /usr/include/boost/test/unit_test_suite_impl.hpp:341
#21 0x00007ffff4662e24 in boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::ut_detail::test_start_caller>::invoke() ()
   from /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0
#22 0x00007ffff465b996 in boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) ()
   from /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0
#23 0x00007ffff465c1b3 in boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) ()
   from /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0
#24 0x00007ffff465e214 in boost::unit_test::framework::run(unsigned long, bool)
    () from /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0
#25 0x00007ffff467a287 in boost::unit_test::unit_test_main(bool (*)(), int, char**) () from /usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.58.0
#26 0x0000000000482e9c in main (argc=1, argv=0x7fffffffe5e8)
    at /usr/include/boost/test/unit_test.hpp:59
(gdb)


It looks like something is broken regarding tstrings and the unit test suite, but I don't know what exactly. (Or possibly, in the gui2 tool tips.)

This looks like a major bug. If it can't be solved then ideally we could bisect it and find the offending commit where this started happening. It appears to me that wesnoth CI does not currently test debug builds (See .travis.yml). Presumably, because it takes too long to do a debug build on travis. I don't know what is a good solution then, other than people running debug builds of the test suite from time to time.

Edit: Indeed, in retrospect this is exactly what you should expect in the case of a segfault. With luck, you will actually get a SIGSEGV signal from the application, but it is undefined behavior and you may just get a hard crash with no report if you aren't running from gdb.
User avatar
iceiceice
Developer
 
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: Running the test suite

Postby shadowm » October 4th, 2016, 4:57 am

Bug #25105 [Gna.org], perhaps? For me, the -O0 test suite dumps libc diagnostics and dies with SIGABRT within a second after launch, whereas the -O3 version runs and passes all tests somehow. I’ve told people that this might be a symptom of a more severe issue even before the sanitizer results were posted, but I don’t think anyone has properly looked into it yet.

Code: Select all
% ./test-debug
*** Error in `./test-debug': free(): invalid pointer: 0x00000000036e89ff ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f0ec1514bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7f0ec151afa6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7f0ec151b79e]
/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.61.0(_ZN5boost6detail8function15functor_managerINS_3_bi6bind_tIvNS_4_mfi3mf1IvNS_9unit_test13test_observerEmEENS3_5list2INS3_5valueIPS8_EENSB_INS7_17test_case_counter19readonly_property41EEEEEEEE6manageERKNS1_15function_bufferERSK_NS1_30functor_manager_operation_typeE+0xfd)[0x7f0ec212739d]
/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.61.0(_ZN5boost9unit_test9framework3runEmb+0x1568)[0x7f0ec2126e28]
/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.61.0(_ZN5boost9unit_test14unit_test_mainEPFbvEiPPc+0x3ff)[0x7f0ec214979f]
./test-debug(main+0x22)[0x4837ea]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f0ec14c42b1]
./test-debug[0x42b75a]
======= Memory map: ========
00400000-01a50000 r-xp 00000000 08:13 86545330                           /home/shadowm/src/wesnoth/test-debug
01c4f000-01c56000 rw-p 0164f000 08:13 86545330                           /home/shadowm/src/wesnoth/test-debug
01c56000-01c6a000 rw-p 00000000 00:00 0
03693000-0404d000 rw-p 00000000 00:00 0                                  [heap]
[...]
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
I also made Wesnoth RCX, a team-color preview tool for artists and content creators.
Elsewhere: shadowmBlogFollow me on Twitter
User avatar
shadowm
Wesnoth.org Administrator
 
Posts: 6177
Joined: November 14th, 2006, 5:54 pm
Location: Chile

Re: Running the test suite

Postby dedObed » October 4th, 2016, 9:45 am

@Tad_Carlucci , thanks, I can even tell you that the iterator is not valid, because it is equal to the .end() of the respective container ;) My intention is to first create an automated test catching the bug and only then fix it.

@iceiceice I confirm that it is the test-debug executable, the test executable runs. However, I've got some more errors in addition to those about grid placing:
Code: Select all
..../wesnoth $ ./test
Running 159 test cases...
error config: Error while loading the map: Illegal tile in map: (Mm) 'Mm'
error config: Error while loading the map: Illegal tile in map: (Mm) 'Mm'
error config: Error while loading the map: Illegal tile in map: (Mm) 'Mm'
error config: Error while loading the map: Illegal tile in map: (Mm) 'Mm'
error config: Error while loading the map: Illegal tile in map: (Mm) 'Mm'
error config: Error while loading the map: Illegal tile in map: (Mm) 'Mm'
error config: Error while loading the map: Illegal tile in map: (Mm) 'Mm'
error config: Error while loading the map: Illegal tile in map: (Mm) 'Mm'
...


It is a clean build, I did exactly:
Code: Select all
git clone "https://github.com/wesnoth/wesnoth.git" wesnoth
cd wesnoth/
scons ccache=true
scons test
./test


EDIT: It is getting more interesting. I've returned from the work and run the tests again (./test). Instead of the errors above, I got the following:
Code: Select all
error config: Error while loading the map: Illegal tile in map: (Gs^Fds) 'Gs^Fds'
error config: Error while loading the map: Illegal tile in map: (Gs^Fds) 'Gs^Fds'
error config: Error while loading the map: Illegal tile in map: (Gs^Fds) 'Gs^Fds'
error config: Error while loading the map: Illegal tile in map: (Gs^Fds) 'Gs^Fds'
error config: Error while loading the map: Illegal tile in map: (Gs^Fds) 'Gs^Fds'
error config: Error while loading the map: Illegal tile in map: (Gs^Fds) 'Gs^Fds'
error config: Error while loading the map: Illegal tile in map: (Gs^Fds) 'Gs^Fds'
error config: Error while loading the map: Illegal tile in map: (Gs^Fds) 'Gs^Fds'
...


Running any test suite separately (via the ./test --run_test=SUITE) did not reveal this error (nor the gui ones). However, this did not cover all the tests. I will look into running the tests individually. Hopefully tomorrow :)
dedObed
 
Posts: 2
Joined: October 3rd, 2016, 6:50 pm


Return to Coder’s Corner

Who is online

Users browsing this forum: No registered users and 3 guests