00:22:45 F0XKIN (L11 SpBr) Crash caused by signal #11: Segmentation fault (Lair:1) 00:26:08 F0XKIN (L11 SpBr) Crash caused by signal #11: Segmentation fault (Lair:1) 00:26:33 F0XKIN (L11 SpBr) Crash caused by signal #11: Segmentation fault (Lair:1) 00:30:02 F0XKIN (L11 SpBr) Crash caused by signal #11: Segmentation fault (Lair:1) 00:37:22 HyperOdds (L18 MuIE) Crash caused by signal #6: Aborted (Elf:3) 00:37:53 <11Odds> !crash 00:37:53 <04Cerebot> 22764. HyperOdds, XL18 MuIE, T:57463 (milestone): https://underhound.eu/crawl/morgue/HyperOdds/crash-HyperOdds-20260313-073721.txt 00:38:13 <11Odds> Felt like a perfectly normal cast of unearth wretches. Maybe with nowhere for the wretches to be placed? 00:39:28 <11Odds> Ah, from the log it wasn't anything to do with my turn 00:56:00 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-187-ge17ad08588 01:09:38 <08o____0> Funny that the lost souls revived a wretch but not sure if that's relevant 01:09:40 <11Odds> OK, so if I cast Unearth Wretches in this screenshot, the game reliably crashes. But it's not true that unearth wretch kills with lost souls always crash the game 01:09:41 <11Odds> https://cdn.discordapp.com/attachments/747522859361894521/1481927209257013289/image.png?ex=69b517c3&is=69b3c643&hm=b68d27574a55e3179ecc2eff0942c81bbf3f512bf552fef575f3f0472fb0e263& 01:10:05 <11Odds> Death channel is not relevant 01:11:11 <11Odds> Maybe it is lost soul kills on unearthed wretches who have just been unearthed? 01:16:03 <11Odds> My local (windows) build doesn't do stack traces, is that fixable? 01:17:27 <04dracoomega> As far as I know, it is not 01:17:56 <04dracoomega> (One of the real big advantages to using WSL, in my experience >.>) 01:18:39 <11Odds> Yeah I should probably do that some time 🙂 01:24:29 <04dracoomega> I can't immediately cause a crash with a similar scenario 01:24:45 <04dracoomega> (Whatever specific condition is missing here) 01:25:29 <11Odds> This is still my hypothesis 01:26:03 <11Odds> An unearthed wretch, killed by one of my allies before my next turn, in the presence of a lost soul 01:27:34 <04dracoomega> I've done that 01:27:51 <04dracoomega> Oh, wait, maybe I haven't and it just looked like I did 01:28:09 <11Odds> Hmmm I'm pretty sure I have though... 01:28:20 F0XKIN (L11 SpBr) Crash caused by signal #11: Segmentation fault (Lair:1) 01:28:23 <11Odds> The crash in that screenshot is only mostly consistent 🙁 01:29:05 <11Odds> Also seems not to be giving me crashlogs, confusingly 01:31:16 <04dracoomega> I, uh... I think I got something to happen 01:31:23 <04dracoomega> And the game is just hanging 01:31:55 <11Odds> Ah but when it didn't crash the wretch didn't revive. Which confuses me anew, surely that always happens if it has LoS on a lost soul 01:32:11 <04dracoomega> It doesn't if their HD is low enough and there are other targets around 01:32:41 <04dracoomega> Possibly that is unnecessary now that there are more of them around, but it means that low HD wretches will sometimes not trigger them 01:32:56 <11Odds> Ah right 01:34:01 <04dracoomega> I am wondering if it's getting caught in a loop of trying to die from being wretched and reviving 01:34:02 <04dracoomega> Somehow 01:34:35 <11Odds> As in, the wretched timeout? 01:35:22 <04dracoomega> Ah, yes. timeout_enchantments is removing ENCH_SLOWLY_DYING as part of the revival, which kills it again (before it's actually spectralised) 01:35:26 <11Odds> The lost soul marks it to revive, it does so but has a zero wretched timeout, so dies, but is still marked to revive, ... 01:36:11 <11Odds> Cool, I shall leave this in your capable hands 01:36:23 <04dracoomega> Ha ^^; 01:36:47 <11Odds> Not least because I have to go do some work 01:37:38 <04dracoomega> (I'm kind of busy also, but I can certainly put it on the to-do list) 01:37:51 <11Odds> Still curious about various things here, including why this doesn't happen with wretches who've been alive dead 01:38:41 <04dracoomega> Is it possible those were dying to timeout first? 01:38:47 <04dracoomega> Which would not cause a loop 01:39:11 <11Odds> Nah I was hitting them with a mace 01:52:23 <11Odds> An obvious fix is just lost souls not working on wretches, which tbh seems pretty reasonable anyway (these are kiku's souls, not some nasty elf's) 01:53:08 <11Odds> (But I still mean to understand what's actually going on) 04:17:28 <11Odds> Ah right, so the wretch is dying twice in a nested way, and I'm pretty sure the immediate problem is that both calls to monster_die attempt to use up the same lost soul. 04:23:59 <11Odds> At any rate, it seems to me that either a) reviving with a lost soul should remove slowly_dying without triggering death, or b) monsters with slowly_dying shouldn't be lost soul candidates at all. I'd say b). 04:25:00 <11Odds> I guess another option is c) reviving with a lost soul doesn't remove slowly_ dying at all 04:26:04 <04dracoomega> I mean, I think in practice no monster that has that should be revived by it 04:26:37 <04dracoomega> Though I am not sure that manually checking is the play. (To be honest, I find myself suddenly uncertain how hostile necromancy ought to interact with wretches) 04:26:54 <04dracoomega> Like, lost souls should probably ignore them, since they're not 'functional' monsters 04:27:11 <04dracoomega> I can see things like necromancers actually 'stealing' them, though 04:27:35 <11Odds> If we imagine a real monster (perhaps some terrifying unique you have to flee) with slowly dying, how would we want them to interact with lost souls? 04:29:24 <11Odds> I guess we'd want them revived by them, in the same way we'd want them to be targets for all the other necromancy 04:29:54 <04dracoomega> Well, ENCH_SLOWLY_DYING is only used for wretches and firewood 04:30:30 <04dracoomega> Oh, you're imagining some future thing using it? 04:30:41 <11Odds> Yeah just as a way to think about the right way to fix this 04:32:47 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 04:33:19 <04dracoomega> Honestly, if the point of some design is that they do slowly die then probably this isn't supposed to revive them anyway. So maybe I revise my earlier statement to say it's fine to veto monsters with ENCH_SLOWLY_DYING from lost souls (as we veto a bunch of things, really) 04:34:54 <11Odds> Yeah that makes sense 04:35:39 <11Odds> On the other point, I think necromancers stealing my wretches is reasonable? I'd certainly not feel aggrieved by it (though I hadn't realised it was a thing) 04:36:49 <04dracoomega> I mean, I agree that it probably makes sense. I was just thinking through what interactions might indeed make sense. 05:32:47 <04dracoomega> I am concerned that I have seen crashes from two different people today that seem to have thrashed the stack so that I can't even tell what could be at fault 05:37:43 <04dracoomega> eg: https://crawl.xtahua.com/crawl/morgue/Gonzollydolly/crash-Gonzollydolly-20260313-104023.txt and https://underhound.eu/crawl/morgue/F0XKIN/crash-F0XKIN-20260313-072632.txt (both of which crashed many times) 06:01:49 <04dracoomega> So, at least one of the many crashes here does point to handle_monsters() being on the stack, and there is a recent change to that function that I am somewhat concerned about in principle (though I can't say for sure yet whether it's at fault) 06:01:54 <04dracoomega> %git bce5b7a 06:01:55 <04Cerebot> WizardIke * 0.35-a0-180-gbce5b7a9de: Fix monster extra action from torchlight being sometimes being delayed (33 hours ago, 29 files, 132+ 78-) https://github.com/crawl/crawl/commit/bce5b7a9de8f 06:05:02 <04dracoomega> So, to avoid a group of recurring bugs in past, this wraps changes to monster::speed_increment in a method that will automatically queue them for action if they gain energy that leaves them with enough energy to act. However, there are multiple cases where monsters that are not 'real' (and may not even be in env.mons[]) have their energy set, such as when they are unmarshalled. Now, I'm not certain if it's possible to end up 06:05:02 marshalling a monster who has action energy (since why didn't they act first?). But there are multiple scenarios where we unmarshall a monster outside of env.mons[] (such as checking apostles or interlevel-followers), and in this case, unmarshalling it would add it to the action queue - even though it's not a monster on the floor and cannot be relied on to even keep existing. 06:05:41 <04dracoomega> And certainly if that happens, we'd expect undefined behavior to result 06:07:14 <04dracoomega> Now, again I am not saying that I am confident the crash is related to this, but even if it isn't, it makes me nervous that this is opening the door to some mysterious problems. 06:21:28 <04dracoomega> Okay, yes, I've managed to figure out at least one realistic way to end up with a corrupt monster in the action queue 06:21:53 <04dracoomega> If a monster falls down a shaft, it can enter the follower list while still having action energy 06:22:11 <04dracoomega> (Presumably it helps if the monster is fast, but it's definitely possible) 06:23:10 <04dracoomega> And then when the follower list is unmarshalled, it will get queued for action and then what happens is anyone's guess. (It usually doesn't immediately crash for me since it fails this check in the monster loop, but it's certainly not guaranteed to do this. C++ if (invalid_monster(mon) || !mon->alive() || !mon->has_action_energy()) continue; 06:32:30 <04dracoomega> (I don't have time at the moment to fix this more properly, so I am reverting for now as multiple people's saves are inaccessible) 06:32:59 03DracoOmega02 07* 0.35-a0-188-gb759490ca2: Revert "Fix monster extra action from torchlight being sometimes being delayed" 10(9 minutes ago, 29 files, 78+ 132-) 13https://github.com/crawl/crawl/commit/b759490ca20f 06:33:31 <04dracoomega> Okay, I suppose those servers might not even rebuild in time anyway, but in principle 16:42:38 Unstable branch on underhound.eu updated to: 0.35-a0-188-gb759490ca2 (34) 23:33:51 Unstable branch on cbro.berotato.org updated to: 0.35-a0-188-gb759490ca2 (34) 23:35:47 Unstable branch on crawl.develz.org updated to: 0.35-a0-188-gb759490ca2 (34) 23:59:14 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-188-gb759490ca2