6 ms·

>I love how developer's go to argument is, "you must not be very experienced if you've never encountered X". It's gatekeepy and gross. Ignore it then. I'm wron

>I love how developer's go to argument is, "you must not be very experienced if you've never encountered X". It's gatekeepy and gross. Ignore it then. I'm wrong. You honestly seem like you don't have much based off of what you're telling me about segfaults. >It turns out you can avoid most segfaults using a little forethought and planning, like I said. Just "avoid them" lol is what you're saying. That's how I program. Avoid all errors and bugs with a little planning and forethought so my programs are 100% bug and error free. That's how you do it. Again I don't think you worked for a large corporate application if you think forethought and planning are all it takes to avoid a segfault or memory leak. With enough people and libraries and dependencies in the codebase statistically it inevitably gets introduced. The only time it absolutely never gets introduced is if the language doesn't even have that class of errors. >Yes, and it's gross. I worked on a 20 year old legacy C++ application that dealt with high frequency trading at my old job. It was nasty and there were several problems including a very large memory leak that was untraceable. You seem to have missed what I said, which was "but that doesn't mean a good developer can't avoid a lot of memory related footguns with a bit of forethought and planning". Key words, "a good _developer_". Once you throw in hundreds of developers into the mix all bets are off, and that's not the claim I was making. Why make this claim at all? My point is C++ is less safe then python. Your attitude made it seem like your countering my claim but really you're just going off on a tangent on how good developers make a language safer? Why? Off topic. I mean the way you put it, we're basically in agreement. C++ is less safe then python and you need "good developers" in order to make it safe. Yet despite this agreement your attitude is passively hostile especially near the end where you just say you're "done replying" lol. I think what's going on here is you're changing the goal posts. >If you're dealing with a system that you know inside and out, it is usually a very simple matter to trace a segfault. How is this even relevant? When is a code base so simple that you know it inside and out? Have you seriously been dealing with C++ outside of your hobby projects? >You can do the same thing with a C++ segfault. No you can't. There's no data to follow backwards from the segfault. The segfault can even occur in a library you don't have source code for and it's very hard to trace this without external tooling. For javascript you just trace the path of the undefined variable. That's it. You don't even technically need a debugger for this. Are you sure you worked with C++ in a large code base? Because what I stated above is somewhat definitive. >Anyways, I hope you have a good day :). My intent is not to have an argument over an inconsequential problem, so I'm done replying. No man. This is a cop out. I'm open to being convinced but you know your arguments are reaching dead ends you're going off on strange tangents just to try to stay afloat. So you act polite and pretend you're too above it all. Come on man that's weak. It is literally definitive that an undefined is easier to trace then a segfault. There's no leeway or opinion here yet you have inserted so much off topic and questionable stuff that I'm not sure if you're even being honest.

_gabe_ 4y ago
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 :)

_gabe_ 4y ago

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 :)