00:13:56 Unstable branch on cbro.berotato.org updated to: 0.33-a0-516-g862ef21dcb (34) 00:39:56 03DracoOmega02 07* 0.33-a0-517-gafa22cc02a: Fix rings of Fire/Ice having a {buggy} stash prefix (Namsan) 10(55 seconds ago, 1 file, 2+ 0-) 13https://github.com/crawl/crawl/commit/afa22cc02a71 00:55:09 Monster database of master branch on crawl.develz.org updated to: 0.33-a0-517-gafa22cc02a 04:33:36 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5249-g4a8afe7061 08:18:21 <09g​ammafunk> Some interesting stats from when I finally took action on CDI's (then) 95% full drive after putting that off for weeks. Although there were about 55G of compressed ttyrecs, which was the largest user data usage by far, as expected, I was surprised by just how little the other user data consumed, all of which is (currently) uncompressed: $du -sc -BG * 2>/dev/null 17G crawl-master 1G crawl-versions.db3 1G dev 0G 08:18:22 dgamelaunch 1G dgldebug.log 14G dgldir 54G usr 1G var 84G total Here I've trimmed out trivial entries. What I found interesting was just how much was taken up by trunk binaries that you see there in usr of the DGL chroot, namely 212 crawl-git builds that still have active saves, each unstripped binary taking ~260MB. 08:19:31 <09g​ammafunk> there's now plenty of free disk on cdi after deleting ttyrecs over 30 days old, and going forward I'd like to archive those on the digital ocean S3 so they won't have to be deleted either ever (if I'm willing to pay for more disc) or for at least a few years 08:20:01 <09g​ammafunk> but it does look like I should implement a scheme of force transfering trunk games older than N days 08:20:36 <09g​ammafunk> that way it will activate the trunk cleanup script which deletes binaries/installs for trunk versions that have no active save 08:21:02 <09g​ammafunk> what's happening is that random games are slowly increasing the number of installed trunk binaries in a way that's not sustainable probably 08:21:13 <12g​e0ff> for the latest trunk, an unstripped binary for local tiles is ~40Mb, so 260MB feels very wrong 08:21:36 <09g​ammafunk> right, not sure why they're so very large, but 08:21:44 <09g​ammafunk> -rwxr-xr-x 1 root root 262602648 Dec 3 07:48 crawl-git-afa22cc02a 08:22:03 <09g​ammafunk> 40mb feels very wrong to me ge0ff 08:22:19 <09g​ammafunk> I recall binaries being far larger than that, but I guess I'd have to take a closer look 08:22:29 <09g​ammafunk> ...yes 08:22:34 <09g​ammafunk> my local crawl webtiles build: 08:22:44 <09g​ammafunk> -rwxrwxr-x 1 gammafunk gammafunk 260868792 Nov 22 17:18 crawl 08:22:59 <09g​ammafunk> this is a full debug build, so not quite what cdi has 08:23:13 <09g​ammafunk> but something tells me you're getting a much smaller binary because you're not compiling in a bunch of eatures 08:23:47 <09g​ammafunk> this is the latest ubuntu lts and cdi is running the previous ubuntu lts 08:24:00 <12g​e0ff> features: 08:24:01 <12g​e0ff> https://cdn.discordapp.com/attachments/747522859361894521/1313526159065088010/image.png?ex=67507410&is=674f2290&hm=f1c9a94301b215d0da5bb731c96659543f705343281b872c8e22b5ad62e6b39b& 08:24:09 <12g​e0ff> 🤷‍♂️ 08:24:28 <09g​ammafunk> are you sure it's unstripped? 08:24:33 <12g​e0ff> yeah 08:24:40 <09g​ammafunk> I have pcre regexs 08:24:44 <09g​ammafunk> oh 08:24:48 <12g​e0ff> just run a make via gcc 08:24:58 <09g​ammafunk> notable: WebTiles support 08:25:03 hilfy crawl:master Z$ ls -l crawl 08:25:03 -rwxr-xr-x 1 allbery allbery 251205920 Nov 28 20:19 crawl* 08:25:03 hilfy crawl:master Z$ file crawl 08:25:03 crawl: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=3d78806ea8ae2e6acff1c5afa649c1b62024ceab, with debug_info, not stripped 08:25:04 <09g​ammafunk> wonder if that is somehow balooning size 08:25:19 <09g​ammafunk> yeah ok, similar for geekosaur 08:25:28 oh, hm, but I did drop WT some time back 08:25:52 <09g​ammafunk> crawl: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=3b50b030a5e74281b84b2424d47336ec8e2daf17, with debug_info, not stripped 08:26:00 (it's "make debug FULLDEBUG=y") 08:26:32 <12g​e0ff> crawl: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 4.4.0, BuildID[sha1]=7ccd1d0d12fe86577af8daa36595e00898edb722, not stripped 08:26:48 <09g​ammafunk> crawl-git-afa22cc02a: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=9524ed271d411b60e19af931e57f6a5a5b5a804f, with debug_info, not stripped aforementioned cdi binary 08:27:12 <09g​ammafunk> not gonna lie, but pie executable sounds delicious 08:27:39 <09g​ammafunk> so I'm not sure about your vast difference in file size 08:27:48 <09g​ammafunk> but to be honest, even at only 40mb there would eventually be problems 08:28:02 <09g​ammafunk> so I think a reasonable force transfer timeframe is the best route 08:28:29 <09g​ammafunk> the only thing that vaguely worries me about those two dgl scripts is how they detect actively used saves 08:29:17 <09g​ammafunk> like it does some kind of lsof iirc and it looked a bit hokey to me, but the scripts do exist for both force transfer and no-active-save-purge (and I'm already using the latter) 08:30:00 <09g​ammafunk> anyhow, only very vaguely related to crawl dev because I did wonder if stripping binaries was warranted (some servers do this), but I think I'd hate to lose the crash data 08:30:17 <09g​ammafunk> really nice for developers to have that (never mind how cdi crashes aren't reported in channel, that's a thing I'll fix eventually) 08:31:07 <03i​mplojin> extremely useful to have debug info in crashlogs 08:33:20 I rebuilt for webtiles and it added a small amount -rwxr-xr-x 1 allbery allbery 261136800 Dec 3 10:32 crawl* 08:34:12 and yes, more crash data please! it's hard enough to diagnose crashes as it is 08:34:41 <03i​mplojin> ~40MB for me as well with FULLDEBUG=y WEBTILES=y 08:35:34 <03i​mplojin> crawl: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 4.4.0, BuildID[sha1]=e5b6ef3f0fe07c59f584c17e17c58dda2250eb46, not stripped 08:35:59 <03i​mplojin> oh, huh, that's not listing debug_info 08:36:07 re detecting actively used saves, lsof or fuser would indeed be the right tools for "is this binary in use?" (won't work for "is this save file in use" unless it's always kept open, but maybe it is since excursions are relatively common) 08:36:58 <12g​e0ff> so, out of 240 - 260 MB, the game is just 40 - 60 MB, and ~200 MB is debug info 08:37:17 sounds like C++ 😛 08:38:13 <03i​mplojin> yeah passing make debug FULLDEBUG=y WEBTILES=y balloons the size to 251MB 08:39:56 interesting 08:50:29 <12g​e0ff> wait, so if a server uses fulldebug builds, it means every 4 online players require at least 1 Gb of memory? 09:13:29 no? debug_info isn't loaded into memory, and even the text and data segments are only loaded as used 09:13:34 it's not 1980 09:14:34 also I think fulldebug builds (either that or `make debug` builds) are implicitly wizmode so I'm not sure that makes sense for servers anyway 09:14:56 my local one starts in wizmode and prints a lot of internal stuff you don't want on servers 09:14:57 <03i​mplojin> brb gotta turn off my delorean 10:11:42 <09g​ammafunk> servers aren't using fulldebug builds 10:11:47 <09g​ammafunk> at least cdi isn't 10:12:02 <09g​ammafunk> I can pull up the exact flags in a second, but it might be something about webtiles specifically, for some reason 10:12:30 <09g​ammafunk> a full debug build guarantees wizmode for new games, although I guess I should add that it is specifically a DGL build 10:12:45 <09g​ammafunk> which does further change a few things, mostly option defaults 10:14:32 <09g​ammafunk> it's: bash say-do crawl-do nice make -C source \ GAME=${GAME}-${REVISION} \ GAME_MAIN=${GAME} MCHMOD=0755 MCHMOD_SAVEDIR=755 \ INSTALL_UGRP=$CRAWL_UGRP \ WEBTILES=YesPlease USE_DGAMELAUNCH=YesPlease WIZARD=YesPlease \ STRIP=true DESTDIR=${DESTDIR} prefix= bin_prefix=/bin \ SAVEDIR=$CHROOT_CRAWL_BASEDIR/${GAME}-${REVISION}/saves \ DATADIR=$CHROOT_CRAWL_BASEDIR/${GAME}-${REVISION}/data \ 10:14:32 WEBDIR=$CHROOT_CRAWL_BASEDIR/${GAME}-${REVISION}/data/web \ SHAREDDIR=$CHROOT_CRAWL_BASEDIR/${GAME}/saves \ USE_PCRE=y \ EXTERNAL_FLAGS_L="-g" 10:14:57 <09g​ammafunk> so as you see it's a default build (not debug nor debug-lite) with webtiles and dgl 10:15:04 <09g​ammafunk> ...STRIP=true confuses me 10:15:12 <09g​ammafunk> maybe this is just ignored? 10:15:35 it's a hack, STRIP is a binary 10:15:41 <09g​ammafunk> we're adding -g at the end there 10:15:45 so it runs 'true crawl' 10:15:55 instead of 'strip crawl' 10:16:06 <09g​ammafunk> hah 10:16:08 <09g​ammafunk> that's so weird 10:16:44 <09g​ammafunk> anyhow, those options are likewise giving ~260MB binaries, so it's not debug/debug-lite causing it per se 10:17:06 I'm comparing .o file sizes between WT and non-WT builds locally 10:17:19 (minus rltiles, so) 10:18:14 anyway I imagine the STRIP thing is historical, since STRIP=/usr/bin/strip is a Makefile convention 10:20:01 <09g​ammafunk> really hoping some very simple webtiles-related fix somehow grew our binary size by over 5x and somehow no one noticed (obviously this isn't the case, but it'd be funny if it was) 10:21:15 * geekosaur wonders if it's some template madness 10:27:47 viewgeom.o is twice as big, otherwise only a small handful of files grow by over 10% and most of those are barely over that 10:28:28 rltiles doesn't have anything big enough to account for 250M 10:29:30 …it's all debugging symbols 10:30:36 hm, do the servers use LTO? I do (but with clang which means the LTO stuff is LLVM IR, I think, so will be bigger than gcc's) 10:30:46 oh wait, no clang on this machine 10:30:58 doesn't find g++'s headers for some reason 10:31:04 so never mind 10:38:42 <09g​ammafunk> regarding: > geekosaur re detecting actively used saves, lsof or fuser would indeed be the right tools for "is this binary in use?" (won't work for "is this save file in use" unless it's always kept open, but maybe it is since excursions are relatively common) I looked at this a bit more, and it seems we're doing a process listing to check for the relevant binary being in use with the relevant user's save, per: 10:38:46 https://github.com/kelbi-org/dgamelaunch-config/blob/cko/chroot/sbin/savegame-transfer.sh 10:38:56 <09g​ammafunk> that link is for floraline's repo but I think this script is unchanged from the one I use 10:40:17 <09g​ammafunk> and then there's a parent script that can call this for some "transfer all users not in the last N trunk builds" scheme 10:42:19 <09g​ammafunk> so I'll probably set up something reasonable using these two so that people can have untransferred saves for only so many trunk versions, which should fix the amount of disk usage from the binaries, regardless of how big they are 10:42:53 huh. seems like a risky way of doing it. lsof and fuser are ore or less designed for this use case 10:43:16 <09g​ammafunk> yeah, and iirc one of these other scripts does in fact use lsof, I was misremembering that this one does 10:43:25 <09g​ammafunk> maybe I can rewrite to use lsof or fuser 10:44:29 <09g​ammafunk> oh, the ttyrec compression script uses lsof 10:44:44 <09g​ammafunk> guess that makes sense 10:53:54 this one's harder unless you invert the logic (check if an instance of the game is running with fuser crawl-whatever) or you know the .cs file is always open when crawl is running 10:54:47 or lsof but I think it's more informational whereas fuser is POSIX-blessed for this exact purpose 10:57:09 that said, linux is a bit weird about POSIX utils that don't fit its zeritgeist, fuser might not be installed on all servers 12:49:01 <09g​ammafunk> It does seem you have to confirm that the binary is accessing that user's file, which i guess why ps was used there 12:50:05 <09g​ammafunk> I'll have to look into save file opening crawl-side but I'd worry that there are edge cases 15:18:27 Cruithne (L16 DsGl) ASSERT(!invalid_monster(&mons)) in 'mon-death.cc' at line 2166 failed. (Swamp:1) 15:19:06 Cruithne (L16 DsGl) ASSERT(!invalid_monster(&mons)) in 'mon-death.cc' at line 2166 failed. (Swamp:1) 15:31:06 03DracoOmega02 07* 0.33-a0-518-ga85234a9e1: Fix battlesphere sometimes shooting its owner (1000000branches, Darby) 10(12 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/a85234a9e1ab 15:31:06 03DracoOmega02 07* 0.33-a0-519-gc3491426b6: Fix monster_pathfind::fill_traversability ignoring no_actors argument 10(11 minutes ago, 1 file, 10+ 1-) 13https://github.com/crawl/crawl/commit/c3491426b6b5 16:27:56 this message is for you. THANK YOU THANK YOU for gell's gavotte working on formicid. It may be the most incredible spell in the game. God bless you God AND you devs and may this never be changed 16:38:26 Unstable branch on underhound.eu updated to: 0.33-a0-519-gc3491426b6 (34) 18:06:12 03DracoOmega02 07* 0.33-a0-520-g0c05a917f8: Fix beams not being properly bouncy (ragingrage, pisaster) 10(84 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/0c05a917f8b6 18:06:49 <04d​racoomega> twelwe: Glad you're enjoying it! ^^ 18:23:27 <04d​racoomega> Incidentally, if anyone is up for taking a look at this at any point, we may have another highly system-specific crash: https://github.com/crawl/crawl/issues/4152 (There is a save file that is a reliable crash trigger for the reporter, and WizardIke could reproduce from at least one distro, but I can't myself on either WSL or Windows tiles. The highly-variable behavior reported is... worrisome. >.>) 20:12:54 <03i​mplojin> playing around with this save after building 0.32 and it's not replicating for me (am running manjaro 6.10) 20:13:33 <03i​mplojin> wonder if it's something specific to manjaro's crawl-tiles package given wizardike's response 20:19:31 <03i​mplojin> at a glance the listed deps of this package look wrong, who knows what else it's doing 23:35:21 Unstable branch on crawl.develz.org updated to: 0.33-a0-520-g0c05a917f8 (34) 23:57:50 Windows builds of master branch on crawl.develz.org updated to: 0.33-a0-520-g0c05a917f8