00:34:33 Unstable branch on cbro.berotato.org updated to: 0.33-a0-554-g008097b4cb (34) 04:33:03 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5249-g4a8afe7061 05:31:45 Unstable branch on crawl.akrasiac.org updated to: 0.33-a0-554-g008097b (34) 05:35:23 <12asciiphilia> I'm not sure if this issue has already been reported, but users utilizing the tile_player_tile RC statement in Trunk are experiencing crashes. 05:35:27 <12asciiphilia> &versions 05:35:53 <04Cerebot> CAO: 0.33-a0-553-g146f489, CBR2: 0.33-a0-554-g008097b4cb, CDI: 0.33-a0-554-g008097b4cb, CDO: 0.33-a0-553-g146f489888, CNC: 0.33-a0-554-g008097b4cb, CPO: 0.33-a0-525-gc082a88ec8, CUE: 0.33-a0-553-g146f489888, CXC: 0.33-a0-553-g146f489888, LLD: none 05:36:11 <12asciiphilia> This issue has been observed in CDI and CNC using build 554. (553 is safe) 05:37:07 <12asciiphilia> https://archive.nemelex.cards/morgue/Tazdingo/crash-Tazdingo-20241211-115843.txt 07:55:31 particleface (L1 MDGl) Crash caused by signal #6: Aborted (D:1) 07:59:47 particleface (L1 MDGl) Crash caused by signal #6: Aborted (D:1) 08:00:05 particleface (L1 MDGl) Crash caused by signal #6: Aborted (D:1) 08:10:24 <09gammafunk> !crashlog 08:10:31 <09gammafunk> !crash 08:10:42 <04Cerebot> 29555. monkeytor, XL16 MDFi, T:25763 (milestone): https://crawl.dcss.io/crawl/morgue/monkeytor/crash-monkeytor-20241211-150539.txt 08:10:50 <04Cerebot> 29555. monkeytor, XL16 MDFi, T:25763 (milestone): https://crawl.dcss.io/crawl/morgue/monkeytor/crash-monkeytor-20241211-150539.txt 08:11:36 <09gammafunk> huh, not particleface's crash but I wonder what that one on cdi is about 08:11:54 <09gammafunk> !crash particleface 08:11:58 <04Cerebot> 28. particleface, XL1 MDGl, T:0 (milestone): https://cbro.berotato.org/morgue/particleface/crash-particleface-20241211-145959.txt 08:16:56 <09gammafunk> well, I guess DO can be relieved that this doesn't look like a crash due to item identification code changes 08:17:40 <09gammafunk> it could still be though; retrieving monster info for the purpose of sending webtiles cell data, it looks like 08:19:00 <09gammafunk> hrm, I see some similarities to ASCIIPhilia's reported crash, but that one is more clearly related to item code 08:19:43 <09gammafunk> oh yeah, and in fact both go through the monster_info deletion code path 08:21:47 <09gammafunk> Thanks for the report! @dracoomega this is probably related to changes in item identification but not 100% sure and I can't investigate further atm. See Ascii's description of crash conditions at https://discord.com/channels/735056636644687913/747522859361894521/1316382827620597771 and also the crash that particleface generated further below may be related. Both have stack traces from gdb and both point to an issue with deletion of 08:21:47 a monster_info object 10:55:36 <09gammafunk> It's looking like the code at tileweb.cc:1700 is perhaps working with an original item instead of a copy that it should be making (which was done before DO's commit), and when the monster_info object is deleted, we're probably deleting an item pointer that we shouldn't 10:55:48 <09gammafunk> my guess is we need to go back to working with a copy in this case, but I could be wrong 10:56:10 <09gammafunk> ran out of time to diagnose further, so hopefully DO can get to that when she's around 11:57:54 <04dracoomega> Ugh =/ 11:57:59 <04dracoomega> Well, I'm awake now (slightly) 12:03:13 <04dracoomega> Oh, hmm. A lot of other uses of get_item_known_info then made a copy of the altered item internally, and I guess I never noticed that this did not 12:03:31 <04dracoomega> Probably as simple as just copying the real item and being done with it, though 12:03:46 <09gammafunk> Yeah seemed that way to me 12:03:59 <09gammafunk> Didn't have time to patch, alas 12:05:20 <04dracoomega> I'll take a quick look to see if I'm accidentally doing the equivalent elsewhere 12:06:37 <04dracoomega> Oh, the local tiles one seems to have already been doing it correctly 12:06:48 <04dracoomega> Convenient 12:07:16 <04dracoomega> Will just build webtiles and confirm 12:07:28 <04dracoomega> Thanks for the help ^^ 12:32:52 03DracoOmega02 07* 0.33-a0-555-g577656edd5: Fix a webtiles crash with monster player tiles (gammafunk) 10(5 minutes ago, 1 file, 6+ 0-) 13https://github.com/crawl/crawl/commit/577656edd5ca 12:32:52 03DracoOmega02 07* 0.33-a0-556-g4374b4c6da: Fix DB description lookup of identified armour not working (NotBatman) 10(28 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/4374b4c6daab 13:37:56 <09gammafunk> So in order to implement my fix of fixed artprops, I need to change cpp static bool _artp_can_go_on_item(artefact_prop_type prop, const item_def &item, const artefact_properties_t &extant_props) { // see also _randart_is_conflicting artefact_properties_t intrinsic_proprt; intrinsic_proprt.init(0); _populate_item_intrinsic_artps(item, intrinsic_proprt); if (intrinsic_proprt[prop]) 13:37:57 return false; // don't duplicate intrinsic props in artefact.cc, specifically that last condition for intrinsic props 13:38:31 <09gammafunk> what this condition means is that if any prop that would be set (either fixed or randomly chosen) is a prop intrinsic to the item type, it will be ignored 13:38:53 <09gammafunk> but this disallows things like e.g. ring of protection from fire that wants to give rF++ instead of just rF+ 13:39:18 <09gammafunk> obviously it's good to disallow giving such a ring rF:-1 as a value 13:39:42 <09gammafunk> what I want to do is change this simple condition to one that allows setting an intrinsic prop if it's consisent with the base props provided by the item 13:40:22 <09gammafunk> so you could set rf:[1-3] to get rF+ through rF+++ 13:40:58 <09gammafunk> but never e.g. rf:[-infty,0] 13:41:12 <09gammafunk> (sorry for the abuse of mathematical terminology) 13:42:03 <09gammafunk> it's not hard to examine for these types of "symmetric" props that can be sometimes good or bad and likewise for props that are always good or always bad; we already do this elsewhere during artefact generation 13:42:23 <09gammafunk> so the relevant test functions exist and can be used here, necessasitating just a bit more logic than that simple conditional 13:42:38 <09gammafunk> I'm just writing this out here in case someone has a reason it's a very bad idea 13:44:09 <09gammafunk> I suppose another approach would be to simply not perform the check calling this function for artprops: as an item spec modifier, but I don't like that as much 13:44:37 <09gammafunk> it is nice to have sanity checks on things people might stuff inside many lines of DES 13:54:52 <04dracoomega> Huh, so artifact rings of protection from fire are actually less able to protect you from fire than artifact rings of other types? 13:55:45 <04dracoomega> (Really, I've often thought that the whole 'artifact rings have a base type' is itself kind of vestigal these days. Amulets still have a couple things that only work based on type and don't have artprop equivalents, but I'm not sure this is even true of rings anymore?) 14:18:43 03DracoOmega02 07* 0.33-a0-557-g3dd2b31670: Fix Rending Blade being hostile to Oka worshippers (Ge0FF) 10(5 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/3dd2b3167099 14:18:43 03DracoOmega02 07* 0.33-a0-558-geb7098ad9d: Fix targeting UI for phantom mirror (and a few other things) 10(55 seconds ago, 5 files, 10+ 7-) 13https://github.com/crawl/crawl/commit/eb7098ad9d42 16:37:39 Unstable branch on underhound.eu updated to: 0.33-a0-558-geb7098ad9d (34) 17:09:04 GnomeSayin (L23 VSFi) Crash caused by signal #6: Aborted (Depths:1) 17:09:16 GnomeSayin (L23 VSFi) Crash caused by signal #6: Aborted (Depths:1) 17:10:44 GnomeSayin (L23 VSFi) Crash caused by signal #6: Aborted (Depths:1) 17:12:06 GnomeSayin (L23 VSFi) Crash caused by signal #6: Aborted (Depths:1) 17:17:11 GnomeSayin (L23 VSFi) Crash caused by signal #6: Aborted (Depths:1) 17:27:53 GnomeSayin (L23 VSFi) Crash caused by signal #6: Aborted (Depths:1) 17:57:23 GnomeSayin (L23 VSFi) Crash caused by signal #6: Aborted (Depths:1) 18:00:46 <04dracoomega> (I did trigger a rebuild on cbr2 a while back, incidentally. It's just taking its time) 18:29:11 <09gammafunk> hrm, still hasn't finished rebuilding... 18:29:27 <09gammafunk> @dracoomega curious...can you try to refresh and see if it finishes? 18:29:44 <09gammafunk> it's feeling like it's timing out 18:30:19 Unstable branch on cbro.berotato.org updated to: 0.33-a0-558-geb7098ad9d (34) 18:30:33 <04dracoomega> Okay, that can't be a coincidence 18:30:41 <04dracoomega> If two times in a row it finished the moment I refreshed the webpage 18:31:35 <04dracoomega> You'd think if you'd sent it the command, then it wouldn't matter what the page was doing on your end, would it? 18:33:54 <09gammafunk> yeah, it was so suspicious last time 18:34:10 <09gammafunk> there's something going a bit wrong with the front end proxy I think 18:34:32 <09gammafunk> it thinks its https connection to webtiles (which I believe runs on a different host for cbr2) is timing out 18:35:14 <09gammafunk> this is all due to the fairly primitive way this script is implemented, but having a better setup would require work. at least we know for next time 18:36:06 <04dracoomega> Yeah, it's not exactly onerous to have to refresh it now and again. Just a bit weird. 18:36:43 <09gammafunk> but the gist is that the proxy probably closes the connection, and the webserver on the actual machine with webtiles sees that the connection is closed, and kills the process 23:35:18 Unstable branch on crawl.develz.org updated to: 0.33-a0-558-geb7098ad9d (34) 23:58:10 Windows builds of master branch on crawl.develz.org updated to: 0.33-a0-558-geb7098ad9d