Hacker News new | past | comments | ask | show | jobs | submit login

"Excellent system stability with no random crashes at all"

This holds for pretty much any language you care to use.




People keep saying that, and I can understand where they are coming from, but this isn't the case. Just yesterday, I managed to segfault python 2.6.something. I have no idea why (I really should have figured it out) but my hypothesis is that I freaked out the parser. It was vanilla python code; it should never segfault. I have had the same experience with the JVM: I once segfaulted the parser by incorporating a static string that was hundreds of lines long. Curiously, Eclipse "compiled" it just fine.

Sometimes environments have bugs. If you need an underlying runtime that simply will not crash, using something tried and true may be at the top of your priority list. That might be overkill for most projects, but I can see a guy who wants something so robust he knows its his fault when it breaks.


So based on your experience (as a comp sci student, I'm assuming, based on your other comment), Python and the JVM are both 'crashy', but you don't happen to remember exactly why?

Reminds me of a bunch of compiler bugs I found back in the day. Strangely the longer I program, the fewer of these compiler bugs I seem to be able to find.


I am going to defend myself. Then, I am going blow my argument out of the water.

Backstory: I am a fifth year comp sci student. I have worked part-time as an SDE for most of my college career. The python crash I referenced earlier was in class, the java problem at work. I have written an optimizing compiler before (C subset to LLVM to SPARC MIPS), so I hope that you will at least agree that I am not a complete moron in this area.

Java story, more detail: To make a really long story short: I wanted to move a really really long stored procedure (~2k LOC) into a JDBC query. Don't ask why, it was a very scary legacy issue. So I copy and paste the stored procedure into one long const string in eclipse, and it compiles just fine. I run our ant script against it, and it explodes with a stack overflow (IIRC). The solution that I found was simply to replace newlines with \n" + (newline). No stack overflow on compilation anymore. From this I could only assume that I had fubared the compiler (which would have been a reasonable way to fubar, being as I was trying to create an absolutely massive const string directly).

Now we could quibble over whether this even counts as a crash in the sense we were talking about, but the underlying premise is: you never want to have to work around your tools. As computer scientists we do it a lot, but it is never fun and its worse when something goes down in production because the tool crapped out. Theoretically, a VM or OS should never fail and bring the entire system down. A compiler should never outright crash.

Now to debunk my own defense: I just sat down for about an hour and did everything I could to reproduce the bug in JDK 1.5.6 (the original JDK I broke it on). Well, go figure, I can't get it to break in the hypothetical way I wanted to. I might one day do exactly what I did with the stored procedure, but setting that particular environment up again would take quite some time.

In conclusion, you can assume I was an idiot because I can't show you the code. I would in your shoes. :)

P.S. This all assumes you are using tools given to you by the platform itself. Using JNI to dereference a NULL doesn't count. :D


That's not a 'random crash.' The compiler ran out of memory trying to compile your file. Stack space is not infinite, a typical Java VM comes with some default which can also be reconfigured. After running out of memory, the compiler told you what the error condition was and exited.


Why not extend the stack at runtime?

LispWorks:

    CL-USER 101 > (defun foo (n) (unless (zerop n) (cons n (foo (1- n)))))
    FOO

    CL-USER 102 > (foo 1000)

    Stack overflow (stack size 15998).
      1 (continue) Extend stack by 50%.
      2 Extend stack by 300%.
      3 (abort) Return to level 0.
      4 Return to top loop level 0.

    Type :b for backtrace or :c <option number> to proceed.
    Type :bug-form "<subject>" for a bug report template or :? for other options.

     CL-USER 103 : 1 > 
Now use restart 1 or 2.


Could you post the code with which you were able to segfault Python 2.6? I succeeded in that only by using ctypes and messing up parameter passing.


I wish I could. I was in the middle of a lab when I did it, and as I fixed it I thought "I should really save this and figure out why it is segfaulting." Alas, the lazy part of me prevailed and I just fixed it so I could demo the assignment. Next time I run into one of those issues I am going to write about it as an example for the argument I just made.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: