NeverSayDie will let you rescue from SEGV's and is evil | Hacker News Reader

NeverSayDie will let you rescue from SEGV's and is evil

github.com

27 points_pius17 comments

I have actually seen code like this in production. A "senior engineer" I worked with decided that C++ DOM parsing code was too verbose with so many checks for null child nodes, so he wrote a set of macros which wrapped setjmp/longjmp and trapped SIGSEGV to allow resuming any code that tried to traverse a null pointer.

If of course made debugging effectively impossible, not to mention catching all segfaults, not just those triggered by a DOM parsing error.

This project has about it a whiff of the quiet, almost understated elegance of the La Brea tar pits. I like it.

Thank you! I take pleasure in knowing that somebody, somewhere, will say "That's exactly what I've been looking for!", and use it in production.

Ruby/Rails segfaults often enough for this to be (even jokingly) useful?

[Edit] Why downvote a genuine question instead of informing me why you think it's inappropriate? I would never have expected someone to write a fatal-signal-ignoring-handler for a scripting language, even as a joke, so I was curious as to whether Ruby/Rails processes did semi-regularly crash.

Not that I've noticed. I just checked a bunch and most of my Ruby daemons have been running since early May, though some are busier than others.

Of course if you're the type to install random C extensions from github you might not always be so lucky.

It also has a whiff of mechanical sabre-toothed tigers.

"Massive security hole" needs to be added to that list of problems :)

On the other hand, it's easy to audit for: "links to NeverSayDie: failure."

Why is that a security hole? I suppose it might make it harder to detect an existing one, but it doesn't add a security hole in it's own right.

According to POSIX, after a SIGSEGV, the state of the program is undefined. This is the reason that a SIGSEGV usually causes an immediate abort. Allowing a program to execute when its state is undefined is a huge security hole.

Done:

http://github.com/tenderlove/neversaydie/commit/b686cf5ebc08...

Yeah, it's only a little memory corruption, no big deal.

I can tell the author is aware of the risks, but I'm sure there are ruby users out there that think this is a good idea.

This is exactly what is wrong with the Ruby community. Rails has an option called "disable whiny nils".

To paraphrase that old quote, "Those that trade correctness for convenience will get neither"

I can tell the author is aware of the risks, but I'm sure there are ruby users out there that think this is a good idea. This is exactly what is wrong with the Ruby community.

I'm literally rolling my eyes at this. You're actually "begging the question" — in the correct sense of the term!

Besides, going off on a tangent and randomly bashing the Ruby community stopped being cool like six months ago.

The problem is that I assume there are ruby users out there who think this is a good idea, even though I support that claim with the evidence of "disable whiny nils" in Rails?

I'm not "randomly" bashing the ruby community. This is a clever hack, but an extremely bad idea to use in production, and it comes fully packaged as a ruby gem that is ready to be deployed with "gem install".

The problem is that I assume there are ruby users out there who think this is a good idea, even though I support that claim with the evidence of "disable whiny nils" in Rails?

The problem's actually more subtle than that. The implication of what you said is that this is a problem with the Ruby community more so than some other communities. You provided no evidence for that claim at all. The disable whiny nils thing, by the way, doesn't do what you think it does.

I'm not "randomly" bashing the ruby community.

Sure you are. You're taking one library that happened to be written in Ruby and using it as an excuse to generally bash Rubyists.

This is a clever hack, but an extremely bad idea to use in production, and it comes fully packaged as a ruby gem that is ready to be deployed with "gem install".

This library is literally a joke. Although maybe not. I think Aaron is also a big fan of using Enterprise Ruby in production, which is why he released this: http://github.com/tenderlove/enterprise/tree/master

"This is exactly what is wrong with the Ruby community. Rails has an option called "disable whiny nils"."

whiny_nils is an option to provide additional information with an error, not an option to disable errors. It's not remotely related to this and you clearly have no idea what you are talking about.

You, sir, win the Internet.

Reply on news.ycombinator.com