--- Log opened Tue Sep 19 00:00:01 2017
20170919 00:04:45< sevu> info server: Admin Command: type: clones
20170919 00:04:46< sevu> info server: CLONES STATUS REPORTNo clones found.
20170919 00:05:03< sevu> somewhere is a \n or a space missing
20170919 00:05:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170919 00:12:57< irker760> wesnoth: loonycyborg wesnoth:master 6a86b54d7ead / src/server/server.cpp: wesnothd: Added missing newline in message from 'clones' command https://github.com/wesnoth/wesnoth/commit/6a86b54d7ead258e345ba020c84ce00215bac68d
20170919 00:13:58< sevu> Thanks
20170919 00:14:30-!- atarocch [~atarocch@93.56.164.28] has quit [Excess Flood]
20170919 00:14:54-!- atarocch [~atarocch@93.56.164.28] has joined #wesnoth-dev
20170919 00:43:01< EliDupree> celticminstrel: How much do you know about how [do_command] works? I crashed wesnoth with it earlier today :3
20170919 00:43:37< celticminstrel> It executes any command that's valid in a saved game replay.
20170919 00:43:51< celticminstrel> How'd you crash Wesnoth with it?
20170919 00:44:06-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170919 00:44:35< EliDupree> [do_command] works correctly in ordinary events, wesnoth.game_events.on_event, and unsynced menu items. It explicitly fails with an error message in synchronize_choice() and unsynced(). It unpredictably fails or crashes in theme items and on_mouse_action.
20170919 00:45:14< EliDupree> I think it's pretty weird that it executes the command IMMEDIATELY, rather than queuing it up for after the current event/callback/etc. exits
20170919 00:45:32-!- sigurdfd [~SigurdFD@dynamic-acs-72-23-110-196.zoominternet.net] has quit []
20170919 00:46:20< EliDupree> Considering that it "generally use the same code path as if a player had ordered it" and players can't order actions in the middle of other actions
20170919 00:46:39< EliDupree> So it seems inherently susceptible to bugs if it doesn't queue it up
20170919 00:49:07< EliDupree> For instance, I think it's pretty likely that very weird/bad things would happen if I used it in the middle of combat
20170919 00:49:16< EliDupree> To, say, start another combat
20170919 00:49:30-!- sevu [~Shiki@p548551D2.dip0.t-ipconnect.de] has quit [Quit: Verlassend]
20170919 00:56:53< EliDupree> Sometimes, but not always, the crashes are accompanied by the message "caught return_to_play_side_exception, please report this bug (quitting)"
20170919 00:57:45< EliDupree> In case it matters, I was only testing with the [fire_event] version of it
20170919 00:57:59< celticminstrel> I see...
20170919 00:58:57< EliDupree> bbl
20170919 01:16:41< EliDupree> back
20170919 03:04:48-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170919 03:14:00-!- irker760 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170919 03:29:07< Necrosporus> Poor Haldric can't now even go a single step out of his camp
20170919 04:43:13-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20170919 04:55:51-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20170919 04:58:36< Necrosporus> shadowm, what about xz but with lower compression setting such as -3 or -2? xz is said to be better than bz2 in both compression ratio and compression speed depending on the settings, so perhaps you can make it work as fast as bz2 while creating smaller tarball
20170919 05:01:39< Necrosporus> not sure if it's actually true though
20170919 05:27:53-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170919 05:46:20< shadowm> I did not have enough patience to test that at the time.
20170919 06:04:08-!- Kwandulin [~Kwandulin@pD9FD50F1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170919 06:05:30-!- Netsplit *.net <-> *.split quits: nore, ChipmunkV[m]
20170919 06:06:04-!- Netsplit over, joins: nore
20170919 06:09:22-!- Greg_Boggs[m] [gregboggsm@gateway/shell/matrix.org/x-hqrdfslisrbtahmm] has quit [Ping timeout: 264 seconds]
20170919 06:09:22-!- madmax28 [madmax28ma@gateway/shell/matrix.org/x-juglzgseuomsioei] has quit [Ping timeout: 264 seconds]
20170919 06:29:38-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20170919 06:33:55< JyrkiVesterinen> Necrosporus: AFAIK, the LZMA2 algorithm (that xz uses) is good in *de*compression speed, not compression.
20170919 06:34:47< zookeeper> FYI: i _probably_ won't be offline for a few days.
20170919 06:54:04-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20170919 06:54:32-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170919 07:01:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170919 07:18:22-!- Greg_Boggs[m] [gregboggsm@gateway/shell/matrix.org/x-vyobtbkcgyullpue] has joined #wesnoth-dev
20170919 07:33:25-!- ChipmunkV[m] [chipmunkvm@gateway/shell/matrix.org/x-qjwtdatzwvkawdxa] has joined #wesnoth-dev
20170919 07:33:25-!- madmax28 [madmax28ma@gateway/shell/matrix.org/x-lghrkyblptconzjs] has joined #wesnoth-dev
20170919 07:41:05-!- vn971 [~vasya@94.158.103.15] has joined #wesnoth-dev
20170919 07:46:46< vn971> Hi guys. My client somewhy crashes often immediately after I try to use :control command. What should I do in order for this to be fix-able.
20170919 07:47:11< JyrkiVesterinen> Do you know how to capture a backtrace?
20170919 07:47:24< vn971> (It's very sad. Players often think I just escaped the game. And escape, too.)
20170919 07:47:44< vn971> JyrkiVesterinen: is it just using the debug mode?: https://wiki.wesnoth.org/DebugMode
20170919 07:47:57< vn971> if no, then no, I do not.
20170919 07:48:29< JyrkiVesterinen> Do you compile Wesnoth from source, or do you use precompiled binaries?
20170919 07:48:35< JyrkiVesterinen> And which OS do you use?
20170919 07:48:50< Necrosporus> vn971, do you start Wesnoth from console?
20170919 07:49:03< Necrosporus> This way you can see some error messages, if they are spawned
20170919 07:49:12< vn971> ArchLinux. I compile 1.13 from source and I use the repo binaries for 1.12. I guess I could compile 1.12, too.
20170919 07:49:21< vn971> Necrosporus: yes, always from console.
20170919 07:49:25< Necrosporus> vn971, you need to make a Debug build
20170919 07:49:34< Necrosporus> in cmake settings
20170919 07:50:02< vn971> Necrosporus: so debug build + console would give me stack traces or other things that could help understand this bug?
20170919 07:50:04< Necrosporus> cd build && cmake -DENABLE_DESKTOP_ENTRY=OFF -DENABLE_FRIBIDI=OFF -DENABLE_NLS=OFF -DENABLE_NOTIFICATIONS=OFF -DENABLE_SERVER=OFF -DCMAKE_BUILD_TYPE=Debug ..
20170919 07:50:09< Necrosporus> No
20170919 07:50:18< JyrkiVesterinen> Well, if it's a rare crash, using a debug build to play in multiplayer may be too laggy an experience.
20170919 07:50:26< Necrosporus> You also need to run wesnoth as gdb path/to/wesnoth
20170919 07:50:41< vn971> Necrosporus: I use scons currently. But there are instructions for debug build on the web page I've linked to, so I can handle that part.
20170919 07:50:44< JyrkiVesterinen> And even a release build backtrace would be useful if there are debugging symbols.
20170919 07:51:09< Necrosporus> I think you can get one if you make core dumped somehow
20170919 07:51:16< Necrosporus> Even if you didn't run from gdb
20170919 07:51:38< vn971> Necrosporus: gdb could be a bit hard because I always launch wesnoth in a namespace jail. But I'll try.
20170919 07:52:16< JyrkiVesterinen> Anyway, the last part: if Wesnoth crashes under GDB, it will freeze instead of disappearing. When it happens, type "bt" to the GDB prompt and upload the output to Gist or somewhere else.
20170919 07:52:29< vn971> JyrkiVesterinen: I couldn't reproduce it instantly by myself, but it happens ~100% of the time when I play real multiplayer games.
20170919 07:52:29< Necrosporus> or bt full
20170919 07:52:50< Necrosporus> vn971, give me steps to reproduce
20170919 07:52:56< vn971> JyrkiVesterinen: so if I could stand the UI for some time, I'll cope with that.
20170919 07:53:16< JyrkiVesterinen> Necrosporus: here is some advice on how to enable core dumps: https://wiki.wesnoth.org/DebuggingWesnoth
20170919 07:55:16< vn971> Necrosporus: 1. start hosting a multiplayer game. 2. wait for other people to join. 3. ??? I'm not sure what is relevant while I play. I use help and Alt+S a lot. 4. observe another player leave. I get this side then. 5. set it to idle. 6. try to give this idle side to a real player back. 7. observe the crash instantly after trying to execute :control command
20170919 07:55:53< Necrosporus> A bit complicated...
20170919 07:56:06< vn971> JyrkiVesterinen: I guess I'll just come back here if/when wesnoth crashes under GDB (if it'll work under gdb at all).
20170919 07:56:19< Necrosporus> It does work for me
20170919 07:56:28< Necrosporus> Did you get core files?
20170919 07:56:31< vn971> I'll try to repro exactly this scenario too, now.
20170919 07:56:36< Necrosporus> I already have unlimited but no core
20170919 07:56:57< vn971> Necrosporus: no, I don't think so.
20170919 08:13:05< vn971> UPD: steps to repro. 1. host a new 4p game. 2. Join other players there, so that the following scheme holds: side1=playerA, side2=playerB, side3=playerC, side4=playerB. 3. start the game. 4. end turn for player A (side1). 5. Force-kill playerB client (sides 2,4). 6. playerA will now have a dialog about orphan sides. Set both to idle. 7. as playerA type `:command 4 playerC`. 8. as playerA type `:command 2 playerC`. Observe the crash 
20170919 08:13:05< vn971> for playerA.
20170919 08:13:15< vn971> This is pretty complex, I'll try to simplify now.
20170919 08:28:08< Necrosporus> [Thread 0x7fffea928700 (LWP 1364) exited]
20170919 08:28:08< Necrosporus> [Thread 0x7fffecf48700 (LWP 1361) exited]
20170919 08:28:08< Necrosporus> Caught unspecified general exception. Terminating.
20170919 08:28:08< Necrosporus> [Thread 0x7fffee3c1700 (LWP 1360) exited]
20170919 08:28:08< Necrosporus> [Inferior 1 (process 1356) exited with code 01]
20170919 08:28:11< Necrosporus> (gdb) bt
20170919 08:28:13< Necrosporus> No stack.
20170919 08:28:21< Necrosporus> JyrkiVesterinen, it's what I get for non-debug build
20170919 08:28:47< Necrosporus> build is not stripped
20170919 08:28:53< Necrosporus> but it's Release
20170919 08:28:58< JyrkiVesterinen> Oh. At that point Wesnoth has already exited.
20170919 08:29:13< Necrosporus> Yes. It exits, not segfaults
20170919 08:29:25< Necrosporus> So the window disappear, not freezes
20170919 08:30:09< Necrosporus> What does it mean LWP 1360 ?
20170919 08:30:48< JyrkiVesterinen> Try with these lines removed: https://github.com/wesnoth/wesnoth/blob/6a86b54d7ead258e345ba020c84ce00215bac68d/src/wesnoth.cpp#L1011-L1023
20170919 08:31:38< JyrkiVesterinen> Regarding LWP, https://stackoverflow.com/a/4692838
20170919 08:34:45< Necrosporus> JyrkiVesterinen, but it's windows specific
20170919 08:34:50< Necrosporus> I have GNU/Linux
20170919 08:35:01< JyrkiVesterinen> Hmm. With a closer look, it looks like you're actually getting into this exception handler: https://github.com/wesnoth/wesnoth/blob/6a86b54d7ead258e345ba020c84ce00215bac68d/src/wesnoth.cpp#L1121
20170919 08:35:05< JyrkiVesterinen> Try removing it.
20170919 08:35:33< JyrkiVesterinen> (The code I linked is used in all platforms *except* Windows. But it doesn't matter here, you don't need to remove it after all.)
20170919 08:35:34< Necrosporus> Is it 1.12?
20170919 08:36:45< Necrosporus> I got crash only for 1.12 for now, not sure if it happens with 1.13
20170919 08:37:29< JyrkiVesterinen> In 1.12 the same exception handler is in game.cpp: https://github.com/wesnoth/wesnoth/blob/01062617a10cd4289fc3b3bebe4c76910e5c5ee8/src/game.cpp#L870
20170919 08:38:10 * JyrkiVesterinen wonders where we have code that throws something other than a std::exception 
20170919 08:45:06< Necrosporus> Didn't happen with 1.13
20170919 08:45:33< Necrosporus> But of course it doesn't mean that same problem doesnt exist
20170919 08:45:39< Necrosporus> it could just trigger differently
20170919 08:47:22< JyrkiVesterinen> And again, it's also possible that the bug has been fixed or it has otherwise disappeared in 1.13. There are a lot of changes between them.
20170919 08:49:09< Necrosporus> Yes, that too
20170919 08:49:22< Necrosporus> So it is better to find what it was
20170919 08:52:43< vn971> we've decided I'll try to build wesnoth-1.12 from source with the lines you say removed. I'm not sure I'll be able to launch gdb though.
20170919 08:52:51< vn971> so which lines should I remove?
20170919 08:53:28< JyrkiVesterinen> 1116-1122 (for 1.12 branch HEAD).
20170919 08:53:32< vn971> the first link, wesnoth.cpp L1011-L1023 ?
20170919 08:53:40< vn971> JyrkiVesterinen: OK, cool
20170919 08:55:27< vn971> should I build a "debug" build or normal?
20170919 08:55:44< JyrkiVesterinen> Debug, if you can live with the slowness.
20170919 08:56:16-!- sevu [~Shiki@p548542F5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170919 08:57:18< sevu> If wesnoth crashes and you didn't start it with gdb, you can access the core anyways
20170919 08:57:25< sevu> coredumpctl list wesnoth
20170919 08:57:41< sevu> and coredumpctl gdb <PID from the list>
20170919 08:58:00< vn971> sevu: I'm using a jail (firejail), which probably somehow suppresses core dumps. IDK, not sure. Will try.
20170919 08:58:35< Necrosporus> vn971, also it's game.cpp I guess
20170919 08:59:11< vn971> Necrosporus: game.cpp 1116-1122 (for 1.12 branch HEAD), OK.
20170919 08:59:52< JyrkiVesterinen> I was looking at a wrong branch, I meant lines 865-871.
20170919 09:00:06< JyrkiVesterinen> And indeed, game.cpp. Wesnoth.cpp doesn't exist in 1.12.
20170919 09:03:11-!- sevu [~Shiki@p548542F5.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20170919 09:16:36< vn971> is it enough to assign myself an "Achievement Unlocked" thing?:D  Like "Found an addon-less bug/crash in stable wesnoth, close to the end of this version live cycle" ?:)
20170919 09:22:24< vn971> // I presume it's /src/game.cpp, not /src/server/game.cpp
20170919 09:22:59< JyrkiVesterinen> Yes, I mean src/game.cpp.
20170919 09:44:53< Necrosporus> I have a crash in 1.12 too
20170919 09:45:00< Necrosporus> Not sure if I should file a bug about it
20170919 09:45:25< JyrkiVesterinen> Do you have a backtrace?
20170919 09:47:36< Necrosporus> It's unspecified general exception too
20170919 09:47:43< Necrosporus> might be related to what  vn971 got
20170919 09:48:03< vn971> under a similar scenario?
20170919 09:48:04< Necrosporus> easy to reproduce
20170919 09:48:28< Necrosporus> Have you build wesnoth with lines removed (or commented)?
20170919 09:57:46-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20170919 10:04:50< vn971> hmm.( I've compiled with `scons prefsdir=.local/share/$_gitname/git build=debug prefix=/opt/wesnoth-$pkgver-debug debug=yes`
20170919 10:04:50< vn971> but gdb says:  Reading symbols from /opt/wesnoth-1.12.6.42.g01062617a1-debug/bin/wesnoth...(no debugging symbols found)...done.
20170919 10:08:04< vn971> anyway, will try to launch and see what happens.
20170919 10:18:54< vn971> the freshly compiled wesnoth just died and that's it.
20170919 10:19:17< vn971> ah no, sorry. Wrong terminal (I have 3 wesnoths open)
20170919 10:19:31< vn971> this is the real exception: > terminate called after throwing an instance of 'end_turn_exception'
20170919 10:35:08-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20170919 10:35:31< vn971> JyrkiVesterinen: check out room logs, if you have them?
20170919 10:35:48< JyrkiVesterinen> They are public. Anyone can view them.
20170919 10:35:55< JyrkiVesterinen> And yes, I just read them.
20170919 10:36:50< JyrkiVesterinen> How did you get the "terminate called" message? Is it from GDB?
20170919 10:38:20< JyrkiVesterinen> Merely knowing which exception was thrown isn't that useful. It would be much better to have the full backtrace.
20170919 10:39:19< vn971> JyrkiVesterinen: this is what I've got by just launching `wesnoth --debug`. Without gdb, that is.
20170919 10:40:36< vn971> JyrkiVesterinen: gdb doesn't seem to work inside my jail (firejail). So I don't know how to launch gdb.:(
20170919 10:41:11< JyrkiVesterinen> Hmm. That is a problem, because the exception name alone isn't much info to work with.
20170919 10:41:27< JyrkiVesterinen> And I guess your jail doesn't allow generation of core dumps, either?
20170919 10:41:49< vn971> JyrkiVesterinen: I tried a couple of times and it never worked.(
20170919 10:43:05< JyrkiVesterinen> Hmm. Then I guess we (developers) need to reproduce the problem ourselves to investigate it.
20170919 10:43:14< vn971> JyrkiVesterinen: also, gdb says it can't find debugging symbols. That's wrong, is it? I've compiled with scons (see above).
20170919 10:43:25< JyrkiVesterinen> Did you just follow these steps you posted earlier?
20170919 10:43:26< JyrkiVesterinen> 20170919 08:13:05< vn971> UPD: steps to repro. 1. host a new 4p game. 2. Join other players there, so that the following scheme holds: side1=playerA, side2=playerB, side3=playerC, side4=playerB. 3. start the game. 4. end turn for player A (side1). 5. Force-kill playerB client (sides 2,4). 6. playerA will now have a dialog about orphan sides. Set both to idle. 7. as playerA type `:command 4 playerC`. 8. as playerA type 
20170919 10:43:26< JyrkiVesterinen> `:command 2 playerC`. Observe the crash 
20170919 10:43:42< vn971> JyrkiVesterinen: yes, exactly them.
20170919 10:44:04< JyrkiVesterinen> Indeed, GDB should be able to find the symbols if you make a debug build. That's how I make my debug builds, and they are very much debuggable.
20170919 10:44:31< JyrkiVesterinen> (Too bad that linking takes forever and completely kills the performance of my PC while it's in progress...)
20170919 10:45:09< vn971> JyrkiVesterinen: could "debug=yes" argument spoil the previous "build=debug" ?
20170919 10:45:25< JyrkiVesterinen> Maybe. I use only "build=debug".
20170919 10:47:32< vn971> JyrkiVesterinen: I'll rebuild.
20170919 11:04:02-!- Kwandulin [~Kwandulin@pD9FD50F1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170919 11:49:17-!- Kwandulin [~Kwandulin@pD9FD50F1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170919 12:07:58-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170919 12:09:48-!- sevu [~Shiki@p548542F5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170919 12:10:13< vultraz> *groans* tfw you sleep for 14 hours straight
20170919 12:10:37< JyrkiVesterinen> I assume it's a sleepy face? :P
20170919 12:11:40< vultraz> Yes
20170919 12:11:50< vultraz> Sorry no release last night
20170919 12:12:21< JyrkiVesterinen> No need to apologize. You're a volunteer after all.
20170919 12:14:31< DeFender1031> vultraz, jetlag'll do that.
20170919 12:16:34< vultraz> And lack of much sleep over a 50 hour period
20170919 12:16:52< DeFender1031> I actually slept for nearly all of last friday and saturday straight as a result of the combination of what I have just now decided to dub "jetless jetlag" (aka, when I decide that my schedule has shifted too late and I stay up all night to reset it) and getting heat stroke from walking across the city in blazing midday heat.
20170919 12:17:17< DeFender1031> (Got up for a couple hours here and there for meals and bathroom breaks)
20170919 12:17:46 * DeFender1031 is super lucky he has both a flexible job and a supportive wife...
20170919 12:20:39< sevu> and you have warm weather. It got so cold the last days here
20170919 12:20:50< vultraz> Like, here's the thing. I didn't get a full night's sleep Friday. Enough, though. Then running like crazy Saturday. Bout 6 hours sleep then. Lot of traveling Sunday. Few short (4 or so) uncomfortable hours on the flight I was talking to you guys from. Arrive here Sunday. Up till 2 am. 6 hours sleep. Running around for the funeral. Combine that with the jet lag and Bam.
20170919 12:23:42< DeFender1031> sevu, you in the southern hemisphere or just somewhere very cold?
20170919 12:23:50< DeFender1031> sevu, also, I prefer the cold to the heat.
20170919 12:24:52< DeFender1031> vultraz, yeah, that'd do it.
20170919 12:27:18< sevu> In europe, it's just becoming autumn. I'm very likely to feel cold. Though, to hot is not the best either
20170919 12:28:17< JyrkiVesterinen> Even worse here in northern Europe. About 9 degrees Celcius now.
20170919 12:30:59< sevu> seem to be still 18 degrees here
20170919 12:32:44< DeFender1031> There's two seasons here: Hell and wet.
20170919 12:32:57< DeFender1031> Okay, granted, we get about a week each of autumn and spring.
20170919 13:14:18-!- Kwandulin [~Kwandulin@pD9FD50F1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170919 13:40:54-!- vn971 [~vasya@94.158.103.15] has quit [Quit: Leaving.]
20170919 14:25:35-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20170919 14:27:18-!- vn971 [~vasya@94.158.103.15] has joined #wesnoth-dev
20170919 15:07:38-!- Kwandulin [~Kwandulin@pD9FD50F1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170919 15:19:18-!- sevu [~Shiki@p548542F5.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
20170919 15:27:45-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170919 15:30:34-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170919 15:48:20-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20170919 16:21:36< vn971> OK, I've got it. wesnoth branch 1.12, with those lines commented out, hang up under gdb.
20170919 16:22:35< vn971> https://gist.github.com/vn971/907d3bcc633c3308975d675e38d4f2a5
20170919 16:22:37< vn971> thoughts?
20170919 16:23:45< JyrkiVesterinen> Enter "bt" and upload the output.
20170919 16:27:14< vn971> gdb bt output: https://gist.github.com/vn971/2c447b3537f2c7fdc0612b9be51fcf85
20170919 16:29:52< JyrkiVesterinen> All right. It's this exception: https://github.com/wesnoth/wesnoth/blob/01062617a10cd4289fc3b3bebe4c76910e5c5ee8/src/menu_events.cpp#L3298-L3309
20170919 16:30:01< vn971> // offtopic. About the previous time I tried to build a debug version and it had no symbols. I did it with `makepkg` (ArchLinux default thing), and it strips out debug symbols by default. I had to configure it NOT to strip the symbols, and then everything was good.
20170919 16:30:37< JyrkiVesterinen> Quite strange. This is NOT an error condition. It isn't supposed to crash the game.
20170919 16:30:51< JyrkiVesterinen> I'll investigate more later.
20170919 16:33:09< Necrosporus> But it throws exception
20170919 16:33:18< Necrosporus> Seems like it's not caught when it should?
20170919 16:36:50< JyrkiVesterinen> Yes, may be.
20170919 16:55:37< Necrosporus> So, backtrace is read from bottom to top. In this case, we get to #6 which indicates the place in code, and #5 which says that exception got to library, then it seems that it have decided to terminate the program
20170919 17:05:14-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev
20170919 17:28:50-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170919 17:29:03< vultraz> Tfw you fall BACK to sleep and sleep some more!
20170919 17:29:30< vultraz> Mein gott
20170919 17:29:55< Kwandulin> Jaaa
20170919 17:40:03-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170919 17:45:25< JyrkiVesterinen> Necrosporus, vn971: All right, I found it.
20170919 17:45:37< JyrkiVesterinen> Both cases have been refactored to no longer use exceptions.
20170919 17:45:46< JyrkiVesterinen> That's why the crashes are impossible on 1.13.
20170919 17:45:52< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/commit/5732ed504dbf585c2dad0a8cd16f27755be40c35#diff-c13e8bd6a835ac26a08a5d2cbc5afee9
20170919 17:45:58< JyrkiVesterinen> https://github.com/wesnoth/wesnoth/commit/b60809e623d89d3667009330cf50e9b96e0aeb0d
20170919 17:46:30< JyrkiVesterinen> There isn't any need for us to do anything here, the crashes are already gone in 1.13 and another 1.12 release is very unlikely.
20170919 17:48:41-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:9d29:97ee:abb4:f171] has joined #wesnoth-dev
20170919 17:52:01< vn971> Not using exceptions is cool! (Couldn't resist, sorry.)
20170919 17:55:12< vn971> BTW, wesnoth is mocking me.  "That's already " << newplayer_name << "'s side, silly."
20170919 17:55:50< vultraz> Heeheehee
20170919 17:57:12< vn971> time to make my first "code" contribution and change this. Though in the commit list it would look kinda... silly:D
20170919 17:58:57-!- Kwandulin [~Kwandulin@pD9FD50F1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170919 18:18:33-!- Kwandulin [~Kwandulin@pD9FD50F1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170919 18:19:16-!- Bhoren [~Bhoren_wh@2a01:e0a:c:2150:9d29:97ee:abb4:f171] has quit [Quit: Leaving]
20170919 18:22:04-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170919 18:22:18-!- sevu [~Shiki@p548542F5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170919 18:22:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170919 18:29:00-!- gfgtdf [~chatzilla@x4e369f5d.dyn.telefonica.de] has joined #wesnoth-dev
20170919 18:33:46< gfgtdf> 20170918 17:33:44< EliDupree> So... [do_command] makes the command happen immediately, rather than waiting for the end of the ongoing event/callback/etc? When IS it safe to call?
20170919 18:34:15< gfgtdf> EliDupree: it's minaly intended for 1) unsyced menu_items, 2) Ai code? 3) select events.
20170919 18:34:22< EliDupree> I learned more about it later in the logs, if you only read that far so far
20170919 18:35:08< EliDupree> It's particularly unfortunate that it crashes in on_mouse_action – not working in theme items is more understandable
20170919 18:36:06< gfgtdf> ye i agrtee that it shoudl work on 'on_mouse_action' did you also test this after my commit which changes on_mouse_action  ?
20170919 18:36:15< EliDupree> nope
20170919 18:36:26-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20170919 18:36:57< gfgtdf> EliDupree: then i'll wait until you did... whihc will probably happen when 1.13.0 comes aout, though if you are using windows you cna also downlaod 1.13.8+dev from jenkins
20170919 18:37:20< EliDupree> got it
20170919 18:37:46< gfgtdf> when 1.13.9 comes out i meant*
20170919 18:38:13-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev
20170919 18:38:40< gfgtdf> vultraz: why was 1.13.9 delayed? are you waiting for somethign in particular ?
20170919 18:38:57< vultraz> I've been traveling
20170919 18:39:05< vultraz> And then I had a funeral to attend yesterday
20170919 18:39:11< gfgtdf> ok
20170919 18:40:07< gfgtdf> 20170919 10:19:31< vn971> this is the real exception: > terminate called after throwing an instance of 'end_turn_exception'
20170919 18:40:40< gfgtdf> vn971: this exception was afaik removed in 1.13, if you are using 1.12 please check whetrh it happen on 1.13 too.
20170919 18:41:34< JyrkiVesterinen> gfgtdf: I already linked the commit where the exception was removed.
20170919 18:42:03< gfgtdf> JyrkiVesterinen: ah ok, i just didn't read the log up to that point yet.
20170919 18:48:39< vn971> gfgtdf: hi. The exception was from the 1.12 branch. It was later investigated fully by using gdb.
20170919 18:50:19< gfgtdf> hmm ye, the point is that we don't intend to make another 1.12 release unless there are security issues.
20170919 18:59:20< EliDupree> ...And although I said [do_command] was safe in on_mouse_move(), it only usually is – on_mouse_move() can occasionally be triggered at times when it's not safe, although I'm not 100% sure what those situations are.
20170919 19:01:36-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20170919 19:03:00< vn971> hmm, wtf is happening. I lost control of what's a bug and what's not. https://pointsgame.net/vn971/temp/2017.09.19_22:02:47_9d6ae90.png
20170919 19:03:50< vn971> how can this be happening? Again, tag 1.12.6 (stable). When I hover the mouse above any of those "red" units, I see "green" flag in the right status window.
20170919 19:04:28< zookeeper> well... what did you do? :x
20170919 19:04:33< vn971> like this one (flag): https://pointsgame.net/vn971/temp/2017.09.19_22:04:22_8034d20.png
20170919 19:04:56< vn971> didn't do anything! Just joined the game "dimaga beach" online now.
20170919 19:05:10< zookeeper> the flag is probably green for the same reason the units aren't red; TC is broken, and the flag TC is green (not magenta)
20170919 19:05:30< vn971> currently online with Gegna and Druid playing.
20170919 19:06:22< zookeeper> well, i for one get some warning about needing to install some color modification ageless thing
20170919 19:06:47< zookeeper> so chances seem pretty high that whatever the problem is, it's an add-on problem.
20170919 19:06:54< vn971> ah.
20170919 19:07:11< zookeeper> you don't see that warning?
20170919 19:07:33< vn971> but it's still counter-intuitive. Why would we let an add-on highlight a unit in one color but show the flag in the right status window in another.
20170919 19:07:55< vn971> zookeeper: nope. In fact, I never see wesnoth add-on warnings. I either can't join a game, or there's no warning.
20170919 19:08:25< zookeeper> a big <Lua WARNING> right there at the top of the chatlog?
20170919 19:08:37< zookeeper> rather weird if it's possible to _not_ see those
20170919 19:09:14< vn971> zookeeper: never saw such thing.
20170919 19:10:14< zookeeper> well, okay, it doesn't actually show in the chatlog. so if you have you wesnoth set to display like 3 chat lines then i guess it would disappear quickly...
20170919 19:10:48< vn971> zookeeper: I _never_ saw this chat thing. Also, opening the "chat history" shows nothing.
20170919 19:11:15< vn971> ( https://pointsgame.net/vn971/temp/2017.09.19_22:11:06_6acd8d6.png )
20170919 19:11:44< zookeeper> huh, so you don't see even the <XP Mod version bla bla bla message
20170919 19:11:53< zookeeper> i wonder what's up with that.
20170919 19:12:16< zookeeper> anyway, it sure looks like it's just some bit of add-on content screwing up TC there. and as said, if TC for a unit/side breaks, you should see a magenta unit with a green flag.
20170919 19:13:47< gfgtdf> EliDupree: yes you ahve to be casutious when using on_mouse_motion, for example if you used [do_command] from on_mouse_motion while it'S curretnty executing another sycned action i wouldnt be surpised if it won't work
20170919 19:14:57< vn971> "XP Mod version ..." I do see. It just disappeared.
20170919 19:15:20< zookeeper> have you got chat aging set to a low value in advanced preferences, or something?
20170919 19:15:37< vn971> zookeeper: 7 minutes
20170919 19:16:37-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170919 19:17:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170919 19:17:36< EliDupree> gfgtdf: There's not necessarily any way I can protect from that. What if another add-on runs an event where they call [delay]? There's no way EoHS events can distinguish between that situation and the mouse just moving while nothing's going on
20170919 19:17:38< Ravana_> color mod defines some custom colors, whose definitions are also duplicated in ageless
20170919 19:18:44< Ravana_> warning is displayed if player has neither of those addons, and custom color is selected
20170919 19:18:57< gfgtdf> EliDupree: you could probably use wesnoth.curent.synced_state 
20170919 19:19:37< EliDupree> I thought of that, but the event could use wesnoth.unsynced(), or it could be a unsynced menu item or other callback in the first place
20170919 19:20:12< vn971> Ravana_: I just don't understand why wesnoth allows this at all. I mean, field color and "hover" color just mismatch. Also, magenta looks A LOT like red. Guess which of these units are red and which magenta? https://pointsgame.net/vn971/temp/2017.09.19_22:19:03_4fb87a0.png
20170919 19:20:59< gfgtdf> hmm 
20170919 19:21:14< Ravana_> I am not really happy that wesnoth requires all players have the color definitions in their local files in the first place
20170919 19:21:20< gfgtdf> you could check the lau call stach via luas debug function ..., 
20170919 19:21:26< Ravana_> its 4 lines of text to send
20170919 19:21:34< EliDupree> *facepalm*
20170919 19:21:46< vn971> though I don't mind that as much as obvious bugs, so I don't insist in explaining/more work if the underlying arguments are verbose and non very obvious.
20170919 19:21:58< gfgtdf> i know i did that in one of my addons (1.10 or 1.12), but i agree that it's not that prett solution
20170919 19:22:06< EliDupree> gfgtdf: Are there significant obstacles to making do_command queue up the commands and execute them in a consistent outer context? That seems much safer
20170919 19:23:22< gfgtdf> EliDupree: well i'd need to add auch a queue and then callen the function in a consistent outer context.. unknown bugs may appear, i didn'T really though about it deeply yet
20170919 19:24:20< EliDupree> I'm thinking, the code already has a lot of restrictions on when the user is allowed to do actions, so that they can't, say, move a unit in the middle of a combat or a theme item callback or whatever
20170919 19:24:48< gfgtdf> by user you mean wml developer ?
20170919 19:24:56< EliDupree> Do_command says on the wiki that it generally follows the same code path as the user doing the same action, so it would make sense – and naturally be safer – if it could only activate at the times a user could activate things
20170919 19:25:01< EliDupree> no, the player
20170919 19:26:21< EliDupree> Like, there used to be actual bugs (way back somewhere around 1.0 or maybe before, but anyway) where an ordinary player could take an action in the middle of combat and crash the game or make weird things happen, I can't remember the details
20170919 19:27:27< EliDupree> Having do_command execute the command immediately would inherently open up all those bugs again
20170919 19:27:59< EliDupree> Oh yeah, it was when set_menu_item was added
20170919 19:28:12< zookeeper> vn971, why wesnoth allows... what, exactly? for an add-on to have broken TC? :p
20170919 19:28:20< EliDupree> It wasn't protected against using the menu items during combat, causing various bugs. But now it is
20170919 19:28:45< vn971> zookeeper: I don't know what TC is, but yes. :DD
20170919 19:28:51< zookeeper> team color
20170919 19:29:04< gfgtdf> hmm
20170919 19:29:07< vn971> zookeeper: ok. Yes. Why allow that?
20170919 19:29:30< vn971> or rather, I don't insist. I just don't get it.
20170919 19:29:48< zookeeper> vn971, why allow an add-on to have broken TC? well that's like asking why allow add-ons to have broken anything.
20170919 19:30:14< vn971> zookeeper: exactly. I mean, why allow changing colors at all?
20170919 19:30:44< zookeeper> i don't know, as i don't even know what the add-on is trying to do and what causes the problem
20170919 19:30:48< zookeeper> does anyone? :P
20170919 19:31:54< zookeeper> well, maybe Ravana_ does
20170919 19:32:34< Ravana_> https://forums.wesnoth.org/viewtopic.php?f=12&t=42818
20170919 19:33:04< vn971> zookeeper: I do not mean any specific add-on of course, that would be like "Halting problem". Rather I'm surprised wesnoth allows changing colors at all.
20170919 19:34:40< zookeeper> Ravana_, oh, so, is this right: the scenario uses the team color mod add-on, which adds new colors, but when someone like me joins and doesn't have team color mod, i don't have those color definitions, and thus units show up without TC because they're to be colored with a color i don't have the definition of?
20170919 19:34:52< Ravana_> yes
20170919 19:34:55< zookeeper> got it
20170919 19:35:10-!- Kwandulin [~Kwandulin@pD9FD50F1.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
20170919 19:35:13< gfgtdf> EliDupree: for the do_command wuee thing, i think that'S rather (complicated) so it'd be best if you mae a featurereuest for it
20170919 19:35:19< EliDupree> ah
20170919 19:36:05< zookeeper> vn971, so it's not that wesnoth allows changing the standard colors (or if it does, it's apparently not relevant here), it just allows adding new ones.
20170919 19:36:35< zookeeper> and there we have a scenario which only works correctly if you have the custom colors that another add-on provides.
20170919 19:37:15-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170919 19:37:58< vn971> OK, I guess there might be scenarios when somebody would want to define custom colors. (I would personally rather never do that, but well, maybe it has its use case.)
20170919 19:38:26< vn971> in this exact case it would mean a dependency not specified explicitly. I guess..
20170919 19:38:37< Ravana_> I don't think it is intentionally supported
20170919 19:39:45< zookeeper> it also feels like the scenario could provide fallbacks to the standard colors if the user doesn't have the color mod installed.
20170919 19:40:32< zookeeper> _if_ that's the case then the author is just lazy
20170919 19:40:36< Ravana_> since I included same color definitions with ageless, I don't consider that real problem. My target audience has ageless
20170919 19:53:49< gfgtdf> i think this is a problem, my point is that it'S afaik possibel to use these colors evne you you don't have the correponding [modification] active to 1.14s 'download addons on demand' won't catch it
20170919 19:54:55< Ravana_> yes, it doesn't need to be active, just loaded
20170919 20:09:46< zookeeper> in 1.14 we could of course enfo... i mean very strongly recommend that people more vigorously #ifdef stuff in MP add-ons to prevent leakage.
20170919 20:09:55< zookeeper> since now it's actually possible.
20170919 20:10:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170919 20:10:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170919 20:19:41< EliDupree> gfgtdf: Feature request posted! https://github.com/wesnoth/wesnoth/issues/2018
20170919 20:19:55< gfgtdf> ok thx
20170919 20:20:37-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 255 seconds]
20170919 20:35:09< gfgtdf> EliDupree: ok added some thought to it
20170919 20:35:17< gfgtdf> thoughts*
20170919 20:41:24< Ravana_> after having tried to compile wesnoth about every 6 months for last few years, I finally decided to ask for help https://forums.wesnoth.org/viewtopic.php?f=5&t=46832
20170919 20:43:01< gfgtdf> Ravana_: hmm maybe you shoudl add which OS exactly do you use.
20170919 20:43:22< Ravana_> Linux Mint 18.1 Serena
20170919 20:43:35< gfgtdf> ah right it in the title
20170919 20:49:47< gfgtdf> Ravana_: i ahve to say i don't now much about inux
20170919 20:50:51< gfgtdf> Ravana_: but there are quite some people here who do i think
20170919 20:51:14< gfgtdf> Ravana_: maybe you coudl even ask one of you linux packages
20170919 20:51:18< Ravana_> on discord I was told to upgrade to 18.2
20170919 20:51:59< vultraz> Did that work?
20170919 21:00:55-!- Rhonda [~rhonda@wesnoth/developer/rhonda] has quit [Remote host closed the connection]
20170919 21:04:32< vn971> from the logs it seems that you just have to install some libraries. Do you normally use "aptitude" to download/install packages on Linux Mint?
20170919 21:04:44< vn971> (Or is it apt-get, or maybe GUI.. I don't know.)
20170919 21:07:02< vn971> OK, I have to go to sleep. AFK.
20170919 21:07:50< Ravana_> I usually write apt
20170919 21:13:06< vn971> Ravana_: try this at first then:  apt-get build-dep wesnoth-1.12
20170919 21:13:28< vn971> it's from the official documentation ( https://wiki.wesnoth.org/Compilingwesnoth ). Re-run scons, let's see what it'll write.
20170919 21:16:04< sevu> apt-get build dep wesnoth-1.13 worked for me, after adding one of the ppas found here https://wiki.wesnoth.org/WesnothBinariesLinux#Repos_with_newer_vesions
20170919 21:17:02-!- Rhonda [~rhonda@anguilla.debian.or.at] has joined #wesnoth-dev
20170919 21:17:21< sevu> on 18.1, so it's possible without reinstall
20170919 21:17:39< Ravana_> E: Unable to find a source package for wesnoth-1.12
20170919 21:18:36< sevu> edit the files in /etc/apt/sources.d or /etc/apt/sources - add for each line the same with deb-src
20170919 21:24:23< vn971> // outdated dependencies and the will to compile from source (to help development) is the reason I've migrated to Arch after several years of ubuntu/xubuntu. Not that it's super-relevant to the discussion, just made me remember.)
20170919 21:49:28-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20170919 21:54:25-!- sevu [~Shiki@p548542F5.dip0.t-ipconnect.de] has quit [Quit: Verlassend]
20170919 22:00:36-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170919 22:31:10-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170919 23:19:39-!- gfgtdf [~chatzilla@x4e369f5d.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 55.0.3/20170824053622]]
20170919 23:55:39-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
--- Log closed Wed Sep 20 00:00:02 2017