5 ms·

This probably needs a rename, "SQLite: View Ticket" is not a terribly descriptive title. That said, it's a little surprising to see a bug of this type in SQLit

• akira2501 8y ago
  > That said, it's a little surprising to see a bug of this type in SQLite which generally has such solid test coverage I was just thinking that's the sign of an extremely mature system. No system will never be free of problems, but you will have less of them, and paradoxically, the problems you are left with have far more complicated and usually emergent paths to activation.
  • peteretep 8y ago
    > usually emergent paths to activation What do you mean by this?
    • akira2501 8y ago
      In this particular case, the fault wasn't in any one component and was subsequently hidden and then revealed due to the complicated interplay between multiple modules. This is usually where case-by-case testing breaks down and you have to turn to other methods like fuzzing to elicit these behaviors.
• contravariant 8y ago
  On the other hand this is the kind of bugs you'd expect to see when programmers rely too heavily on the tests to catch bugs.
  • shakna 8y ago
    It takes 20 lines to reproduce the bug minimally, and relies on a confluence of code-generator bugs. I believe most fuzzers would take a considerable amount of time to find a bug like this... How are you suggesting a team on a very large project find this elsewise?
    • jessaustin 8y ago
      rely too heavily on the tests Presumably they are to find it using something besides tests? Intuition? Casting lots? Code review?
      • lifthrasiir 8y ago
        I think the intention was to embrace formal methods, which "proves" the absence of bugs (to the limited extents though). For a heavily-used critical piece of code like SQLite the lack or weak use of formal methods might actually be a reasonable criticism. EDIT: Not meant to say that the original comment was reasonable.
        • shakna 8y ago
          Surprisingly SQLite does actually embrace formal methods in various places. Such as, in their draft goals [0], under S30200, they outline a memory allocator goal by referring to a proof. Though, if the parents goal was to imply that the whole of SQLite should be verified... I'm not convinced its entirely possible. Quite a lot of SQLite revolves around things around where the halting problem may come into play. [0] http://www.sqlite.org/draft/sysreq.html http://www.sqlite.org/draft/sysreq.html
          • adrianN 8y ago
            Almost all things you'd want to prove about a program are undecidable in the general case. That doesn't mean much about the particular case of your program.
          • im3w1l 8y ago
            A computer program should be written to never* deadlock, and that implies that the programmers have a vague proof sketch in their head of why it doesn't deadlock that could if needed be formalized as a proof. *I'm sure there is some exception out there but it doesn't matter for this argument.
          • Jweb_Guru 8y ago
• exikyut 8y ago
  I agree with the rename. I'd suggest "SQLite (Severity: Critical): Infinite loop due to ORDER BY LIMIT optimization" It's very arguable that the bit in the brackets is editorialization. On the one hand I added it so nontechnical manager types would go "wait, what" and forward the issue internally so techs learn sooner. On the other hand, the subject itself is bad enough that _most_ will figure it out anyway, and pragmatically speaking this probably isn't going to kill anything by not being fixed within the next 30.8 seconds, so... Although this could be classed as a security vulnerability because now SQL injection can get you DoS. But the likelihood of the DoS being on a server is arguably low. Definitely nonzero but arguably low.
  • quietbritishjim 8y ago
    I think most readers of Hacker News realise that an infinite loop bug is pretty severe.
    • deleted 8y ago
      [deleted]