00:05 <+bridge> [ddnet] I saw him on ddnet last time 00:05 <+bridge> [ddnet] So he isnt namebanned 00:10 <+bridge> [ddnet] @snail swap nameban with snail did 9/11 00:11 <+bridge> [ddnet] too political 00:14 <+bridge> [ddnet] Is the ball mod for 0.6 available? 00:17 <+bridge> [ddnet] https://github.com/scosu/teeworlds/tree/ball0.6.1 00:18 <+bridge> [ddnet] Yea I know for 0.6.1 00:18 <+bridge> [ddnet] but I mean a up to date ball mod 00:26 <+bridge> [ddnet] did you mean 0.7? 00:48 <+bridge> [ddnet] Nah I mean for 0.6.5 00:49 <+bridge> [ddnet] or for 0.7 idc 01:17 <+bridge> [ddnet] all the ball servers use that source i think 02:08 <+bridge> [ddnet] @Learath2 what the difference between git bash and git cmd? 09:38 <+bridge> [ddnet] @Arseniy Zarche git bash uses msys to give you a unix like environment, like all the usual things, grep, sed, awk, rm, cp 09:38 <+bridge> [ddnet] Git cmd just puts git tools in your path before launching cmd 09:55 <+ZillyHuhn> @Learath2 send brain 09:56 <+ZillyHuhn> https://github.com/ddnet/ddnet/pull/2256#issuecomment-643586537 09:56 <+ZillyHuhn> how to i print the netobj? 09:56 <+ZillyHuhn> u want the int Type? 09:57 <+bridge> [ddnet] <αΆ°Β°KonΝ§sti> ChillerDragon when come to 0.6 again, Shocktsunami soon :feelsbadman: 10:00 <+ZillyHuhn> nice is the rls finally progressing? o.O 10:00 <+ZillyHuhn> hope ddnet siwtched to 0.7 already when its rlsd 10:00 <+ZillyHuhn> u unbanned btw? 10:03 <+bridge> [ddnet] ZillyHuhn: Yeah I want int Type 10:03 <+bridge> [ddnet] I'm assuming it's failing at `Type < 0` 10:03 <+bridge> [ddnet] if it's not can you find where the unpack is failing? 10:05 <+ZillyHuhn> https://github.com/ZillyWoods/ZillyWoods/blob/b71ec28076ec6615342c9683f9c8672181be6023/src/engine/shared/snapshot.cpp#L440 10:05 <+ZillyHuhn> oh wp vscode 10:05 <+ZillyHuhn> worng link :D 10:05 <+ZillyHuhn> https://github.com/ZillyWoods/ZillyWoods/blob/b71ec28076ec6615342c9683f9c8672181be6023/src/engine/shared/snapshot.cpp#L431 10:05 <+ZillyHuhn> SnapSize is -3 10:06 <+bridge> [ddnet] eeeh? really? 10:06 <+ZillyHuhn> https://zillyhuhn.com/cs/.1592035565.png 10:06 <+bridge> [ddnet] can you add a debug statement on the server to check what it's sending? 10:06 <+ZillyHuhn> type=72 btw 10:07 <+ZillyHuhn> btw how is it that u cant reproduce? 10:07 <+bridge> [ddnet] snapshot.cpp:L638 print Type ID and Size 10:07 <+bridge> [ddnet] That's what's weird 10:07 <+ZillyHuhn> is it some mac feature to fix tw snaps? 10:08 <+bridge> [ddnet] maybe some undefined behaviour that clang decided to fix and gcc decides to optimize around 10:08 <+bridge> [ddnet] it's a common occurance 10:08 <+ZillyHuhn> yea probably 10:09 <+bridge> [ddnet] type 72 sounds insane so I'm guessing some broken size is being sent for previous objects 10:10 <+ZillyHuhn> https://paste.zillyhuhn.com/lZ 10:10 <+bridge> [ddnet] These snapshot issues are extremely annoying to fix 10:10 <+ZillyHuhn> here is what the server sends 10:10 <+ZillyHuhn> wanna ssh into mi machine? 10:10 <+bridge> [ddnet] can I connect to this server? 10:10 <+ZillyHuhn> nah its local 10:10 <+bridge> [ddnet] Oh actually ssh would be nice 10:10 <+ZillyHuhn> i can make a public one if u want 10:11 <+ZillyHuhn> send ur ssh key 10:11 <+bridge> [ddnet] the server actually seems to send that 72 10:49 <+bridge> [ddnet] I hoped it'd happen for me to if I used a release build, but nope 😦 10:50 <+bridge> [ddnet] lets see if gcc makes it happen 10:50 <+ZillyHuhn> yea ima get some breakfast feel free to hop into my machine later tho 10:54 <+bridge> [ddnet] oh forgot I build with clang on my vm too 10:55 <+bridge> [ddnet] yeah no, gcc with a release build doesn't make it happen either 11:07 <+bridge> [ddnet] I tested with GCC and an old TW 0.7 client version btw 11:07 <+bridge> [ddnet] self compiled, all in Debug 11:08 <+bridge> [ddnet] I used current master of 0.7 but I don't remember a change that'd influence this 11:10 <+bridge> [ddnet] ah finally got it to happen with gcc 11:11 <+bridge> [ddnet] so I guess it's UB 😦 11:13 <+ZillyHuhn> think its more a server thing i could reproduce it with old and new clients 11:13 <+ZillyHuhn> well its obviously a server thing :D 11:56 <+bridge> [ddnet] so unpleasant to debug 11:57 <+bridge> [ddnet] are you sure you dont send any wrong snapshots? 11:57 <+bridge> [ddnet] snapshots that are meant for the 0.6 clients only for example 11:57 <+bridge> [ddnet] Well compiling with clang fixes it, so it's doubtful that I'm doing something obviously wrong 12:00 <+bridge> [ddnet] besides the unknown objects should just be dropped, no? 12:05 <+bridge> [ddnet] hm the snap just looks truncated, very confused 12:24 <+bridge> [ddnet] my terminal just doesn't have enough scroll buffer to debug this πŸ˜› 12:58 <+bridge> [ddnet] full screen it 13:00 <+bridge> [ddnet] @fokkonaut do you happen to know why we are looking for `ItemSize` space in the snap but only end up incrementing data by `ItemSize/4`? 13:01 <+bridge> [ddnet] eh 13:01 <+bridge> [ddnet] what 13:01 <+bridge> [ddnet] https://discord.com/channels/252358080522747904/293493549758939136/721302168493097031 13:01 <+bridge> [ddnet] `if(RangeCheck(pEnd, pData, ItemSize) || ItemSize < 0) return -3;` Range check checks whether we have `ItemSize` bytes left in the snap 13:01 <+bridge> [ddnet] but we only do `pData += ItemSize/4;` 13:02 <+bridge> [ddnet] I am not familiar with that code, sorry :/ 13:02 <+bridge> [ddnet] seems no one is, matricks wrote it and it has been sitting there for the last decade πŸ˜„ 13:02 <+bridge> [ddnet] maybe when @heinrich5991 is around, he can give me a clue 13:03 <+bridge> [ddnet] xD 13:03 <+bridge> [ddnet] heinrich should know about it 13:03 <+bridge> [ddnet] Is this a client problem or server? 13:03 <+bridge> [ddnet] server 13:04 <+bridge> [ddnet] when compiled with gcc it does something wrong with the snap 13:05 <+bridge> [ddnet] I dont have a clue, but an idea is to check your character snap handling. I think you do it differently than I do 13:06 <+bridge> [ddnet] I dont get any errors, not on a 0.7 client, not on ddnet Client and also not on the server 13:06 <+bridge> [ddnet] well duh, It's from scratch it is supposed to be different 13:06 <+bridge> [ddnet] true 13:06 <+bridge> [ddnet] does this error occur while using ddnet or 0.7 client? 13:06 <+bridge> [ddnet] Yeah I have a feeling it's the character snap too 13:06 <+bridge> [ddnet] 0.7 13:07 <+bridge> [ddnet] Yep, then i am pretty sure 13:07 <+bridge> [ddnet] on a broken server the character doesn't get snapped at all, I don't get an object of type 10 13:07 <+bridge> [ddnet] Mh 13:07 <+bridge> [ddnet] No on a working one I don't get a character snap 13:07 <+bridge> [ddnet] wtf 13:07 <+bridge> [ddnet] why do you do it the way you do it 13:07 <+bridge> [ddnet] With the cast and all that 13:08 <+bridge> [ddnet] The way you had it before was correct 13:08 <+bridge> [ddnet] what cast? 13:09 <+bridge> [ddnet] The whole point of importing the protocol is to avoid using the ugly offsets into snap objects 13:09 <+bridge> [ddnet] https://github.com/ddnet/ddnet/commit/fbeec8a750510d98df15aa672cc184dd0c9cedde#diff-fcc0cc87472883c0ac01be250a1135b1R1171 13:09 <+bridge> [ddnet] oh, i see 13:10 <+bridge> [ddnet] But i guess the problem should be around this stuff 13:10 <+bridge> [ddnet] If I had any idea wtf is up with the snap sizes I could figure this out 13:10 <+bridge> [ddnet] https://gist.github.com/Learath2/1c19cc61227f1fab6b24c79b0380ba9ba 13:11 <+bridge> [ddnet] This is what a broken servers first snap looks like 13:11 <+bridge> [ddnet] 404 13:12 <+bridge> [ddnet] https://gist.github.com/Learath2/1c19cc61227f1fab6b24c79b0380ba9b 13:12 <+bridge> [ddnet] And this is a working one 13:12 <+bridge> [ddnet] https://gist.github.com/Learath2/a17040df98ffb85becf153cf18b1bc1c 13:13 <+bridge> [ddnet] mhh 13:13 <+bridge> [ddnet] notice how the working one is missing the actual character snap but it has the ddnetcharacter 13:13 <+bridge> [ddnet] so odd 13:14 <+bridge> [ddnet] i have an idea 13:15 <+bridge> [ddnet] Maybe you should pCore->Write(pCharacter) with the normal character from 0.6 13:15 <+bridge> [ddnet] Because the 0.7 character has a different size 13:16 <+bridge> [ddnet] Where you do the cast, i dont think thats needed 13:16 <+bridge> [ddnet] well wait 13:16 <+bridge> [ddnet] i am wrong 13:16 <+bridge> [ddnet] okay so 13:17 <+bridge> [ddnet] I am doing it the normal way, I just create the pCharacter with the normal size and also write that 13:18 <+bridge> [ddnet] then later on i change the values, but I dont write the 0.6 character (so for you, you shoudnt write the 0.7 one i think) 13:18 <+bridge> [ddnet] that reinterpret_cast is horrible there 13:18 <+bridge> [ddnet] let me get rid of that 13:18 <+bridge> [ddnet] maybe that'll help 13:18 <+bridge> [ddnet] I think you should just always create the 0.6 cnetobj_character 13:18 <+bridge> [ddnet] and always write that 13:19 <+bridge> [ddnet] And for 0.7 clients you just edit it. cast the pCharacter to a 07character and then set the vars for it i think? 13:20 <+bridge> [ddnet] Thats how i do it basically, but since i dont have the 0.6 protocol for my server, i need to do the offset thing 13:20 <+bridge> [ddnet] I can always create it, I can't always write it 13:21 <+bridge> [ddnet] Still a violation of strict aliasing, which is why I think this is breaking anyway 13:21 <+bridge> [ddnet] works for me 13:21 <+bridge> [ddnet] Yeah this works for me aswell 13:21 <+bridge> [ddnet] case closed 13:21 <+bridge> [ddnet] lets ship this and everyone just use clang 13:22 <+bridge> [ddnet] i wouldnt do that tbh 13:22 <+bridge> [ddnet] ofc not... 13:22 <+bridge> [ddnet] xd 13:23 <+bridge> [ddnet] I was trying to make the point that "works for me" is not a great bar 13:28 <+bridge> [ddnet] it's not the cast but will change that anyway 13:35 <+bridge> [ddnet] oh the 4 is because of using ints 13:36 <+bridge> [ddnet] Imagine iterating your binary protocol with a pointer to a non-fixed size 13:59 <+bridge> [ddnet] okay, now it disappeared with a debug build 14:00 <+bridge> [ddnet] maybe valgrind will bless me with the answer 14:13 <+bridge> [ddnet] pf even more broke and I didn't even touch anything 14:19 <+bridge> [ddnet] @timakro you ever here anymore? πŸ˜„ 14:28 <+bridge> [ddnet] > @Arseniy Zarche git bash uses msys to give you a unix like environment, like all the usual things, grep, sed, awk, rm, cp 14:28 <+bridge> [ddnet] @Learath2 too much nonunderstandable words for me but thanks. Will book say me about this? 14:29 <+bridge> [ddnet] I don't think it mentions git bash 14:29 <+bridge> [ddnet] msys is a unix environment that works in windows, it gives you the tools that you'd have on linux on windows 14:29 <+bridge> [ddnet] that's it 14:32 <+bridge> [ddnet] I should have used valgrind at the very beginning... 14:58 <+bridge> [ddnet] `-fsanitize=undefined` is also a godsend 15:35 <+bridge> [ddnet] @heinrich5991 you seem to have a uninitialized use in aio_write 15:41 <+bridge> [ddnet] @Learath2 omg what is it? 15:41 <+bridge> [ddnet] is this the bug I've been wondering about for a couple of years? 15:42 <+bridge> [ddnet] I'm trying to get a clean backtrace 15:42 <+bridge> [ddnet] you can check it out if you have clang with `-fsanitize=memory` 15:42 <+bridge> [ddnet] what do you need to do to trigger it? just starting the server? 15:43 <+bridge> [ddnet] yep 15:44 <+bridge> [ddnet] ```[vagrant@archlinux cross]$ ./DDNet-Server "sv_register 0" 15:44 <+bridge> [ddnet] [2020-06-13 13:44:03][engine]: running on unix-linux-amd64 15:44 <+bridge> [ddnet] [2020-06-13 13:44:03][engine]: arch is little endian 15:44 <+bridge> [ddnet] Uninitialized bytes in __interceptor_fwrite at offset 0 inside [0x7f9b4d71fe50, 112) 15:44 <+bridge> [ddnet] ==8666==WARNING: MemorySanitizer: use-of-uninitialized-value 15:44 <+bridge> [ddnet] #0 0x560f435119ba in io_write /vagrant/ddnet/cross/../src/base/system.c:341:9 15:44 <+bridge> [ddnet] #1 0x560f435119ba in aio_thread /vagrant/ddnet/cross/../src/base/system.c:483:3 15:44 <+bridge> [ddnet] #2 0x560f435135ac in thread_run /vagrant/ddnet/cross/../src/base/system.c:697:2 15:44 <+bridge> [ddnet] #3 0x7f9b4fdd1421 in start_thread (/usr/lib/libpthread.so.0+0x9421) 15:44 <+bridge> [ddnet] #4 0x7f9b4fcdebf2 in clone (/usr/lib/libc.so.6+0xffbf2) 15:44 <+bridge> [ddnet] 15:44 <+bridge> [ddnet] SUMMARY: MemorySanitizer: use-of-uninitialized-value /vagrant/ddnet/cross/../src/base/system.c:341:9 in io_write 15:44 <+bridge> [ddnet] Exiting 15:44 <+bridge> [ddnet] ==8666==WARNING: MemorySanitizer: use-of-uninitialized-value``` 15:45 <+bridge> [ddnet] this might be the bug we've been hitting on windwos 15:46 <+bridge> [ddnet] io_write is inlined too well so I can't see what is actually uninitialized 15:46 <+bridge> [ddnet] `[0x7f9b4d71fe50, 112)` 15:46 <+bridge> [ddnet] do you know what that means? 15:46 <+bridge> [ddnet] does that mean in a memory region of 112 bytes starting at 0x7f...? 15:47 <+bridge> [ddnet] Yes, not including the 112th byte 15:47 <+bridge> [ddnet] what is 112 bytes long even 15:48 <+bridge> [ddnet] let me try at O0 15:48 <+bridge> [ddnet] if it doesn't disappear 15:50 <+bridge> [ddnet] ASYNCIO is 88 bytes long on my machine 15:51 <+bridge> [ddnet] takes a while to instrument code on a 1 core vm :/ 15:53 <+bridge> [ddnet] oh cmake forces -O2 somewhy 15:53 <+bridge> [ddnet] helo 15:54 <+bridge> [ddnet] is there a way to get an animated text (from after effects for example) into a tw map? 15:55 <+bridge> [ddnet] I don't think I've ever heard of something like that 15:56 <+bridge> [ddnet] @Learath2 by default it uses the release config which includes `-O3`(?) or `-O2` 15:58 <+bridge> [ddnet] For release it adds -O3 15:58 <+bridge> [ddnet] idk how to override it 15:59 <+bridge> [ddnet] remove the forced `CMAKE_BUILD_TYPE` in CMakeLists.txt or build with `-DDEV=ON` or `-DCMAKE_BUILD_TYPE=Debug` 15:59 <+bridge> [ddnet] `-DCMAKE_C_FLAGS_DEBUG` helped 16:00 <+bridge> [ddnet] ah, if that helped, only my first hint has a chance of working 16:01 <+bridge> [ddnet] noooo with -O1 there is another bug that happens first 16:01 <+bridge> [ddnet] also in asyncio? 😦 16:01 <+bridge> [ddnet] in the uuid manager 16:01 <+bridge> [ddnet] :(( 16:01 <+bridge> [ddnet] https://gist.github.com/Learath2/327d000bccd365769066a3948d106b1c 16:03 <+bridge> [ddnet] how though? I don't understand it 16:04 <+bridge> [ddnet] this is now `-O1` with `clang -fsanitize=memory`? 16:04 <+bridge> [ddnet] and `-fno-optimize-sibling-calls` 16:05 <+bridge> [ddnet] `CFLAGS="-fsanitize=memory -fno-optimize-sibling-calls" CXXFLAGS="-fsanitize=memory -fno-optimize-sibling-calls" LDFLAGS="-fsanitize=memory" CC="clang" CXX="clang++" cmake -GNinja -DCLIENT=OFF -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS_DEBUG="-g -O1" -DCMAKE_CXX_FLAGS_DEBUG="-g -O1" ..` 16:05 <+bridge> [ddnet] That was how I configured it 16:05 <+ZillyHuhn> @jimmy take the after effects animation and create each frame as a image and then use alpha evelopes to play it frame by frame in the map 16:06 <+bridge> [ddnet] and relwithdebinfo has yet another one at `-g -O1` so 3 uninitialized uses 16:06 <+bridge> [ddnet] I'm wondering if MSan is broken πŸ˜› 16:06 <+bridge> [ddnet] newest ddnet? 16:07 <+bridge> [ddnet] yep 16:12 <+bridge> [ddnet] ``` 16:12 <+bridge> [ddnet] ../src/game/collision.cpp:902:247: warning: bitwise or with non-zero value always evaluates to true [-Wtautological-bitwise-compare] 16:12 <+bridge> [ddnet] if(m_pDoor[TileOnTheRight].m_Index == TILE_STOPA || m_pDoor[TileOnTheLeft].m_Index == TILE_STOPA || ((m_pDoor[TileOnTheRight].m_Index == TILE_STOPS || m_pDoor[TileOnTheLeft].m_Index == TILE_STOPS) && m_pDoor[TileOnTheRight].m_Flags|ROTATION_270|ROTATION_90)) 16:12 <+bridge> [ddnet] ``` 16:12 <+bridge> [ddnet] RelWithDebInfo has an uninitialized use in LoadMap leading to digest_str 16:12 <+bridge> [ddnet] Debug has one in uuid manager 16:12 <+bridge> [ddnet] RelWithDebInfo at -O2 has one in io_write 16:12 <+bridge> [ddnet] I think those warnings already have an issue 16:17 <+bridge> [ddnet] If you want MemorySanitizer to work properly and not produce any false positives, you must ensure that all the code in your program and in libraries it uses is instrumented (i.e. built with -fsanitize=memory). In particular, you would need to link against MSan-instrumented C++ standard library. We recommend to use libc++ for that purpose. 16:17 <+bridge> [ddnet] Ah I left now but I bet trace origins would help 16:17 <+bridge> [ddnet] Msan has an exception for libc 16:17 <+bridge> [ddnet] It has interceptors 16:18 <+bridge> [ddnet] yea, currently building with `-fsanitize-memory-track-origins=2` 16:18 <+bridge> [ddnet] libc++ im not sure if they have interceptors for those, maybe you do need an instrumented libc++ 16:18 <+bridge> [ddnet] `Uninitialized value was created by an allocation of 'retval' in the stack frame of function 'md5_finish'` 16:18 <+bridge> [ddnet] sounds like a false positive 16:21 <+bridge> [ddnet] Could be, can you reproduce the one in aio_write? 16:22 <+bridge> [ddnet] which flags do I need for that again? 16:22 <+bridge> [ddnet] RelWithDebInfo and just fsanitize=memory 16:22 <+bridge> [ddnet] I think relwithdebinfo defaults to o2 16:36 <+bridge> [ddnet] hm 16:37 <+bridge> [ddnet] it tells me the buffer is wholly uninitialized, but it contains the bytes I'm expecting it to contain 16:41 <+bridge> [ddnet] Hm I wonder what's wrong with it, it should be using a pattern 16:43 <+bridge> [ddnet] 112 is precisely the length even. maybe the variable just happens to still contain the bytes? 16:44 <+bridge> [ddnet] Thatd be some luck 16:46 <+bridge> [ddnet] note that we also had problems with bytes marked as uninitialized on windows 16:46 <+bridge> [ddnet] so maybe there's more to it 16:46 <+bridge> [ddnet] but I don't understand it ← that might well be the problem ^^ 16:48 <+bridge> [ddnet] Well the issue is very subtle on windows too, subtle enough to make it all the way to ntkernel before crashing 17:11 <+bridge> [ddnet] you know, I wonder how the world fits together 17:11 <+bridge> [ddnet] on the one hand we have this issue in code I wrote, with an memsan and (back then) windows reporting a problem 17:11 <+bridge> [ddnet] and we can't figure it out 17:12 <+bridge> [ddnet] on the other hand one can go to ctf challenges and figure out bugs in a closed source or extremely undocumented software 18:01 <+bridge> [ddnet] :D 19:06 <+bridge> [ddnet] @Learath2 Hi 19:08 <+bridge> [ddnet] Hi, I was having big trouble, but I figured it out 20:46 <+bridge> [ddnet] @timakro have you seen my pr btw? It'd be nice to have a review as you were the first one to implement this