08:25 < ws-client> **<ChillerDragon>** yea all servers hexagoupled ram usage over night just the gperf server did not increase by a single bit
08:26 < ws-client> **<ChillerDragon>** i wonder if my old friend `2025-12-07 00:19:40 I mysql: can't free last result (free_result:stmt:5025): Statement has no result set` is related
08:26 < ws-client> **<ChillerDragon>** @blaiszephyr u figured it out? xd
08:26 < ws-client> **<ChillerDragon>** is there a chance than asan+gdb causes memleaks on its own?
08:27 < ws-client> **<ChillerDragon>** ah wait never mind i even had a test server running without asan gdb or gperf and it leaked too
08:35 < bridge> <0xdeen> Sounds like you don't have a memory leak, but some data structure that keeps growing but isn't supposed to
08:35 < ws-client> **<ChillerDragon>** yea i think so too i keep calling it a leak tho :D
08:36 < ws-client> **<ChillerDragon>** or do you have a sexy term to replace it?
08:36 < bridge> <0xdeen> So the memory is still reachable, you could use something like massif and keep it running for a while to check where the memory is used
08:36 < ws-client> **<ChillerDragon>** memory hog? xd
08:36 < ws-client> **<ChillerDragon>** i was hoping gperf would do that
08:37 < ws-client> **<ChillerDragon>** but since its not collecting memory with it i might actually try massif next
08:37 < bridge> <0xdeen> > gperf is a perfect hash function generator
08:37 < bridge> <0xdeen> ?
08:37 < ws-client> **<ChillerDragon>** ah wait
08:37 < ws-client> **<ChillerDragon>** the link robsi sent its some google tool sec
08:37 < ws-client> **<ChillerDragon>** https://gperftools.github.io/gperftools/heapprofile.html
08:38 < ws-client> **<ChillerDragon>** looks similar to massif its also just some kind of profiler
08:38 < ws-client> **<ChillerDragon>** its just every time i am watching the memory stays low :D 
08:38 < ws-client> **<ChillerDragon>** but im not giving up yet!
08:38 < bridge> <0xdeen> Yeah, tcmalloc can do that, jemalloc too. Maybe a race condition
08:38 < ws-client> **<ChillerDragon>** i even dumped the ram once :D 
08:39 < ws-client> **<ChillerDragon>** turns out i had 321489 occurences of the string `1(i0` in my ram. not sure what that means xd
10:42 < bridge> <Assa> hmm what process even safes new strings
10:44 < bridge> <Assa> thats the wrong approach probably
11:09 < ws-client> **<ChillerDragon>** its raw ram so it might not be a string just something that happens to be representable as string
11:09 < ws-client> **<ChillerDragon>** pushing into an vector of std::strings does that 
11:35 < bridge> <blaiszephyr> no D:
11:35 < bridge> <blaiszephyr> i gave up after spending close to 10 hours on finding the cure
12:14 < bridge> <chillerdragon> @sedonya: new big ass pr
12:14 < bridge> <chillerdragon> 1k commits again just 3 days later lol
12:20 < ws-client> **<ChillerDragon>** yea looks like massif is also not collecting ram -.
12:32 < bridge> <learath2> Wdym not collecting ram?
12:32 < bridge> <chillerdragon> Its usage doesn’t grow when observed
12:33 < bridge> <learath2> Ah a heisenbug, yeah have fun 😄
12:35 < bridge> <learath2> Map changes maybe?
12:41 < bridge> <learath2> I’d just try the tcmalloc heap profiler I guess, massif has massive overhead. Just let it run with tcmalloc until it does one day leak, then get a profile with a signal
12:42 < bridge> <milkeeycat> massif has... *massif* overhead ba dum tsss
12:42 < bridge> <milkeeycat> massif has... *massif* overhead. ba dum tsss
12:54 < bridge> <sedonya> Thank you, the last PR will be especially useful, check wire
12:55 < ws-client> **<ChillerDragon>** massif and tcmalloc both fix the leak tho
12:56 < ws-client> **<ChillerDragon>** i run both right now
12:56 < bridge> <learath2> Are you sure they “fix” it? Is it immediately obvious that the memory usage gets higher without them?
12:56 < ws-client> **<ChillerDragon>** yes
12:57 < ws-client> **<ChillerDragon>** other servers rise to 11% memory usage in a day
12:57 < ws-client> **<ChillerDragon>** this one is flat at 0.8% since yesterday
12:57 < ws-client> **<ChillerDragon>** but ye maybe im impatient
12:57 < bridge> <learath2> And people played on the server?
12:57 < ws-client> **<ChillerDragon>** ima wait a few more days
12:58 < ws-client> **<ChillerDragon>** servers i thought were empty also collected but i dont have proper statistics
12:58 < ws-client> **<ChillerDragon>** im a bit scared at some point my vps dies with full disk because of all this logging xd
12:59 < bridge> <learath2> I mean either of those things “fixing” something like this is a tad on the insane side. Some weird race condition, or maybe a bug inside glibc somehow. You can I guess also dump out the heap from a server that has grown in memory usage and just stare at it real hard
13:00 < ws-client> **<ChillerDragon>** i dumped the heap
13:00 < ws-client> **<ChillerDragon>** but not sure what im looking at xd
13:01 < ws-client> **<ChillerDragon>** i looked at strings xd https://github.com/ddnet-insta/ddnet-insta/issues/267#issuecomment-3620627728
13:01 < bridge> <learath2> Yeah it would be quite hard to figure out what where is just by looking at it, you are sort of hoping for obvious stuff like strings around e.g.
13:02 < ws-client> **<ChillerDragon>** thats where heinrichs gdb command comes into play
13:02 < ws-client> **<ChillerDragon>** if he can patch maps with gdb while a tournament is running he can also tell me which code allocated all the ram
13:03 < bridge> <learath2> He can’t, that information is not tracked
13:03 < ws-client> **<ChillerDragon>** sadge
13:03 < ws-client> **<ChillerDragon>** if only there was still magnuses memory manager
13:03 < bridge> <learath2> That’s what the profilers do, they instrument free/malloc/new then keep track of what allocated what
13:03 < ws-client> **<ChillerDragon>** in the good old days there was no `std::` or `new` and `delete`
13:04 < bridge> <learath2> That’s what the profilers do, they instrument free/malloc/new/delete then keep track of what allocated what
13:04 < ws-client> **<ChillerDragon>** there was the teeworlds engine memory allocator
13:04 < bridge> <learath2> We used to avoid heap memory like the plague 😄
13:04 < ws-client> **<ChillerDragon>** should go back to that
13:05 < ws-client> **<ChillerDragon>** okay i will slap profiler on my most played on server now
13:05 < ws-client> **<ChillerDragon>** tcmalloc or massif?
13:05 < ws-client> **<ChillerDragon>** or memcheck?
13:06 < ws-client> **<ChillerDragon>** massif it is
13:07 < bridge> <learath2> Your dump memory script you used seems to dump way more than just the heap btw
13:07 < ws-client> **<ChillerDragon>** oke xd
13:07 < ws-client> **<ChillerDragon>** ye it took forver to dump
13:07 < ws-client> **<ChillerDragon>** and contained all sorts of nudes
13:07 < bridge> <learath2> Maybe just dump the heap and you might find patterns easier, we are pretty much sure it’s not something else that is leaking
13:08 < ws-client> **<ChillerDragon>** wat about stack leak?
13:08 < bridge> <learath2> Stack can’t really “leak”
13:08 < ws-client> **<ChillerDragon>** also idk how to only dump heap i copied this from stackoverflow
13:08 < ws-client> **<ChillerDragon>** @learath2 tell that to my assembly code xd
13:09 < bridge> <learath2> In /proc/<pid>/maps there is a memory region marked [heap]
13:09 < bridge> <learath2> Maybe you can just add a `grep heap` to the script you used right before the sed 😄
13:10 < ws-client> **<ChillerDragon>** lel lemme try
13:11 < bridge> <learath2> Also another question, does it keep growing as you keep the server on?
13:11 < ws-client> **<ChillerDragon>** yes
13:11 < ws-client> **<ChillerDragon>** until OOM
13:12 < bridge> <learath2> Ok, just wanted to make sure, because it just could have been the max size and for whatever reason glibc malloc just wasn’t feeling like returning the memory to the OS
13:13 < bridge> <aegisub> just restart the server every 10 finishes
13:13 < bridge> <learath2> Ok these are all the easy-ish ideas I can think of rn, so try all these and if you still can’t find it we can talk about patching glibc to hack in a profiler 😛
13:13 < ws-client> **<ChillerDragon>** i wonder how feasible it is to just look at the code xd
13:14 < bridge> <learath2> I really can’t imagine it not happening under massif though, the way it hooks stuff it shouldn’t ever change behaviour unless a race is involved
13:14 < ws-client> **<ChillerDragon>** yea lets give it another day to grow
13:14 < bridge> <learath2> If you can find a version where it doesn’t happen, you can bisect for it
13:15 < ws-client> **<ChillerDragon>** bisecting will be uselessly slow tho
13:15 < ws-client> **<ChillerDragon>** i cant detect it on launch
13:15 < bridge> <learath2> I mean if it’s like 30 commits it will only take you 5 days 😄
13:16 < ws-client> **<ChillerDragon>** i cant really run non forward compatible breaking db changes
13:16 < ws-client> **<ChillerDragon>** oh there is only one heap segment
13:16 < ws-client> **<ChillerDragon>** much faster
13:16 < bridge> <learath2> Also you can stare at the changes between the 2 commits if you do find one good commit
13:16 < ws-client> **<ChillerDragon>** also it doesnt seem to need root idk why once i got permission errors
13:17 < bridge> <learath2> Probably because you tried to dump the vdso
13:17 < ws-client> **<ChillerDragon>** yea i think diff isnt the way i noticed the first mem leak in feb
13:19 < ws-client> **<ChillerDragon>** https://paste.zillyhuhn.com/e5
13:19 < ws-client> **<ChillerDragon>** cant make any sense out of it
13:22 < bridge> <learath2> I doubt just looking at strings would work in this case, you’ll need to get in there with a hex editor, maybe some statistical analysis to look for repeating patterns of bytes
13:22 < bridge> <learath2> Gtg, need to craft food
13:26 < bridge> <patiga> Please check out https://twmap.patiga.eu/info and https://twmap.patiga.eu/fix, two twmap tools to get some infos about a map and to fix maps which are not loadable by tmwap. The web pages are again static, so your maps aren't uploaded to anywhere :)
13:36 < bridge> <milkeeycat> can someone with good cpu run my today's aoc code, it takes too much time on my laptop xdd
13:37 < ws-client> **<ChillerDragon>** send
13:38 < ws-client> **<ChillerDragon>** or push i guess https://github.com/MilkeeyCat/aoc
13:39 < ws-client> **<ChillerDragon>** i need input too
13:39 < bridge> <milkeeycat> Here's `input` file
13:39 < bridge> <milkeeycat> https://cdn.discordapp.com/attachments/293493549758939136/1447205926300942457/message.txt?ex=6936c70c&is=6935758c&hm=1027c597b1e988a9863853a6ee815601a91c4869ec48e7df371a5c7636c277d4&
13:39 < ws-client> **<ChillerDragon>** both parts?
13:40 < bridge> <milkeeycat> part 2 xd
13:41 < ws-client> **<ChillerDragon>** it uses 1 core bruv
13:41 < ws-client> **<ChillerDragon>** thats why i focussed on single core speed when selecting a cpu xd
13:43 < ws-client> **<ChillerDragon>** where loading bar xd
13:43 < bridge> <milkeeycat> hm?
13:44 < ws-client> **<ChillerDragon>** i see no progress xd
13:44 < bridge> <milkeeycat> me neither
13:44 < bridge> <milkeeycat> it's been 20 mins and it's still running
13:44 < bridge> <milkeeycat> i hope it doesn't have a bug xd
13:48 < ws-client> **<ChillerDragon>** idk if this is going anywhere
13:48 < ws-client> **<ChillerDragon>** i tried to add dbg prints to build progress bar but recursion is too complicated xd
13:51 < ws-client> **<ChillerDragon>** i tried to print the depth and it only seems to be growing xd
13:51 < ws-client> **<ChillerDragon>** u sure this works?
13:51 < bridge> <milkeeycat> it works on a simple input 
13:51 < bridge> <milkeeycat> ```
13:52 < bridge> <milkeeycat> .......S.......
13:52 < bridge> <milkeeycat> ...............
13:52 < bridge> <milkeeycat> .......^.......
13:52 < bridge> <milkeeycat> ...............
13:52 < bridge> <milkeeycat> ......^.^......
13:52 < bridge> <milkeeycat> ...............
13:52 < bridge> <milkeeycat> .....^.^.^.....
13:52 < bridge> <milkeeycat> ...............
13:52 < bridge> <milkeeycat> ....^.^...^....
13:52 < bridge> <milkeeycat> ...............
13:52 < bridge> <milkeeycat> ...^.^...^.^...
13:52 < bridge> <milkeeycat> ...............
13:52 < bridge> <milkeeycat> ..^...^.....^..
13:52 < bridge> <milkeeycat> ...............
13:52 < bridge> <milkeeycat> .^.^.^.^.^...^.
13:52 < bridge> <milkeeycat> ...............
13:52 < bridge> <milkeeycat> ```
13:54 < ws-client> **<ChillerDragon>** wait
13:54 < ws-client> **<ChillerDragon>** i got progress bar
13:56 < ws-client> **<ChillerDragon>** okay i restarted run
13:56 < ws-client> **<ChillerDragon>** its already declining the depth
13:56 < ws-client> **<ChillerDragon>** so only 18446744073702000000 left to go
13:57 < bridge> <milkeeycat> :justatest: t
13:57 < bridge> <milkeeycat> :justatest:
13:57 < ws-client> **<ChillerDragon>** number looks big tho
13:57 < ws-client> **<ChillerDragon>** 18446744073666000000
13:57 < ws-client> **<ChillerDragon>** 18446744073660000000
13:57 < ws-client> **<ChillerDragon>** 18446744073653000000
13:58 < ws-client> **<ChillerDragon>** 18446744073644000000
13:58 < bridge> <01000111g> is aoc fun?
13:58 < ws-client> **<ChillerDragon>** im not that strong in maffs stuff
13:59 < ws-client> **<ChillerDragon>** but i have the feeling that this wont finish fast enuff
13:59 < bridge> <milkeeycat> These numbers are suspiciously close to max size_t value -.-
13:59 < ws-client> **<ChillerDragon>** oh yea i used uint64_t for the counter xd
14:01 < ws-client> **<ChillerDragon>** oke i stopped now
14:02 < ws-client> **<ChillerDragon>** even perfect multi thread with 32x speed would not finish during my lifetime i guess
14:03 < bridge> <milkeeycat> Thanks for trying to run it :)
14:17 < bridge> <learath2> fwiw aoc rarely ever has computationally intensive questions from what I remember
14:18 < bridge> <milkeeycat> i wanted to get the answer using my stupid code, but it won't work with such a big input :\
14:18 < bridge> <learath2> your algorithm must be suboptimal, this looks like || it should be solved with dfs and memoization||
14:20 < bridge> <learath2> actually || dynamic programming is a better keyword here I guess||
14:22 < bridge> <milkeeycat> okay, I added an `std::unoredered_map` which stores previously computed values and it doesn't take ages(the answer is wrong tho xd)
14:22 < bridge> <learath2> something like || go down as far as you can, recurse at `^`s, remember stuff || 😄
14:22 < bridge> <learath2> something like || go down as far as you can, recurse left and right at `^`s, remember stuff || 😄
14:24 < bridge> <milkeeycat> ah, it doesn't work like that :p
14:29 < bridge> <learath2> ```cpp
14:29 < bridge> <learath2> size_t magic(std::vector<std::string> &Diagram, std::unordered_map<std::pair<size_t, size_t>, size_t> &memo, size_t i, size_t j) {
14:29 < bridge> <learath2>   if(auto s = memo.find(std::make_pair(i,j)); s != memo.end())
14:29 < bridge> <learath2>     return s.second;
14:30 < bridge> <learath2> 
14:30 < bridge> <learath2>   while(Diagram[i][j] == '.') {
14:30 < bridge> <learath2>     i++;
14:30 < bridge> <learath2>     if(i == Diagram.size()) {
14:30 < bridge> <learath2>       memo[std::make_pair(i, j)] = 1;
14:30 < bridge> <learath2>       return 1;
14:30 < bridge> <learath2>     }
14:30 < bridge> <learath2>   }
14:30 < bridge> <learath2>   return magic(i, j - 1) + magic(i, j + 1);
14:30 < bridge> <learath2> }
14:30 < bridge> <learath2> ```
14:30 < bridge> <learath2> 
14:30 < bridge> <learath2> I think this sounds about right to me
14:30 < bridge> <learath2> ```cpp
14:30 < bridge> <learath2> size_t magic(std::vector<std::string> &Diagram, std::unordered_map<std::pair<size_t, size_t>, size_t> &memo, size_t i, size_t j) {
14:30 < bridge> <learath2>   if(auto s = memo.find(std::make_pair(i,j)); s != memo.end())
14:30 < bridge> <learath2>     return s.second;
14:30 < bridge> <learath2> 
14:30 < bridge> <learath2>   while(Diagram[i][j] == '.') {
14:30 < bridge> <learath2>     i++;
14:30 < bridge> <learath2>     if(i == Diagram.size()) {
14:30 < bridge> <learath2>       memo[std::make_pair(i, j)] = 1;
14:30 < bridge> <learath2>       return 1;
14:30 < bridge> <learath2>     }
14:30 < bridge> <learath2>   }
14:30 < bridge> <learath2>   return magic(i, j - 1) + magic(i, j + 1);
14:30 < bridge> <learath2> }
14:30 < bridge> <learath2> ```
14:30 < bridge> <learath2> I think this sounds about right to me
14:30 < bridge> <learath2> ```cpp
14:30 < bridge> <learath2> size_t magic(std::vector<std::string> &Diagram, std::unordered_map<std::pair<size_t, size_t>, size_t> &memo, size_t i, size_t j) {
14:31 < bridge> <learath2>   if(auto s = memo.find(std::make_pair(i,j)); s != memo.end())
14:31 < bridge> <learath2>     return s.second;
14:31 < bridge> <learath2> 
14:31 < bridge> <learath2>   while(Diagram[i][j] == '.') {
14:31 < bridge> <learath2>     i++;
14:31 < bridge> <learath2>     if(i == Diagram.size()) {
14:31 < bridge> <learath2>       memo[std::make_pair(i, j)] = 1;
14:31 < bridge> <learath2>       return 1;
14:31 < bridge> <learath2>     }
14:31 < bridge> <learath2>   }
14:31 < bridge> <learath2> 
14:31 < bridge> <learath2>   size_t res = magic(i, j - 1) + magic(i, j + 1);
14:31 < bridge> <learath2>   memo[std::make_pair(i, j)] = res;
14:31 < bridge> <learath2>   return res;
14:31 < bridge> <learath2> }
14:31 < bridge> <learath2> ```
14:31 < bridge> <learath2> I think this sounds about right to me
14:31 < bridge> <learath2> Making a std unordered_map actually work with a std pair is left as an exercise to the reader 😛
14:31 < bridge> <learath2> ```cpp
14:31 < bridge> <learath2> size_t magic(std::vector<std::string> &Diagram, std::unordered_map<std::pair<size_t, size_t>, size_t> &memo, size_t i, size_t j) {
14:31 < bridge> <learath2>   if(auto s = memo.find(std::make_pair(i,j)); s != memo.end())
14:31 < bridge> <learath2>     return s.second;
14:31 < bridge> <learath2> 
14:31 < bridge> <learath2>   while(Diagram[i][j] == '.') {
14:31 < bridge> <learath2>     if(++i == Diagram.size()) {
14:31 < bridge> <learath2>       memo[std::make_pair(i, j)] = 1;
14:31 < bridge> <learath2>       return 1;
14:31 < bridge> <learath2>     }
14:32 < bridge> <learath2>   }
14:32 < bridge> <learath2> 
14:32 < bridge> <learath2>   size_t res = magic(i, j - 1) + magic(i, j + 1);
14:32 < bridge> <learath2>   memo[std::make_pair(i, j)] = res;
14:32 < bridge> <learath2>   return res;
14:32 < bridge> <learath2> }
14:32 < bridge> <learath2> ```
14:32 < bridge> <learath2> I think this sounds about right to me
14:32 < bridge> <learath2> Making a std unordered_map actually work with a std pair key is left as an exercise to the reader 😛
14:33 < bridge> <learath2> ||```cpp
14:33 < bridge> <learath2> size_t magic(std::vector<std::string> &Diagram, std::unordered_map<std::pair<size_t, size_t>, size_t> &memo, size_t i, size_t j) {
14:33 < bridge> <learath2>   if(auto s = memo.find(std::make_pair(i,j)); s != memo.end())
14:33 < bridge> <learath2>     return s.second;
14:33 < bridge> <learath2> 
14:33 < bridge> <learath2>   while(Diagram[i][j] == '.') {
14:33 < bridge> <learath2>     if(++i == Diagram.size()) {
14:33 < bridge> <learath2>       memo[std::make_pair(i, j)] = 1;
14:33 < bridge> <learath2>       return 1;
14:33 < bridge> <learath2>     }
14:33 < bridge> <learath2>   }
14:33 < bridge> <learath2> 
14:33 < bridge> <learath2>   size_t res = magic(i, j - 1) + magic(i, j + 1);
14:33 < bridge> <learath2>   memo[std::make_pair(i, j)] = res;
14:33 < bridge> <learath2>   return res;
14:33 < bridge> <learath2> }
14:33 < bridge> <learath2> ```||
14:33 < bridge> <learath2> I think this sounds about right to me
14:35 < bridge> <learath2> ||```cpp
14:35 < bridge> <learath2> size_t magic(std::vector<std::string> &Diagram, std::unordered_map<std::pair<size_t, size_t>, size_t> &memo, size_t i, size_t j) {
14:35 < bridge> <learath2>   if(auto s = memo.find(std::make_pair(i,j)); s != memo.end())
14:35 < bridge> <learath2>     return s.second;
14:35 < bridge> <learath2> 
14:35 < bridge> <learath2>   while(Diagram[i][j] == '.') {
14:35 < bridge> <learath2>     if(++i == Diagram.size()) {
14:35 < bridge> <learath2>       memo[std::make_pair(i, j)] = 1;
14:35 < bridge> <learath2>       return 1;
14:35 < bridge> <learath2>     }
14:35 < bridge> <learath2>   }
14:35 < bridge> <learath2> 
14:35 < bridge> <learath2>   size_t res = magic(Diagram, memo, i, j - 1) + magic(Diagram, memo, i, j + 1);
14:35 < bridge> <learath2>   memo[std::make_pair(i, j)] = res;
14:36 < bridge> <learath2>   return res;
14:36 < bridge> <learath2> }
14:36 < bridge> <learath2> ```||
14:36 < bridge> <learath2> I think this sounds about right to me
14:55 < bridge> <milkeeycat> https://github.com/MilkeeyCat/aoc/blob/2d1a9b833771e13bf3809fd9b5ff602e72a49bdb/2025/day7/part2.cpp#L10-L63 my solution is not that pretty but it works xd
14:56 < bridge> <milkeeycat> One `unordered_map` saved sooo much time
14:56 < bridge> <aegisub> I solved today's problem in excel so yeah
14:57 < bridge> <aegisub> you can just ||||
14:58 < bridge> <aegisub> you don't even need to ||memoize anything||, you can just ||assign a 1 to each of the bottom | characters and then go up from bottom to top, and sum the left and right "child" of each ^||
15:03 < bridge> <learath2> Yeah you can definitely do it || bottom up|| too 😄
16:31 < bridge> <Assa> @kebscs I think we should make a video for the release for the scoreboard
18:21 < bridge> <nyrrcly_> Weblate is awesome
18:21 < bridge> <nyrrcly_> https://cdn.discordapp.com/attachments/293493549758939136/1447276892703949012/image.png?ex=69370924&is=6935b7a4&hm=34af1f8c87ebc5c95cb3d699d19a46e88b09ca60bcb36df17511d15eb07986c8&
20:07 < bridge> <kebscs> there is 1 already
20:07 < bridge> <kebscs> what else from the one posted in #announcements
20:29 < bridge> <pioooooo> https://github.com/ddnet/ddnet/blob/050dbe925fc9046f69d2b3b7ad291328666ce650/src/game/client/components/menus_settings.cpp#L2768 
20:29 < bridge> <pioooooo> https://hosted.weblate.org/search/ddnet/ddnet/?q=show+background
23:07 < bridge> <Assa> spec is also now there, just more obscure, but 🤷‍♂️