Ok, clearly you do not know how to trace a "random" segfault. Segfaults are not random, you said so your self. It's when you write to, and I quote (you), "an un

Ok, clearly you do not know how to trace a "random" segfault. Segfaults are not random, you said so your self. It's when you write to, and I quote (you), "an unallocated page, in which case you get a segfault". Well, is there a way you can trace that? Yes. Here's a great article I'll link to in a second, it might help for you to read a thing or two because you seem to think some problems are unsolvable. > There is no direct backwards path from a segfault to the source of the error. All you know is that a segfault happened here, and the cause of the segfault must've happened somewhere before it. Really? No direct way? Here's a cool article: https://ourmachinery.com/post/virtual-memory-tricks/ https://ourmachinery.com/post/virtual-memory-tricks/ This article says: > To see why, first note that the term random memory overwrite is actually a misnomer. Just like regular space, address space is mostly empty. With a 64 bit address space and an application size of say 2 GB, the address space is 99.999999988 % empty. This means that if the memory overwrites were truly random, most likely they would hit this empty space and cause a page fault/access violation. That would give us a crash at the point of the bad write, instead of the innocent read, which would make the bug much easier to find and fix. > But of course, the writes are usually not truly random. Instead they typically fall in one of two categories: > Writing to memory that has been freed. > Writing beyond the allocated memory for an object. And then he goes on to write about how you can use virtual memory to detect exactly when a segfault occurs. When I talk about avoiding segfaults these days, it's because I've written similar tools for myself. It doesn't mean a segfault never occurs, but when it does occur I get an error that says: "Error: Buffer overrun detected from memory allocated on line 215 in file foo/bar.cpp" Which means I know exactly where to begin tracing the segfault from. I'll give you the benefit of the doubt and assume that you have programmed in C++. You just must be a pretty poor C++ programmer if you've never figured out how to make tracing a segfault easier. It's OK, we've all been there and you'll eventually figure out that this is a problem that actually has a solution. I know it's a crazy idea that these things aren't completely random and we shouldn't just throw our hands up in the air and say "oh well, this is unsolvable". Instead of, you know, being smart and using just a tiny bit of forethought and planning by making sure every heap allocation is wired through a custom allocator. That way you can detect stuff like segfaults and prevent them. Just with a bit of forethought and planning. Crazy, I know. Lastly, a JS undefined object can happen in a library as well. You may or may not have access to the non-minified, non-transpiled source code. You may or may not get a correct stack trace depending on where the error occurred. This is a moot point. If you're using libraries, there will be untraceable bugs. Period. No matter the language. And by the way your attacks on my experience are great. I feel like you're insinuating that I've lied about my experience because that might be a projection of your own experience? If that's the case, I'm sorry to tell you, most people are honest and don't go lying on hacker news for internet points. Once again, you're probably like 15 or 16, we've all been there. You'll grow out of the clout chasing don't worry :)