--- Log opened Thu Jun 07 00:00:57 2018 20180607 00:08:05-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180607 00:23:37-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180607 00:35:11< celticminstrel> Gasp, GitHub added something good immediately after announcing that they're being acquired. >_> 20180607 00:35:20< celticminstrel> Comment edit history! 20180607 00:35:54<+discordbot5> That was added like 2 days before the announcement. 20180607 00:36:03< celticminstrel> Really? I never saw it until today. 20180607 00:36:11<+discordbot5> Yeah 20180607 00:36:11< celticminstrel> Now you can view every revision of my comments where I correct spelling errors, add entire paragraphs, or whatever. 20180607 00:36:59< celticminstrel> I was definitely using GitHub over the weekend too... maybe I just never edited a comment. 20180607 00:38:05-!- gfgt [~androirc@134.76.63.8] has quit [Ping timeout: 240 seconds] 20180607 01:04:46< mattsc> I noticed that I could suddenly see what you had edited earlier today only as well. 20180607 01:05:41< mattsc> celticminstrel: isn’t the WML tag metatable deprecated? I removed all the deprecated Lua code a few weeks ago. 20180607 01:06:05< mattsc> In other words, it’s not used in ai_helper. 20180607 01:06:20< mattsc> (but I understand now what you meant) 20180607 01:06:27< celticminstrel> mattsc: No, it's renamed. 20180607 01:06:39< celticminstrel> wml.tag is the WML tag metatable. 20180607 01:06:48< mattsc> Oh, itr’s the actions table ... 20180607 01:06:55< celticminstrel> ? 20180607 01:08:42< mattsc> Never mind. Just ignore me. I’m too tired to think at the moment. 20180607 01:08:50-!- gfgtdf [~gfgtdf@134.76.63.8] has quit [Quit: Leaving] 20180607 01:44:53-!- EliDupree [~quassel@2604:a880:400:d0::9bb:2001] has quit [Quit: No Ping reply in 180 seconds.] 20180607 01:45:59-!- EliDupree [~quassel@2604:a880:400:d0::9bb:2001] has joined #wesnoth-dev 20180607 02:15:43< irker268> wesnoth/wesnoth:master Nils Kneuper c9b7d5b22f updated Italian translation AppVeyor: All builds passed 20180607 02:45:46-!- fabi_ [~fabi@200116b82b97b9007cd44bc765eeae54.dip.versatel-1u1.de] has joined #wesnoth-dev 20180607 02:46:02-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Ping timeout: 265 seconds] 20180607 03:05:43< mattsc> celticminstrel: Is the following syntax okay? 20180607 03:05:44< mattsc> wesnoth.get_units { wml.tag["not"] { status = "petrified" }, wml.tag["and"](filter) } 20180607 03:06:14< mattsc> It works, I did check that much, just wondering if there’s anything undesirable about it. 20180607 03:07:31< mattsc> I personally like the bracket notation better, but I don’t really care that much. 20180607 03:08:46< mattsc> wesnoth.get_units { { "not", { status = "petrified" } }, { "and", filter } } 20180607 03:09:02< mattsc> I don’t know, the latter looks “nicer” to me. 20180607 03:12:43< mattsc> Yeah, I think I’ll go with the bracket notation, esp. since it is also faster. 20180607 03:13:04< mattsc> Even though, as gfgtdf says, that won’t really make a difference in practice in this case. 20180607 03:57:41< celticminstrel> mattsc: Yes it's fine. 20180607 03:57:50< celticminstrel> Personally I prefer the wml.tag notation. 20180607 03:58:06< celticminstrel> Though wml.tag itself is kinda long but whatever. 20180607 03:58:53< celticminstrel> The reason I don't like the second version is because there's an extra nested set of brackets, which IMO doesn't look nice if you break it into multiple lines, because then you have a line consisting of just }}, 20180607 03:59:10< mattsc> celticminstrel: I’ve used the wml.tag notation for other things (because I preferred it for them), but I guess in this specific case I don’t. 20180607 04:00:13< mattsc> I actually think that the closing }} is just like having an ‘end’ for other things, which often gets it’s on line too. 20180607 04:00:19< mattsc> *its 20180607 04:00:47< mattsc> So I don’t mind it, and actually kind of like to for denoting blocks and indenting etc. 20180607 04:01:18< mattsc> s/on/own (3 lines up) 20180607 04:01:32< mattsc> I really need to increase the font for my irc client! 20180607 04:01:42< mattsc> font size 20180607 04:02:24< celticminstrel> I think I can sorta agree that the difference matters less in this one-liner case, though personally I'd still choose 1ml.tag just for consistency. 20180607 04:03:28< mattsc> Well, currently the bracket notation is much more used in the MAIs and AI helper functions. 20180607 04:03:46< mattsc> If you ever update all of that, feel free to change these lines also. :P 20180607 04:14:11-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20180607 04:24:14-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180607 04:33:10< irker268> wesnoth/wesnoth:1.14 Nils Kneuper 0f43f82a3b updated Italian translation AppVeyor: All builds passed 20180607 05:34:24-!- gallaecio [~quassel@162.red-81-39-199.dynamicip.rima-tde.net] has joined #wesnoth-dev 20180607 06:06:42<+discordbot5> @Vultraz I'm having trouble reproducing the crash with --nocache. 20180607 06:06:52<+discordbot5> 😦 20180607 06:07:18<+discordbot5> well, to be fair, it only happens to be on release builds... and I don't think asan can run on release builds 20180607 06:07:24<+discordbot5> so I guess I'm out of options here 20180607 06:07:36<+discordbot5> I'm running a debug build on gdb. 20180607 06:07:43<+discordbot5> I was before as well. 20180607 06:08:21<+discordbot5> when I run debug build the crash doesn't happen 20180607 06:08:44<+discordbot5> [race condition suspicion intensifies] 20180607 06:09:41<+discordbot5> Nothing's happening without --nocache either. 20180607 06:11:20<+discordbot5> 😦 20180607 06:14:39<+discordbot5> how is it i can consistently repro something here 20180607 06:14:42<+discordbot5> but not yu 20180607 06:14:45<+discordbot5> you 20180607 06:15:03<+discordbot5> can you maybe see if it hapens on a plain release build? 20180607 06:15:07<+discordbot5> It was pretty consistent for me last night as long as I chose the right campaign. 20180607 06:15:11<+discordbot5> With or without asan? 20180607 06:15:22<+discordbot5> I think it should still work with -O3, the output will just be significantly less useful. 20180607 06:15:46<+discordbot5> OTOH asan does introduce timing artifacts that would otherwise not be present in a normal release (or debug) build. 20180607 06:16:29<+discordbot5> the one you got last night was a different crash, I think 20180607 06:16:33<+discordbot5> actually, I'm certain 20180607 06:17:00<+discordbot5> if asan can work on release builds it can't hurt to try 20180607 06:19:16<+discordbot5> the crash im seeing always happens at startup 20180607 06:19:23<+discordbot5> during the loading screen 20180607 06:19:31<+discordbot5> or when ging to Local Game 20180607 06:19:33<+discordbot5> during the loding screen 20180607 06:19:50<+discordbot5> and always during Reading Files and Creating Cache 20180607 06:20:07<+discordbot5> always 20180607 06:23:04<+discordbot5> is this with the current 1.14 git revision? 20180607 06:23:10<+discordbot5> no 20180607 06:23:21<+discordbot5> a branch of mine based on master 20180607 06:23:49<+discordbot5> ah, ok. was wondering why nothing was happening when I tried. 20180607 06:24:31<+discordbot5> https://github.com/vultraz/wesnoth/tree/gui2_widget_ptr_init_refactor 20180607 06:33:40<+discordbot5> @Vultraz Still nothing with -O3 + asan. 20180607 06:33:51<+discordbot5> I give up 😦 20180607 06:33:52<+discordbot5> Both with and without --nocache. 20180607 06:34:30<+discordbot5> Have you tried retracing your steps towards the current code and figuring out what can possibly go wrong with each change? 20180607 06:41:06<+discordbot5> 🙄 20180607 06:41:09<+discordbot5> it's all one big change 20180607 06:41:15<+discordbot5> so I can't really 20180607 06:41:15<+discordbot5> >_> 20180607 06:43:28<+discordbot5> I've read over the diff and I just can't see what would be wrong 20180607 06:44:27<+discordbot5> the only thing i can think of is that somehow the widget is destroyed too early 20180607 06:44:36<+discordbot5> but I don't figure out WHERE that could be happening 20180607 06:44:42<+discordbot5> or why it's happening here 20180607 06:45:20<+discordbot5> Because it seems to be timing related, there are likely multiple threads involved. 20180607 06:46:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180607 06:53:01<+discordbot5> BTW, one possibility is this bug from a video you linked here earlier: https://youtu.be/lkgszkPnV8g?t=25m15s 20180607 06:53:21<+discordbot5> is shared_ptr thread-saf? 20180607 06:53:23<+discordbot5> safe* 20180607 06:53:27<+discordbot5> that one? 20180607 06:53:35<+discordbot5> Yes, that one. 20180607 06:54:42<+discordbot5> but the UI is only handled in the main thread 20180607 06:56:04<+discordbot5> widgets are now handled by shared_ptrs, yes, but nothing here should be touching them. 20180607 06:56:18<+discordbot5> in the worker thread, that is 20180607 06:56:36<+discordbot5> On the other hand, it's almost impossible to explain why the crash is timing related if there is only one thread involved. 20180607 06:56:51<+discordbot5> A single thread should be deterministic and always do the same things in the same order. 20180607 06:56:55<+discordbot5> why do you say it's timing related? 20180607 06:57:16<+discordbot5> You're only getting it in release builds, which are faster. 20180607 06:57:35<+discordbot5> And --nocache also changes timing. 20180607 06:57:40<+discordbot5> @shadowm side note to all of this - does 1.15 seem to launch faster than 1.14? 20180607 06:57:52<+discordbot5> It could have to do with order of allocations though. 20180607 06:57:58<+discordbot5> @jyrkive i did not get it with a ReleaseDebug build 20180607 06:58:15<+discordbot5> As a last resort I could make a pure -O0 build and run it through Valgrind. 20180607 06:58:37<+discordbot5> is that completely optimized or completely unoptimized? 20180607 06:58:46<+discordbot5> (For vultraz's reference, that's about as comfortable as sitting on a cactus.) 20180607 06:59:40<+discordbot5> @Vultraz It's even more evidence in favor of a timing issue. ReleaseDebug has very slightly different timing characteristics because the linker orders things in a different way. 20180607 06:59:50<+discordbot5> @shadowm Could you try ThreadSanitizer? 20180607 07:00:03<+discordbot5> I couuuuuuld. 20180607 07:00:27<+discordbot5> O3 + LTO + march=native works for me, FWIW 20180607 07:00:29<+discordbot5> I'm not a fan of all the external noise it includes. 20180607 07:00:47<+discordbot5> PA and SDL doing weird crap and tripping tsan, mainly. 20180607 07:58:18<+discordbot5> This is the tsan output up to the title screen: https://gist.github.com/shikadiqueen/08090d4e3c9f8eba4f63226ceb250b42 20180607 07:59:21<+discordbot5> hmmmm 20180607 08:00:36<+discordbot5> @jyrkive I can't tell if this confirms your theory about shared_ptrs.... 20180607 08:01:02<+discordbot5> I see some shared stuff... 20180607 08:01:14<+discordbot5> but that looks like t_string-related 20180607 08:01:15<+discordbot5> And up to the Objectives screen of Two Brothers scenario 1: (you will need to click on Raw to see the full thing, it includes the lines from the log above) https://gist.github.com/shikadiqueen/69808f4097f18afd8398a01c5b0d8f60 20180607 08:02:32<+discordbot5> thanks for grabbing this 20180607 08:05:54<+discordbot5> all the drawing stuff is in the main thread as far asi can see.. 20180607 08:06:09<+discordbot5> Interesting. The log shows that call_in_main_thread() isn't thread-safe. 20180607 08:06:11<+discordbot5> https://github.com/Vultraz/wesnoth/blob/gui2_widget_ptr_init_refactor/src/events.cpp#L57 20180607 08:06:27<+discordbot5> That boolean isn't atomic, or protected by a mutex. 20180607 08:06:37<+discordbot5> .....oh my 20180607 08:07:26<+discordbot5> design oversight, this is 20180607 08:09:24<+discordbot5> would changing it to std::atomic_bool be enough? 20180607 08:09:30<+discordbot5> Yes. 20180607 08:10:45<+discordbot5> Hmm... the log doesn't seem to show anything related to GUI widget ownership. :/ 20180607 08:10:55<+discordbot5> yup :/ 20180607 08:13:09<+discordbot5> and trying to debug my release build still tells me the heap has been corrupted 20180607 08:16:30<+discordbot5> hmmm 20180607 08:16:34<+discordbot5> wait 20180607 08:16:36<+discordbot5> just noticed some suspicious code 20180607 08:18:42<+discordbot5> a function where I take a non-const shared_ptr reference 20180607 08:19:34<+discordbot5> though it's immediately passed to a function that takes a copy... 20180607 08:24:51<+discordbot5> nope 20180607 08:24:55<+discordbot5> didn't fix it 20180607 08:30:09-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180607 08:32:20-!- fabi_ is now known as fabi 20180607 08:32:31<+discordbot5> I dunno, maybe you can see something suspicious in the chageset I don't :/ 20180607 08:32:34<+discordbot5> https://github.com/Vultraz/wesnoth/commit/3b917defe7e893e0a75fa9b016b42c2abb05eb1e 20180607 08:32:40-!- fabi [~fabi@200116b82b97b9007cd44bc765eeae54.dip.versatel-1u1.de] has quit [Changing host] 20180607 08:32:40-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180607 08:32:47<+discordbot5> (excluding the viewport fix) 20180607 08:32:49<+discordbot5> zookeeper: Any particular reason this is still pending and without any comments? https://github.com/wesnoth/wesnoth/pull/3190 20180607 08:33:25<+discordbot5> I didn't merge it since I'm not entirely satisfied with the new graphics 20180607 08:34:24<+discordbot5> If only there was a way to tell the artist about that. 20180607 08:35:15< fabi> Hello, is someone on MacOSX online? 20180607 08:36:25< zookeeper> @shadowm, i guess i got the impression it was still a WIP. i'll merge it... 20180607 08:36:44<+discordbot5> blinks 20180607 08:37:00<+discordbot5> It's hard to tell whether it's ready or not when the PR description is empty. 20180607 08:37:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 256 seconds] 20180607 08:37:26-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20180607 08:37:59<+discordbot5> You could ask, of course. Although my first assumption is that if someone doesn't include anything to the effect of "WIP" or "DO NOT MERGE" in the description/subjectk they probably consider it to be finished barring any comments from the would-be reviewers. 20180607 08:39:45<+discordbot5> Incidentally, I spotted #3176 last night but I stopped reading since it apparently contains SotA spoilers (I haven't got around to playing that yet). 20180607 08:43:33< irker268> wesnoth: doofus-01 wesnoth:1.14 216215830ae5 / data/campaigns/Under_the_Burning_Suns/ (5 files in 3 dirs): UtBS: Graphics update for Giant Ant (#3190) https://github.com/wesnoth/wesnoth/commit/216215830ae52909ad874f907ba60bf2b96da22c 20180607 08:50:36< irker268> wesnoth: doofus-01 wesnoth:master 9bb6cbb82c46 / data/campaigns/Under_the_Burning_Suns/ (5 files in 3 dirs): UtBS: Graphics update for Giant Ant (#3190) https://github.com/wesnoth/wesnoth/commit/9bb6cbb82c46a51aa9a3f4da2eefdcff9c4409e6 20180607 09:07:23<+discordbot5> @Vultraz Code reading shows two instances of thread-unsafe shared_ptr assignment. 20180607 09:08:05<+discordbot5> One in grid::child::set_widget() and another in scrollbar_container::finalize_setup(). 20180607 09:08:39<+discordbot5> It's possible that some other thread accesses the shared_ptr at the same time when your code assigns to it. 20180607 09:13:02<+discordbot5> hmmm 20180607 09:13:09<+discordbot5> how would I address this? 20180607 09:13:58<+discordbot5> I'd suggest testing the hypothesis first. 20180607 09:14:16<+discordbot5> Fiddle with the timing by adding SDL_Delay(10) to both functions. 20180607 09:14:38<+discordbot5> before or after assignment? 20180607 09:14:38<+discordbot5> If it's a race condition, it's very unlikely that it would occur with different timing. 20180607 09:14:42<+discordbot5> Before. 20180607 09:34:25<+discordbot5> no, that doesn't seem to change anything.. 20180607 09:35:10<+discordbot5> thought maybe one of the delays was postponing the issue, but that doesn't seem to be the case 20180607 09:35:17<+discordbot5> I see. It's almost certainly something else, then. 😦 20180607 09:41:35-!- stikonas_ is now known as stikonas 20180607 09:54:09-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has quit [Ping timeout: 248 seconds] 20180607 10:01:34-!- travis-ci [~travis-ci@ec2-54-204-134-146.compute-1.amazonaws.com] has joined #wesnoth-dev 20180607 10:01:35< travis-ci> wesnoth/wesnoth#18497 (master - 9bb6cbb : doofus-01): The build has errored. 20180607 10:01:35< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/389145940 20180607 10:01:35-!- travis-ci [~travis-ci@ec2-54-204-134-146.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180607 10:07:59< irker268> wesnoth/wesnoth:1.14 mattsc 746be26e5d Goto Micro AI: add [and] to a filter AppVeyor: All builds passed 20180607 11:49:30-!- APic [apic@apic.name] has quit [Ping timeout: 260 seconds] 20180607 12:23:44-!- APic [apic@apic.name] has joined #wesnoth-dev 20180607 12:37:38-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Ping timeout: 265 seconds] 20180607 12:50:01-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has joined #wesnoth-dev 20180607 12:54:57-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has quit [Ping timeout: 264 seconds] 20180607 13:08:07-!- irker268 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180607 13:17:54-!- irker271 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180607 13:17:54< irker271> wesnoth/wesnoth:1.14 josteph a6887a2bf7 Replay: Don't disable the "Point of view AppVeyor: All builds passed 20180607 13:33:30-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180607 13:40:26< irker271> wesnoth: mattsc wesnoth:1.14 fb364cf2b738 / data/ai/lua/ai_helper.lua: AI helper: improve efficiency of get_unit functions https://github.com/wesnoth/wesnoth/commit/fb364cf2b7384aa5a3c68ed9d48948cf3405f103 20180607 13:40:28< irker271> wesnoth: mattsc wesnoth:1.14 4b8870ed93f8 / data/ai/micro_ais/cas/ca_goto.lua: Goto Micro AI: change order of SLF and SUF evaluation https://github.com/wesnoth/wesnoth/commit/4b8870ed93f84f4aed3479c33c787a75591ed0b5 20180607 13:40:30< irker271> wesnoth: mattsc wesnoth:1.14 7727130e2443 / data/ai/micro_ais/cas/ca_goto.lua: Goto Micro AI: add [and] to a filter https://github.com/wesnoth/wesnoth/commit/7727130e244398911b574f43d705c7c69b2cce56 20180607 13:40:32< irker271> wesnoth: mattsc wesnoth:1.14 6071efa67d24 / data/ai/ (lua/ai_helper.lua micro_ais/cas/ca_goto.lua): Merge pull request #3213 from mattsc/speed_up_goto_mai https://github.com/wesnoth/wesnoth/commit/6071efa67d24745f982f69963a26118444fecf3f 20180607 13:45:54< irker271> wesnoth: mattsc wesnoth:master 972ecc2f56c3 / data/ai/lua/ai_helper.lua: AI helper: improve efficiency of get_unit functions https://github.com/wesnoth/wesnoth/commit/972ecc2f56c3cc1391db165518324b1a3757431d 20180607 13:45:56< irker271> wesnoth: mattsc wesnoth:master 0dcbe1d0d0b1 / data/ai/micro_ais/cas/ca_goto.lua: Goto Micro AI: change order of SLF and SUF evaluation https://github.com/wesnoth/wesnoth/commit/0dcbe1d0d0b1dda90a0fa649120348b7542f2644 20180607 13:45:58< irker271> wesnoth: mattsc wesnoth:master 6c38b8ce934e / data/ai/micro_ais/cas/ca_goto.lua: Goto Micro AI: add [and] to a filter https://github.com/wesnoth/wesnoth/commit/6c38b8ce934ea68bd11a3aa960a91fe6f9dbfb87 20180607 13:55:41< irker271> wesnoth: mattsc wesnoth:master 7ed5b210b5ae / changelog.md: Changelog: collect AI entries in 'AI' section https://github.com/wesnoth/wesnoth/commit/7ed5b210b5aecffc5f9d34e468abe237783be158 20180607 13:55:43< irker271> wesnoth: mattsc wesnoth:master 7afe6adbee97 / changelog.md: Update changelog with Lua AI efficiency improvements https://github.com/wesnoth/wesnoth/commit/7afe6adbee971ddfbd23df67929a965ff57597d1 20180607 13:55:54<+discordbot5> When inheriting from a unit an animation - be it in a [variation] or [female] tag or using [base_unit] - and placing another tag to overwrite the inherited animation - will the tag replace the whole inherited tag? Or are they merged together and one must mention every subtag of the inherited tag to overwrite them?asking because of the bat sound issue 20180607 13:56:26<+discordbot5> if I set a breakpoint in grid::child::set_widget in 3/4 instances it says the internal widget ptr is "empty".... 20180607 13:59:26< irker271> wesnoth: mattsc wesnoth:1.14 84e88ee797b8 / changelog.md: Update changelog with Lua AI efficiency improvements https://github.com/wesnoth/wesnoth/commit/84e88ee797b8145343308702c12d9788aea67e82 20180607 14:00:30< mattsc> @Vultraz That’s all I had on my list for 1.14.3. 20180607 14:00:44<+discordbot5> good, good 20180607 14:02:56< zookeeper> @sevu, i don't know, but i _think_ the bat sound issue isn't related to that. it affects WC's too, after all. 20180607 14:03:29< zookeeper> oh, you mean... yeah i get it. as said i'll try to rewrite it to fix it. afk now. 20180607 14:13:02<+discordbot5> does it mean anything if the variable entry is red in VS? 🤔 20180607 14:13:47<+discordbot5> It means that the value has changed after the last single-step. 20180607 14:15:41<+discordbot5> alright... I've set up a breakpoint in set_widget and everything looks alright 20180607 14:17:23<+discordbot5> each ptr seems to have "3 strong refs" 20180607 14:24:17-!- travis-ci [~travis-ci@ec2-54-204-134-146.compute-1.amazonaws.com] has joined #wesnoth-dev 20180607 14:24:18< travis-ci> wesnoth/wesnoth#18498 (1.14 - 6071efa : mattsc): The build has errored. 20180607 14:24:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/389252562 20180607 14:24:18-!- travis-ci [~travis-ci@ec2-54-204-134-146.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180607 14:37:01-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: mattsc] 20180607 14:39:34-!- travis-ci [~travis-ci@ec2-54-204-134-146.compute-1.amazonaws.com] has joined #wesnoth-dev 20180607 14:39:35< travis-ci> wesnoth/wesnoth#18500 (master - 7afe6ad : mattsc): The build passed. 20180607 14:39:35< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/389260106 20180607 14:39:35-!- travis-ci [~travis-ci@ec2-54-204-134-146.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180607 14:39:40<+discordbot5> zookeeper, I wrote down my thoughts/experiments in 3215, maybe it helps. Please tell me if I am wrong with my understanding of how inheritance works. 20180607 14:52:55< irker271> wesnoth/wesnoth:1.14 doofus-01 216215830a UtBS: Graphics update for Giant Ant (#31 AppVeyor: All builds passed 20180607 14:53:52<+discordbot5> calling set_child with id set_widget called 1 times calling set_child with id set_widget called 2 times calling set_child with id set_widget called 3 times calling set_child with id test_animation set_widget called 4 times calling set_child with id status set_widget called 5 times calling set_child with id set_widget called 6 times 20180607 14:53:54<+discordbot5> hmmm... 20180607 14:58:34<+discordbot5> ok, the problem is not here 20180607 15:00:20-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev 20180607 15:11:46-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has joined #wesnoth-dev 20180607 15:58:07-!- behalebabo [~behalebab@unaffiliated/behalebabo] has quit [Ping timeout: 245 seconds] 20180607 15:59:15-!- behalebabo [~behalebab@unaffiliated/behalebabo] has joined #wesnoth-dev 20180607 16:28:13-!- gallaecio [~quassel@162.red-81-39-199.dynamicip.rima-tde.net] has quit [Remote host closed the connection] 20180607 16:31:14-!- gfgtdf [~gfgtdf@134.76.63.8] has joined #wesnoth-dev 20180607 16:31:15-!- gfgtdf_ [~gfgtdf@134.76.63.8] has joined #wesnoth-dev 20180607 16:31:45-!- gfgtdf [~gfgtdf@134.76.63.8] has quit [Client Quit] 20180607 16:48:12-!- mattsc [~mattsc@wesnoth/developer/mattsc] has quit [Quit: So long and thanks for all the fish.] 20180607 16:53:41-!- gallaecio [~quassel@188.79.96.255] has joined #wesnoth-dev 20180607 17:03:45< irker271> wesnoth/wesnoth:master doofus-01 9bb6cbb82c UtBS: Graphics update for Giant Ant (#31 AppVeyor: All builds passed 20180607 17:19:04<+discordbot5> ok, how is it release builds allow illegal access if dynamic_ptr_cast fails. 😐 20180607 17:19:20<+discordbot5> I had this logging set up: cpp std::cerr << "calling set_child with id " << widget->id() << " and type " << std::dynamic_pointer_cast(widget)->get_control_type() << std::endl; 20180607 17:19:35<+discordbot5> debug builds tell me it's an illegal access if the cast fails 20180607 17:20:01<+discordbot5> release builds say nothing 20180607 17:20:27<+discordbot5> blah 20180607 17:20:38<+discordbot5> I guess it's irrelevant 20180607 17:20:50< Soliton> surely you need to check the result of the cast before dereferencing. 20180607 17:21:35<+discordbot5> @Vultraz Null pointer dereference is undefined behavior. 20180607 17:21:43<+discordbot5> It's not guaranteed to crash the game. 20180607 17:22:34<+discordbot5> You can call a method on a pointer to null and it may actually work as long as said method doesn't access member variables. 20180607 17:22:56<+discordbot5> That's just a consequence of an implementation detail. 20180607 17:23:00<+discordbot5> Do not rely on it. 20180607 17:23:09<+discordbot5> nods 20180607 17:24:39<+discordbot5> anyway, I've confirmed that there are 6 calls to grid::child::set_widget that pass on both builds... 20180607 17:25:47<+discordbot5> the subsequent ones are setting them to nullptr... 20180607 17:26:15<+discordbot5> so the crash is somewhere. after setup 20180607 17:26:23<+discordbot5> but how can that be 20180607 17:26:38-!- sigurdfd [sigurdfd@dynamic-acs-72-23-110-196.zoominternet.net] has joined #wesnoth-dev 20180607 17:28:37<+discordbot5> let's add logging to the widget dtor 20180607 17:29:28<+discordbot5> no widgets are destroyed. 20180607 17:30:03<+discordbot5> so if nothing is prematurely destroyed WHAT'S GOING ON 20180607 17:31:27<+discordbot5> alright... 20180607 17:31:44<+discordbot5> let's try finding the next executed block of code after the 6th call to set_widget 20180607 17:31:52<+discordbot5> VS helpfully tells you that 20180607 17:33:14<+discordbot5> void builder_grid::build(grid& grid, optional_replacements_t replacements) const ends 20180607 17:33:39<+discordbot5> alright 20180607 17:33:53<+discordbot5> so that tells us the damn grid is built 20180607 17:35:05<+discordbot5> well, first cpp if(gui2::widget* w = cell.get_widget()) { w->set_parent(this); } is called, but there's nothing weird here... 20180607 17:35:26<+discordbot5> so, we got here from container_base::init_grid 20180607 17:35:37<+discordbot5> ya know, actually, this function used to take a ptr 20180607 17:35:42<+discordbot5> not a ref 20180607 17:35:48<+discordbot5> could that have anything ot do... 20180607 17:36:02<+discordbot5> no, I don't think so 20180607 17:36:04<+discordbot5> there's no assignment 20180607 17:36:52<+discordbot5> so we have grid_builder->build(grid_); 20180607 17:37:09<+discordbot5> used to take &grid_, but since it's a member object I see no problem here 20180607 17:37:54<+discordbot5> so, where do we go next 20180607 17:37:55<+discordbot5> win->add_to_keyboard_chain(win.get()); 20180607 17:37:59<+discordbot5> no problem here 20180607 17:39:04<+discordbot5> - window unique_ptr {video_= status_=51707904 show_mode_=686648991 ...} std::unique_ptr > struct at NULL? eh... also probably irrelevant 20180607 17:39:41<+discordbot5> So it means that window is null. 20180607 17:40:27<+discordbot5> it says video_ is null 20180607 17:41:09<+discordbot5> If window isn't null or expected to be garbage, this is UB. 20180607 17:41:16<+discordbot5> References are not allowed to be null. 20180607 17:41:56<+discordbot5> The values of status_ and show_mode_ look like garbage as well. 20180607 17:43:09<+discordbot5> but that would mean there's some problem in this block: https://github.com/Vultraz/wesnoth/blob/gui2_widget_ptr_init_refactor/src/gui/core/window_builder.cpp#L49-L89 20180607 17:43:32<+discordbot5> and i didn't touch that... 20180607 17:44:50<+discordbot5> Which line are you on? 20180607 17:45:02<+discordbot5> If it's 85 or 86, this is expected. 20180607 17:45:19<+discordbot5> window hasn't been initialized yet, so it's a wild pointer. 20180607 17:45:31<+discordbot5> hmmm 20180607 17:45:39<+discordbot5> I'll have to double check 20180607 17:45:52<+discordbot5> MSVC debugging rule of thumb: don't look at variables which haven't been initialized yet. 20180607 17:46:27<+discordbot5> yeah, I've added logging...the dialog successfully gets all the way to show 20180607 17:46:39<+discordbot5> as is expected because we see it.. 20180607 17:47:18<+discordbot5> so I know the dialog is built correctly 20180607 17:47:21<+discordbot5> the dialog shows correctly 20180607 17:47:27<+discordbot5> no widgets are prematurely destroyed 20180607 17:47:54<+discordbot5> Making it to show() doesn't necessarily mean that everything until that point has been done correctly. 20180607 17:48:27<+discordbot5> It's possible that some memory has been freed, but the game hasn't crashed yet because the memory area hasn't been overwritten (or subsequently read). 20180607 17:48:43<+discordbot5> and I know the dialog makes it at least past Verifying Cache, but will always freeze at Reading Files and Creating Cache... 20180607 17:50:16<+discordbot5> let's add a breakpoint at show()... 20180607 17:50:53<+discordbot5> window ptr loos god.. 20180607 17:50:55<+discordbot5> good 20180607 17:51:43<+discordbot5> everything looks good here 20180607 17:59:28<+discordbot5> oddd 20180607 17:59:31<+discordbot5> setting stage to Reading files and creating cache... calling ls process calling ls draw callback calling ls process calling ls draw callback calling ls process calling ls draw callback calling ls process calling ls draw callback c 20180607 17:59:44<+discordbot5> there's a lone c at the end of my cerr output 20180607 18:00:01<+discordbot5> does this mean something 20180607 18:00:22<+discordbot5> ie, is there some reason an entire line wouldn't print 20180607 18:00:42<+discordbot5> interesting.... 20180607 18:01:17<+discordbot5> the issue definitely seems to be in the draw callback 20180607 18:04:58<+discordbot5> the problem does not go away if i remove the draw callback's contents 20180607 18:06:08-!- sigurdfd [sigurdfd@dynamic-acs-72-23-110-196.zoominternet.net] has quit [] 20180607 18:21:35<+discordbot5> is it possible there's a problem in the worker thread? 20180607 18:21:41<+discordbot5> I don't know how to check that... 20180607 18:22:37<+discordbot5> The fact that the problem doesn't occur in ReleaseDebug builds suggests that it's timing related, and in turn, that the worker thread is involved. 20180607 18:38:03<+discordbot5> Can you set a breakpoint in the worker? 20180607 18:38:18<+discordbot5> Or do you do that by setting a breakpoint in the code executed in the worker 20180607 18:38:43<+discordbot5> The latter. 20180607 18:38:56<+discordbot5> Breakpoints work regardless of which thread hits it. 20180607 18:45:21< gfgtdf_> well if your debugtool doesnt support thread specific breakpoins, you can simpl add a code like if(!is_mein_thread()) { int i = 0; } and add a brekpoint into that. 20180607 18:45:51-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20180607 18:48:23<+discordbot5> MSVC does support thread-specific breakpoints. You can right-click a breakpoint, then go Conditions -> Filter -> ThreadName. 20180607 18:49:00<+discordbot5> (Or ThreadId, if you have obtained the ID of the main thread earlier. Note that it changes between runs though.) 20180607 18:56:33<+discordbot5> ok, so I added some logging first 20180607 18:56:37<+discordbot5> the game doesn't get past this line 20180607 18:56:39<+discordbot5> cache_.get_config(filesystem::get_wml_location(wml_tree_root), game_config_); game_config_.append(valid_cores); 20180607 18:56:47-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 256 seconds] 20180607 18:57:01<+discordbot5> let's see which. 20180607 18:57:43<+discordbot5> yeah, it's specifically cache_.get_config(filesystem::get_wml_location(wml_tree_root), game_config_); 20180607 18:58:33<+discordbot5> let's add a breakpoint 20180607 18:59:40-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20180607 18:59:44< zookeeper> @sevu, it doesn't (seem to) have anything to do with inheritance; i can just use the WC defense anims as-is without any inheritance, and they exhibit the same problem. 20180607 19:00:04< zookeeper> (of course, you may want to double-check that) 20180607 19:00:10<+discordbot5> actually, first let's add finer logging 20180607 19:00:17< gfgtdf_> so i understood you correctly that the worker thread crashes during cache_.get_config(filesystem::get_wml_location(wml_tree_root), game_config_); ? 20180607 19:00:35<+discordbot5> that seems to be the case. I'm getting more info. 20180607 19:01:13<+discordbot5> it reaches config_cache::read_cache... 20180607 19:02:17< gfgtdf_> shadowms tsay output form earielr also had at least one trace that goes points to game_config::config_cache::get_config, unfortunateley the correpsonding maintread entryjust shows '[failed to restore the stack]' 20180607 19:02:56< gfgtdf_> wait why do you need breakoints, cnt you just look at tha stacktrace at when it crashes ? 20180607 19:03:01<+discordbot5> I wonder if shadowm's tsan output would be cleaner in general 20180607 19:03:12<+discordbot5> after fixing the error in call_from_main_thread 20180607 19:03:30<+discordbot5> gfgtdf_: this is a release-only crash happening with some changes of mine. No errors with debug builds 20180607 19:03:50<+discordbot5> all I get with release isan error about an exception thown because a stack was corrupted 20180607 19:03:56< gfgtdf_> if you mean that nonatimic bool that was just a few lines 20180607 19:08:01<+discordbot5> wtf. now wesnoth is just immediately crashing and doesn't even stay frozen so i can read console 20180607 19:11:12<+discordbot5> what in hell... 20180607 19:11:53<+discordbot5> ok 20180607 19:12:01<+discordbot5> it passes at least as far as this: 20180607 19:12:11<+discordbot5> cpp return config_cache_transaction::instance().add_defines_map_diff(defines_map); 20180607 19:12:34< gfgtdf_> i looked at showms tsan log again and i think the firt issue was the textdomain_to_id and id_to_textdomain in tstring.cpp 20180607 19:14:57<+discordbot5> I added an assertion at the start of config_cache_transaction::add_defines_map_diff and it's only somtimes reached 20180607 19:15:03<+discordbot5> and this shit is back in the console preprocessor: ??? not terminated 20180607 19:15:37<+discordbot5> config_cache_transaction::instance is defined as so... 20180607 19:15:44<+discordbot5> cpp static config_cache_transaction& instance() { assert(active_); return *active_; } 20180607 19:15:54<+discordbot5> that assertion never fails, so... 20180607 19:17:14<+discordbot5> the assertion in config_cache_transaction::add_defines_map_diff is consistently hit when using --nocache 20180607 19:17:55<+discordbot5> but it must be by a different path... 20180607 19:19:05<+discordbot5> yes 20180607 19:20:11<+discordbot5> well, that's odd. my logging doesn't seem to show that call is reached... 20180607 19:20:12<+discordbot5> but.. 20180607 19:20:14<+discordbot5> mehhh 20180607 19:21:49<+discordbot5> I deleted my cache, game still crashes 20180607 19:21:53<+discordbot5> what the hell is going on... 20180607 19:23:11<+discordbot5> @shadowm does it not crash for you still if you delete your cache folder? 20180607 19:25:34<+discordbot5> I don't understand how my refactoring of the UI can somehow end up with a crash in the config cache mechanism 20180607 19:25:38<+discordbot5> like... what?? 20180607 19:26:48<+discordbot5> is this a bug that was somehow hidden before? 20180607 19:27:00<+discordbot5> did i actually fuck up my code somehow? 20180607 19:58:40-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180607 19:58:46-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180607 20:04:07-!- irker271 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout] 20180607 20:13:15-!- irker851 [~irker@uruz.ai0867.net] has joined #wesnoth-dev 20180607 20:13:15< irker851> wesnoth/wesnoth:master mattsc 7afe6adbee Update changelog with Lua AI efficiency AppVeyor: All builds passed 20180607 20:18:47< gfgtdf_> i think i'll file an issue for the loadingscreen issues unvocered by that tsan run so that it wont be fogotten 20180607 20:19:44<+discordbot5> Keep in mind it’s against master 20180607 20:24:22-!- behalebabo [~behalebab@unaffiliated/behalebabo] has quit [Ping timeout: 264 seconds] 20180607 20:24:53-!- fabi [~fabi@200116b82bd66c00c07d8dcce3256a4e.dip.versatel-1u1.de] has joined #wesnoth-dev 20180607 20:24:53-!- fabi [~fabi@200116b82bd66c00c07d8dcce3256a4e.dip.versatel-1u1.de] has quit [Changing host] 20180607 20:24:53-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180607 20:26:46< gfgtdf_> hmm ye but i think most of these apply to 1.14 aswell. 20180607 20:28:46-!- behalebabo [~behalebab@unaffiliated/behalebabo] has joined #wesnoth-dev 20180607 20:31:12<+discordbot5> switching back to master to confirm that the problem is indeed with my changes 20180607 20:34:03< irker851> wesnoth: Charles Dang wesnoth:master b70463b6adbe / src/events.cpp: Ensure events::call_in_main_thread is thread-safe https://github.com/wesnoth/wesnoth/commit/b70463b6adbeb235ba24da315627c5dba79b5e75 20180607 20:50:55-!- travis-ci [~travis-ci@ec2-54-196-204-91.compute-1.amazonaws.com] has joined #wesnoth-dev 20180607 20:50:56< travis-ci> wesnoth/wesnoth#18502 (master - b70463b : Charles Dang): The build was broken. 20180607 20:50:56< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/389426527 20180607 20:50:56-!- travis-ci [~travis-ci@ec2-54-196-204-91.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180607 20:57:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180607 20:57:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180607 21:01:08-!- gallaecio [~quassel@188.79.96.255] has quit [Quit: http://quassel-irc.org - Converse confortabelmente. En calquera parte.] 20180607 21:01:11< zookeeper> @sevu, ok, there's indeed _also_ an inheritance issue. as i said, the sound problem exists even when using the anim on an unrelated unit, and when i rewrote the anim to fix that problem and copied it back over to the WC bat, it gets messed up. 20180607 21:06:07< gfgtdf_> vultraz: d you know under whihc conditions this comment https://github.com/wesnoth/wesnoth/blob/b5f76eff796c09921b34baae93989697e07c2ec6/src/gui/core/canvas.cpp#L1063is trietrueis true bout image loactor returing different images? 20180607 21:07:07< gfgtdf_> hmm neverminds, sees be bout the tiltescreen logog when the language is changed. 20180607 21:08:59<+discordbot5> probably stuff like that yes 20180607 21:10:06< gfgtdf_> hmm i still think we can still cache it in most cases though, maybe i'll add a attribute cache yes/no in [image] 20180607 21:10:57<+discordbot5> why? 20180607 21:11:37< gfgtdf_> to fix loadginsreen issues so that the image is not 'searche'd during the loadginscreen. 20180607 21:12:18< gfgtdf_> actuall you cannot change the language whiel playing a game right? so the tiltescreen is really the only case hre that can happen i assume. 20180607 21:13:18<+discordbot5> that's not going to fix the issue 20180607 21:13:59< gfgtdf_> it's goind to fix one the threading issue i noted in my bugreport (the one about image locator) 20180607 21:15:09<+discordbot5> what are you talking about 20180607 21:15:18<+discordbot5> that's an issue with the worker thread accessing the image cache 20180607 21:15:27<+discordbot5> the main thread is SUPPOSED to access it 20180607 21:15:40<+discordbot5> and even if you cached the result it still need to be fetched once 20180607 21:17:25< gfgtdf_> https://github.com/wesnoth/wesnoth/issues/3218, the worker thread needs to acces it aswell and making sure that the mainscreen doesnt call it is way easier since the worer thread can asicially do anything, in particular ince it executes umc wml. 20180607 21:17:55<+discordbot5> then make the cache thread-safe 20180607 21:19:32< gfgtdf_> why should we do it if the loadingscreen just need it for two images images? also as jykive noticed the threadsafe solution that we had before was quite slow. 20180607 21:21:22<+discordbot5> you're not fixing the issue 20180607 21:21:31<+discordbot5> you're sweeping it under the rug 20180607 21:21:59<+discordbot5> there;s no guarantee the ls will fetch its images before the worker thread accesses it 20180607 21:25:38< gfgtdf_> well, my plan was to bypass the image.cpp cache for the tiltescreen dialog ui so that won't clash with the get_image calls wrong the worker thread. 20180607 21:28:34-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Quit: Konversation terminated!] 20180607 21:28:44-!- fabi [~fabi@mue-88-130-62-149.dsl.tropolys.de] has joined #wesnoth-dev 20180607 21:28:44-!- fabi [~fabi@mue-88-130-62-149.dsl.tropolys.de] has quit [Changing host] 20180607 21:28:44-!- fabi [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev 20180607 21:32:22-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection] 20180607 21:38:32< irker851> wesnoth: ln-zookeeper wesnoth:1.14 ff7aa38e3544 / data/core/units/undead/ (Corpse_Soulless.cfg Corpse_Walking.cfg): Restructured WC/Soulless bat variation defense animation (fixes #3215) https://github.com/wesnoth/wesnoth/commit/ff7aa38e3544188c7a1f499ad9c35724e8a8aec9 20180607 21:40:01< irker851> wesnoth: ln-zookeeper wesnoth:master 131868581d1b / data/core/units/undead/ (Corpse_Soulless.cfg Corpse_Walking.cfg): Restructured WC/Soulless bat variation defense animation (fixes #3215) https://github.com/wesnoth/wesnoth/commit/131868581d1bb22c2d5612e223657951489e6c1d 20180607 21:41:24< zookeeper> wow, lotsa numbers. 20180607 21:47:04< zookeeper> @sevu, @shadowm, i wouldn't mind you also double-checking the new behavior. 20180607 22:13:12-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20180607 22:47:25-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20180607 22:47:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20180607 22:52:26-!- travis-ci [~travis-ci@ec2-54-90-238-126.compute-1.amazonaws.com] has joined #wesnoth-dev 20180607 22:52:27< travis-ci> wesnoth/wesnoth#18504 (master - 1318685 : ln-zookeeper): The build is still failing. 20180607 22:52:27< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/389451305 20180607 22:52:27-!- travis-ci [~travis-ci@ec2-54-90-238-126.compute-1.amazonaws.com] has left #wesnoth-dev [] 20180607 22:58:34-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20180607 23:20:58< irker851> wesnoth/wesnoth:1.14 mattsc 84e88ee797 Update changelog with Lua AI efficiency AppVeyor: All builds passed 20180607 23:32:57<+discordbot5> I'll try asking in here as well 👋 In abilities, "other" refers to the one with the ability, right? Is it the same for traits? Like if I'm making a trait do different things depending on the trait holder's whatever, is "other" what I should use to access the trait holder? 20180607 23:55:45-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 260 seconds] --- Log closed Fri Jun 08 00:00:00 2018