11:04:27 Hi guys, im currently fiddeling with the monero-wallet-rpc. I want a local running software to use the rpc calls and nothing else. Am i getting that right that it is enough for security to host the monero-wallet-rpc daemon on localhost or do i have to set other param. in order to prevent outside rpc calls? 11:09:02 You can firewall stuff. You can enforce SSL and set a whitelisted SSL cert. You can set a wallet password. 11:11:46 Are you familiar with jtgrassies c pool software? 11:12:13 In this case i think that i have to use the firewall 11:12:50 No. 11:28:35 dvd13, imho as long as you run monerod with --rpc-bind-ip 127.0.0.1 its cant be accessed by outside of your box. 11:28:54 only app in your machine can access this rpc port 11:36:37 i know, but just wanted to be sure;) Thanks 15:11:48 hello 15:47:48 hi 16:05:39 if is need to speed up new blocks creation for new blockchain until some height what to change emission_speed or smth else 16:13:29 anyone here 16:42:26 hi, according to https://www.reddit.com/r/Monero/comments/fb9ylj/c_memory_leak_detection_overload_operators_new/ that looks like spam here some screenshots of the .pdf. I know there are parts missing, if somebody thinks a specific part inside can be useful i could try to get it. here some screenshots of the .pdf https://imgur.com/a/h3XNI3n Its not 16:42:26 meant to look like spam. 16:51:57 fiddleitout: hey, I know this is meant to be helpful but Monero has no problems with memory leaks and logging alloc/free is a known technique. 16:54:06 thanks for your feedback, one of my friends already told me this is how you learn to do it in university anyways, ty for feedback 16:56:14 if you have problems with memory leaks perhaps try rewriting it in Rust 17:24:30 logging is resource-intensive. my leak-detector is far more efficient than every other one in existence. https://github.com/hyc/mleak 17:24:52 it's also perfectly thread-safe while using no locks of its own 17:39:28 Why not just use valgrind? 17:41:10 you're joking, right? 17:41:30 I use valgrind for lots of things. but it's a machine simulator, it runs 100x slower than native code. 17:42:02 a lot of bugs that you'd want help detecting won't even surface when you change the timing of its runtime environment so drastically 17:42:49 valgrind does excellent memory error detection, like detecting buffer overruns 17:43:01 they use a makro in this article , and compare than 17:43:01 but it uses 10x memory to do its job 17:43:17 (along with the 100x cpu time) 17:43:45 when you know you have no other memory errors, using my tool lets you run your program at near normal speed. 17:44:09 if you don't know that all your potential buffer overruns have been fixed, then my tool would be the wrong choice 17:44:35 srsly though, the README is like 3 paragraphs, you could have read that for yourself already 17:46:57 valgrind's machine simulator is also only single-threaded. while it can emulate multi-threaded code, again, it's a major difference in runtime timing behavior compared to native execution. 17:47:55 don't get me wrong - I like valgrind. I've contributed to it. It's a good tool, extremely useful. 17:48:15 but you could never drop it into a production environment to trace a bug, it would be too slow. 17:48:38 you could never use it with real-world workloads... 17:53:43 ASAN's typically better nowadays. Much faster too. 17:54:05 You do have to rebuild it though, so you've got to know in advance. 17:55:12 Yeah but if you use Valgrind already, what's the point? If you have good test cases, it should find all the memory leaks. 17:56:38 valgrind is too slow to use all the time. I only use it for exceptional circumstances. 17:57:24 Well, once you have run it, isn't that enough? If your tests pass with a clean bill of health, that is. 17:57:39 ASAN is decent but can be fooled, particularly by malware. all you have to do is make sure your memory overruns use the same poison pattern that ASAN itself uses. 17:58:01 Can't this be randomized? 17:58:18 It seems like if you have malware in your test vectors, buffer overruns are the least of your problems. 18:03:06 true. anyway that's out of scope for where we started 18:03:20 Also, about thread safety, isn't ml_sh very thread unsafe? I can't see thread local storage being used 18:04:15 it doesn't need to be. it's only used during initialization, and that only happens right after ld.so invokes it. 18:05:26 Wait, so how does it actually find the allocations? I was looking at ml_imalloc.. 18:05:40 But if it stores it before the allocation, then how does it actually find any leaks? 18:05:44 O(n) scan over all memory? 18:05:46 like I said, it is only used during invocation/init 18:06:03 yeah but in the malloc() function 18:06:05 here https://github.com/hyc/mleak/blob/master/mleak.c#L240 18:06:13 again, read the README 18:06:36 I have... I get that the actual data is stored before the allocation 18:07:11 oh it does do O(n) scan? 18:09:19 there's no other way, really. but since it happens at exit time, it doesn't affect runtime performance. 18:09:37 and linear scan of RAM is fast, there's no noticeable delay in shutdown time even for very large program heaps 18:24:29 10GB/s or so? 18:24:47 And upon free() it removes the sentinel I presume 20:29:28 it's only a 450 line file, no need to presume :P