












-fsanitize=undefined
UBSAN_OPTIONS=suppressions=./ubsan.supp:log_path=./SAN:print_stacktrace=1:halt_on_errors=0 ASAN_OPTIONS=log_path=./SAN:print_stacktrace=1:check_initialization_order=1:detect_leaks=1:halt_on_errors=0 LSAN_OPTIONS=suppressions=./lsan.supp ./DDNet
shared_ptrs of CServer::m_pDnsblLookup[ClientID] are set, but not cleaned up when done. Therefore the Job is kept alive until the player disconnects and a new player joins on that slot. Currently this means that the full linked list of jobs is kept alive.
When the Job is overwritten with a new job, all the remaining objects in the list can be dropped. With enough jobs, that is causing a stack overflow in the destructor.
This patch fixes this overflow by making the lifetime independe...
=================================================================
==22179==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 72704 byte(s) in 1 object(s) allocated from:
#0 0x558d9f5f9d1e in malloc (/data1/edgar/ddnet/build/DDNet+0x1325d1e)
#1 0x7f62ff140f65 (<unknown module>)
#2 0x7f62ff0c9caa (<unknown module>)
Direct leak of 6360 byte(s) in 5 object(s) allocated from:
#0 0x558d9f5f9e58 in calloc (/data1/edgar/ddnet/build/DDNet+0x1325e58)
#1 0x7f63135f2150 (<unknown module>)
Direct leak of 1152 byte(s) in 1 object(s) allocated from:
#0 0x558d9f5f9fe5 in realloc (/data1/edgar/ddnet/build/DDNet+0x1325fe5)
#1 0x7f63135f28e6 (<unknown module>)
Direct leak of 368 byte(s) in 3 object(s) allocated from:
#0 0x558d9f5f9d1e in malloc (/data1/edgar/ddnet/build/DDNet+0x1325d1e)
#1 0x7f63000a1377 (<unknown module>)
Direct leak of 176 byte(s) in 1 object(s) allocated from:
#0 0x558d9f5f9e58 in calloc (/data1/edgar/ddnet/build/DDNet+0x1325e58)
#1 0x7f631e9bfbde (/usr/lib64/libdbus-1.so.3+0x30bde)
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x558d9f5f9d1e in malloc (/data1/edgar/ddnet/build/DDNet+0x1325d1e)
#1 0x7f63135f1824 (<unknown module>)
Indirect leak of 164592 byte(s) in 521 object(s) allocated from:
#0 0x558d9f5f9e58 in calloc (/data1/edgar/ddnet/build/DDNet+0x1325e58)
#1 0x7f63135f2150 (<unknown module>)
Indirect leak of 9650 byte(s) in 264 object(s) allocated from:
#0 0x558d9f5f9d1e in malloc (/data1/edgar/ddnet/build/DDNet+0x1325d1e)
#1 0x7f62ffe40e53 (<unknown module>)
Indirect leak of 6156 byte(s) in 1 object(s) allocated from:
#0 0x558d9f5f9e58 in calloc (/data1/edgar/ddnet/build/DDNet+0x1325e58)
#1 0x7f62ffe5b8f5 (<unknown module>)
Indirect leak of 5791 byte(s) in 430 object(s) allocated from:
#0 0x558d9f5f9d1e in malloc (/data1/edgar/ddnet/build/DDNet+0x1325d1e)
#1 0x7f63135f1824 (<unknown module>)
Indirect leak of 5665 byte(s) in 17 object(s) allocated from:
#0 0x558d9f5f9d1e in malloc (/data1/edgar/ddnet/build/DDNet+0x1325d1e)
#1 0x7f63000a1377 (<unknown module>)
Indirect leak of 752 byte(s) in 6 object(s) allocated from:
#0 0x558d9f5f9fe5 in realloc (/data1/edgar/ddnet/build/DDNet+0x1325fe5)
#1 0x7f63135f28e6 (<unknown module>)
Indirect leak of 409 byte(s) in 2 object(s) allocated from:
#0 0x558d9f5f9fe5 in realloc (/data1/edgar/ddnet/build/DDNet+0x1325fe5)
#1 0x7f631e9d10ac (/usr/lib64/libdbus-1.so.3+0x420ac)
Indirect leak of 204 byte(s) in 1 object(s) allocated from:
#0 0x558d9f5f9e58 in calloc (/data1/edgar/ddnet/build/DDNet+0x1325e58)
#1 0x7f62ffe5b469 (<unknown module>)
Indirect leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x558d9f5f9d1e in malloc (/data1/edgar/ddnet/build/DDNet+0x1325d1e)
#1 0x7f62ffe4d5e0 (<unknown module>)
SUMMARY: AddressSanitizer: 274027 byte(s) leaked in 1255 allocation(s).











































VkPhysicalDeviceType it returns?VK_PHYSICAL_DEVICE_TYPE_CPU

[MainThread ] vulkan.cpp:2442 ERR| The only available GPU is of type VK_PHYSICAL_DEVICE_TYPE_CPU. Early exiting


[MainThread ] vulkan.cpp:2442 ERR| The only available GPU is of type VK_PHYSICAL_DEVICE_TYPE_CPU. Early exiting 






























MESA_VK_DEVICE_SELECT? I was under the impression that mesa wasn't even supposed to be in the path when using a physical device

MESA_VK_DEVICE_SELECT? I was under the impression that mesa wasn't even supposed to be in the path when using a physical device 




















MESA_VK_DEVICE_SELECT? I was under the impression that mesa wasn't even supposed to be in the path when using a physical device 








































































Hacker News • 2023-08-01 13:50:29Z 

Hacker News • 2023-08-01 01:18:41Z 



























drawTriangle













CNetChunk you'll need to parse it as such



CUnpacker. After that you can check UnpackMessageId to see how we figure out the message id



































ip routeip route default via 192.168.2.1 dev enp86s0 proto dhcp metric 20100 
















ip route please

ping 8.8.8.8 please, too, please @AssassinTee

ip route please
Ziel Router Genmask Flags Metric Ref Use Iface
default 192.168.2.1 0.0.0.0 UG 0 0 0 enp86s0
192.168.2.1 0.0.0.0 255.255.255.255 UH 0 0 0 enp86s0 
ping 192.168.2.1







enp86s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether SOMEMAC brd ff:ff:ff:ff:ff:ff
inet 192.168.2.162/24 brd 192.168.2.255 scope global dynamic noprefixroute enp86s0











noprefixroute on my linkjournalctl -ru NetworkManager (edited)





sudo iptables -L -n -v
Hacker News • 2023-08-01 15:52:57Z 








Chain INPUT (policy ACCEPT 27673 packets, 2164K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 25692 packets, 4621K bytes)
pkts bytes target prot opt in out source destination
Chain DOCKER (0 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-ISOLATION-STAGE-1 (0 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-ISOLATION-STAGE-2 (0 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-USER (0 references)
pkts bytes target prot opt in out source destination
Chain f2b-sshd (0 references)
pkts bytes target prot opt in out source destination





curl -i http://1.1.1.1/ is?













iptables -nL you are looking at the filter table: iptables -t filter -nL













