[Wesnoth-bugs] [bug #18683] Leader sprite is missing in the load game dialog

2016-10-23 Thread Charles Dang 
Update of bug #18683 (project wesnoth):

  Status: In Progress => Fixed  

___

Follow-up Comment #14:

In 1.13.5+dev I've ensured the binary path is parsed twice - once at save
index creation and again when the Load Game dialog is shown. If neither
returns a usable image, the 'unknown unit' image is displayed instead.

The save_index mechanism will save the relative path on binary path lookup
fail so it has a chance to at least be shown correctly in the dialog as long
as the correct binary path data is loaded. Note that it doesn't resave the
full path back to the save index; I'm not sure that's possible.

Anyway, I consider this fixed.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #24164] Demote halos toggle to Advanced Preferences

2016-10-23 Thread Charles Dang 
Update of bug #24164 (project wesnoth):

  Status:None => Fixed  
 Assigned to:shadowmaster => vultraz

___

Follow-up Comment #1:

Demoted 
https://github.com/wesnoth/wesnoth/commit/231cb1a4a4f36543ca0d9cbe0bca6dd896b57216

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #19320] Chat log should show latest messages, not oldest

2016-10-23 Thread Charles Dang 
Update of bug #19320 (project wesnoth):

  Status:None => Ready For Test 
 Assigned to:shadowmaster => vultraz

___

Follow-up Comment #2:

Should finally be fixed here:
https://github.com/wesnoth/wesnoth/commit/b89731c7ac48ead261217aa7f532e37d8870d113
Wasn't able to test since one would need to play an mp game.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25080] UB in map resize window

2016-10-23 Thread Wedge009 
Follow-up Comment #5, bug #25080 (project wesnoth):

Hmm, it's been a while since I've really worked in-depth in C/C++. I recall
the stuff about passing by reference when you're dealing with function
parameters. But in this case expand_direction_ is a private member of the
teditor_resize_map class. Is it really necessary or helpful to have it as a
reference? I recall another bug where you suggested that the member reference
needed to be changed to just a reference value - and that worked. Don't recall
what bug report that was, though.

I know C++ has advanced a lot since I worked with it in the early 2000s
(C++11/14/etc), I feel like such a newbie again!

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25186] [message] lag

2016-10-23 Thread Pentarctagon 
Follow-up Comment #10, bug #25186 (project wesnoth):

I used gdb and got a few stacktraces, and they're all identical to the below
except for a few memory addresses changing:

(gdb) bt
#0  0x7fffe6abd51e in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#1  0x7fffe69b8b35 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#2  0x7fffe69b8eb3 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#3  0x7fffe69d1453 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#4  0x7fffe69d172c in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#5  0x7fffe6a8cc12 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#6  0x7fffe670df62 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#7  0x7fffe670f397 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#8  0x7fffe672b4f4 in ?? () from
/usr/lib/nvidia-370/libnvidia-glcore.so.370.28
#9  0x76ddec54 in ?? () from
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#10 0x76dd8386 in ?? () from
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#11 0x76e31449 in ?? () from
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#12 0x76e329ca in ?? () from
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#13 0x011c4162 in sdl::twindow::render (this=0x1e060f0) at
src/sdl/window.cpp:110
#14 0x01169c73 in CVideo::flip (this=0x1ccdc50) at src/video.cpp:391
#15 0x004afa5a in gui2::event::thandler::draw (this=0x3cbab20,
force=false) at src/gui/core/event/handler.cpp:537
#16 0x004af1df in gui2::event::thandler::handle_event (this=0x3cbab20,
event=...) at src/gui/core/event/handler.cpp:357
#17 0x010a1c9f in events::pump () at src/events.cpp:593
#18 0x005cc0b7 in gui2::twindow::show (this=0xf545f00, restore=true,
auto_close_timeout=0) at src/gui/widgets/window.cpp:638
#19 0x004b50ca in gui2::tdialog::show (this=0xfb053b0, video=...,
auto_close_time=0) at src/gui/dialogs/dialog.cpp:68
#20 0x00b05fcb in gui2::show_wml_message (video=..., title="",
message="", left=0x82afb00, right=0x0, options=..., input=...) at
src/gui/dialogs/wml_message.cpp:187
#21 0x0064c68f in lua_gui2::show_message_dialog (L=0x7fffc45c3ac8,
video=...) at src/scripting/lua_gui2.cpp:357
#22 0x00653522 in lua_kernel_base::video_dispatch_impl
(this=0x7fffc0974a50, L=0x7fffc45c3ac8, callback=0x64b3c8
) at
src/scripting/lua_kernel_base.cpp:127
#23 0x00657401 in video_dispatch<_gui2::show_message_dialog>
(L=0x7fffc45c3ac8) at src/scripting/lua_kernel_base.cpp:121
#24 0x00f939f4 in luaD_precall (L=0x7fffc45c3ac8, func=0x7fffc2b432a0,
nresults=2) at src/lua/ldo.cpp:365
#25 0x00fa7c39 in luaV_execute (L=0x7fffc45c3ac8) at
src/lua/lvm.cpp:1134
#26 0x00f94040 in luaD_call (L=0x7fffc45c3ac8, func=0x7fffc2b43290,
nResults=1) at src/lua/ldo.cpp:496
#27 0x00f9409e in luaD_callnoyield (L=0x7fffc45c3ac8,
func=0x7fffc2b43290, nResults=1) at src/lua/ldo.cpp:506
#28 0x00f8fe47 in f_call (L=0x7fffc45c3ac8, ud=0x7fff1d10) at
src/lua/lapi.cpp:942
#29 0x00f92ede in luaD_rawrunprotected (L=0x7fffc45c3ac8, f=0xf8fe12
, ud=0x7fff1d10) at src/lua/ldo.cpp:142
#30 0x00f94870 in luaD_pcall (L=0x7fffc45c3ac8, func=0xf8fe12
, u=0x7fff1d10, old_top=880, ef=864) at
src/lua/ldo.cpp:727
#31 0x00f8ff25 in lua_pcallk (L=0x7fffc45c3ac8, nargs=1, nresults=1,
errfunc=-3, ctx=0, k=0x0) at src/lua/lapi.cpp:968
#32 0x0064636e in luaW_pcall_internal (L=0x7fffc45c3ac8, nArgs=1,
nRets=1) at src/scripting/lua_common.cpp:940
#33 0x006463f5 in luaW_pcall (L=0x7fffc45c3ac8, nArgs=1, nRets=1,
allow_wml_error=false) at src/scripting/lua_common.cpp:956
#34 0x0061a74e in (anonymous namespace)::lua_synchronize::query_lua
(this=0x7fff22f0, side=1, function_index=2, cfg=...) at
src/scripting/game_lua_kernel.cpp:2581
#35 0x0061a59b in (anonymous namespace)::lua_synchronize::query_user
(this=0x7fff22f0, side=1) at src/scripting/game_lua_kernel.cpp:2558
#36 0x00699c67 in user_choice_manager::ask_local_choice
(this=0x7fff1ff0) at src/synced_user_choice.cpp:343
#37 0x0069a4bf in user_choice_manager::get_user_choice_internal
(name="input", uch=..., sides=std::set with 1 elements = {...}) at
src/synced_user_choice.cpp:419
#38 0x006988eb in mp_sync::get_user_choice (name="input", uch=...,
side=1) at src/synced_user_choice.cpp:216
#39 0x0061a9c0 in intf_synchronize_choice (L=0x7fffc45c3ac8) at
src/scripting/game_lua_kernel.cpp:2625
#40 0x00f939f4 in luaD_precall (L=0x7fffc45c3ac8, func=0x7fffc2b43240,
nresults=1) at src/lua/ldo.cpp:365
#41 0x00fa7c39 in luaV_execute (L=0x7fffc45c3ac8) at
src/lua/lvm.cpp:1134
#42 0x00f94040 in luaD_call (L=0x7fffc45c3ac8, func=0x7fffc2b42f40,
nResults=0) at src/lua/ldo.cpp:496

[Wesnoth-bugs] [bug #25186] [message] lag

2016-10-23 Thread Pentarctagon 
Follow-up Comment #9, bug #25186 (project wesnoth):

Alright, I'll try the debugger.  I had actually tried using valgrind/callgrind
with Wesnoth's debug build earlier today, but it froze on the main menu after
taking ~10 minutes to start up.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25186] [message] lag

2016-10-23 Thread Daniel 
Follow-up Comment #8, bug #25186 (project wesnoth):

> Ram usage not particularly, but the CPU does increase noticeably  ..

Thx for this information.

Hm ok i think the easiest Way to figure out what's wrong would be to rprpdce
this in a profiler and then just check what the cpu is doing all the time. If
you don't have a profiler and just a normal debugger, you can try to reproduce
this in a debugger and then at 5 random times while the game is freezing with
100% cpu usage press stop in the debugger and look at the stacktrace.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25186] [message] lag

2016-10-23 Thread Pentarctagon 
Follow-up Comment #7, bug #25186 (project wesnoth):

Ram usage not particularly, but the CPU does increase noticeably - Wesnoth is
shown as taking 100% of a single logical CPU core.  You can see in the video I
linked starting at 0:42 Wesnoth is taking ~12% of the total CPU (4 physical/8
logical cores), and after that at 0:51 the graph shows one of the cores as
being constantly at 100% usage.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25080] UB in map resize window

2016-10-23 Thread Daniel 
Follow-up Comment #4, bug #25080 (project wesnoth):

expand_direction_ is like an output paramter of that dialog, like when you
pass a pointer as a parameter to a function, but actually the function ignores
the value of that parameter and just write it so tzhat the caller can use it.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25224] add translation friendly string.format function

2016-10-23 Thread Daniel 
URL:
  

 Summary: add translation friendly string.format function
 Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: So 23 Okt 2016 22:56:45 UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13
Operating System:  

___

Details:

as noted by celmin, codes like:

stding.format(_("Yout got %n, but you need %n"), n_items, max_items)

are not really translation friendly since it can happen that the 2 numbers
appear in a different order in the translated string.

To fix this issue we need a different function like

newfunction(_("Yout got %items, but you need %items_needed"), {items =
n_items, items_needed = max_items})

that doesn't identify the inserted strings by their index. 

Ideally such function would also return a lua tstring userdata if one of it's
parameters was a tstring.




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25186] [message] lag

2016-10-23 Thread Daniel 
Follow-up Comment #6, bug #25186 (project wesnoth):

When the lag appears does wesnoths ram or cpu useage increate noticably?

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25222] crash in planning mode, moving planned recruit

2016-10-23 Thread Daniel 
Follow-up Comment #2, bug #25222 (project wesnoth):

> when I was testing, num_turns() returned 1 and it was the first turn of the
game

You know what the 'turn_num' variable was?


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25222] crash in planning mode, moving planned recruit

2016-10-23 Thread Wedge009 
Update of bug #25222 (project wesnoth):

  Status:None => Confirmed  
 Release: git => 1.13.5+dev 
Operating System:   linux => All

___

Follow-up Comment #1:

I hate planning mode and I hate planned recruits in particular. ): Maybe I
should re-introduce my PR to disable planned recruits altogether.


//for a little extra safety, since we should never resize by much at a time
assert(turn_num <= num_turns() || future_only);


I'm not sure if anyone still active really knows what the planning code is
doing. But the general way to replicate this issue is to plan a recruit and
then plan several turns of movement (when I was testing, num_turns() returned
1 and it was the first turn of the game).

I disabled planned movements on planned recruits a while back but it only
cancels the planned movement when you attempt to add it to the queue. So I
suppose there's still some background processing involved which is where this
assertion gets hit. Incidentally, ignoring the assertion failure seems okay...
until you go to close the game in which case there's another crash/exception,
presumably due to the assertions failing the first time around.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25218] UB when TOD progresses

2016-10-23 Thread Wedge009 
Update of bug #25218 (project wesnoth):

  Status:  Ready For Test => Fixed  
 Assigned to:None => wedge009   


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25223] planning mode: don't allow planning of movement after planning of attack

2016-10-23 Thread Wedge009 
Follow-up Comment #1, bug #25223 (project wesnoth):

It's risky to predict that far into the future, of course - as you never
really know what the outcome of the attack will be nor where the enemy will be
afterwards - but it is indeed possible to attack and then move afterwards (in
the subsequent turn).

As much as I dislike planning mode I don't really think this is an actual
problem nor would it make sense to disallow a planned move after a planned
attack.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25218] UB when TOD progresses

2016-10-23 Thread Matthias Krüger 
Follow-up Comment #3, bug #25218 (project wesnoth):

Looks good.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25220] UB: integer overflow (ai) in test scenario

2016-10-23 Thread Wedge009 
Update of bug #25220 (project wesnoth):

 Release: git => 1.13.5+dev 

___

Follow-up Comment #1:


int rating = hp * defense * most_damage * village_bonus / 200;


I wasn't able to get that huge value. But maybe those more familiar with the
AI (mattsc?) should have a look at this and check for the potential for huge
numbers to be processed and potentially overflowing the rating value. Most of
the values I saw being processed was in the order of millions.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25223] planning mode: don't allow planning of movement after planning of attack

2016-10-23 Thread Matthias Krüger 
URL:
  

 Summary: planning mode: don't allow planning of movement
after planning of attack
 Project: Battle for Wesnoth
Submitted by: matthiaskrgr
Submitted on: Sun 23 Oct 2016 11:17:13 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: v1.13.5+dev
Operating System: all

___

Details:

It's possible to first plan a unit to attack something and then plan the same
unit to move afterwards which makes no sense since the move is not going to be
executed after the attack in non-planned gameplay.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25221] MP slot selection becomes black

2016-10-23 Thread Wedge009 
Update of bug #25221 (project wesnoth):

 Release: git => 1.13.5+dev 

___

Follow-up Comment #1:

At first I thought this might be related to bug #25107, but it doesn't look
like it. I'm playing around with the colour selection in both Windows and
Linux and I can't see what you're describing.

I wonder if it's something to do with your SDL version or maybe graphics
drivers.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25219] UB: left shift of -1000 on AI turn

2016-10-23 Thread Wedge009 
Update of bug #25219 (project wesnoth):

 Release: git => 1.13.5+dev 
Operating System:   linux => All

___

Follow-up Comment #1:


std::size_t hash_value(map_location  const & a){
std::hash h;
return h( (a.x << 16) ^ a.y );
}


I suppose map location co-ordinates are normally non-negative integers. x and
y are both defined as signed ints and initialised to -1000 by default
(map/location.hpp:63). I don't really know what the hash_value() function is
intending to calculate - wondering if there should be some check if the
co-ordinates are negative and return something else if they are.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25218] UB when TOD progresses

2016-10-23 Thread Wedge009 
Update of bug #25218 (project wesnoth):

  Status:None => Ready For Test 
 Release: git => 1.13.5+dev 
Operating System:   linux => All

___

Follow-up Comment #2:

I think it should start with false. Looking at the tod_manager methods, all
the functions which touch has_tod_bonus_changed_ set it to true, except for
set_turn(), which sets it to false.

Anyone who knows more about the ToD stuff, please feel free to correct or
confirm.

https://github.com/wesnoth/wesnoth/commit/5d144595945ae3a5614433105d621eef2298f657

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25222] crash in planning mode, moving planned recruit

2016-10-23 Thread Matthias Krüger 
URL:
  

 Summary: crash in planning mode, moving planned recruit
 Project: Battle for Wesnoth
Submitted by: matthiaskrgr
Submitted on: Sun 23 Oct 2016 10:40:46 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: git
Operating System: linux

___

Details:

start game on sablestone delta with FoW but no shroud as undead
move leader to keep
start planning mode
in planning mode:
recruit skeleton
select planned recruit skeleton and move it to the lower right corner of the
map

There was an assertion failure:
wesnoth:
/home/matthias/vcs/github/wesnoth/src/whiteboard/side_actions.cpp:163:
wb::side_actions_container::iterator wb::side_actions_container::queue(size_t,
wb::action_ptr): Assertion `turn_num <= num_turns() || future_only' failed.







___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25221] MP slot selection becomes black

2016-10-23 Thread Matthias Krüger 
URL:
  

 Summary: MP slot selection becomes black
 Project: Battle for Wesnoth
Submitted by: matthiaskrgr
Submitted on: Sun 23 Oct 2016 10:28:01 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: git
Operating System: linux

___

Details:

Multiplayer
Local game
create game
=> hover cursor between team color selector and background of the widget(?)

the background will become darker every time until text is completely
unreadable




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25095] wesnoth -t: "reload & exec lua code" segfaults

2016-10-23 Thread Wedge009 
Update of bug #25095 (project wesnoth):

  Status:  Ready For Test => Fixed  

___

Follow-up Comment #3:

1.12 and 1.13 show slightly different error messages, but I think that's due
to the refactoring/upgrade. Behaviour between Windows and Linux appears to be
the same.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25220] UB: integer overflow (ai) in test scenario

2016-10-23 Thread Matthias Krüger 
URL:
  

 Summary: UB: integer overflow (ai) in test scenario
 Project: Battle for Wesnoth
Submitted by: matthiaskrgr
Submitted on: Sun 23 Oct 2016 10:13:29 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: git
Operating System: linux

___

Details:

start wesnoth -t
end turn
when the game asks for selections in dialogs, just select the topmost option.

At some point during the AI turn, you should encounter

/home/matthias/vcs/github/wesnoth/src/ai/contexts.cpp:1138:44: runtime error:
signed integer overflow: 153900 * 2 cannot be represented in type 'int
[6]'


Log attached.





___

File Attachments:


---
Date: Sun 23 Oct 2016 10:13:29 UTC  Name: int_overflow_UB.log  Size: 5kB   By:
matthiaskrgr



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25218] UB when TOD progresses

2016-10-23 Thread Matthias Krüger 
URL:
  

 Summary: UB when TOD progresses 
 Project: Battle for Wesnoth
Submitted by: matthiaskrgr
Submitted on: Sun 23 Oct 2016 09:39:36 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: git
Operating System: linux

___

Details:

this:
/home/matthias/vcs/github/wesnoth/src/tod_manager.hpp:182:12: runtime error:
load of value 190, which is not a valid value for type 'bool'

shows up as soon as the TOD progresses.

Full trace attached.



___

File Attachments:


---
Date: Sun 23 Oct 2016 09:39:36 UTC  Name: TOD_UB.log  Size: 2kB   By:
matthiaskrgr



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25217] unit moves on impassible terrain

2016-10-23 Thread Matthias Krüger 
URL:
  

 Summary: unit moves on impassible terrain
 Project: Battle for Wesnoth
Submitted by: matthiaskrgr
Submitted on: Sun 23 Oct 2016 07:47:59 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: git
Operating System: linux

___

Details:

in last turn, see attached replay.



___

File Attachments:


---
Date: Sun 23 Oct 2016 07:47:59 UTC  Name:
2p_—_Dark_Forecast_(Survival)_replay.gz  Size: 10kB   By: matthiaskrgr



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs

[Wesnoth-bugs] [bug #25095] wesnoth -t: "reload & exec lua code" segfaults

2016-10-23 Thread Matthias Krüger 
Follow-up Comment #2, bug #25095 (project wesnoth):

There is some lua error showing up but the game no longer crashes, so works
for me.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs