Live data from Hacker News

Tracking down the 16-year-old WAL-reset SQLite bug

tailscale.com

211–220 of 263 posts

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#212
post #182

It says a lot about sqlite that a bug becomes front-page news on HN. I'm impressed that Tailscale took this seriously enough to engage with a commercial support contract. I'd love to work for a company that cared so much about correctness.

Indeed, SQLite has got to be one of the best tested pieces of software with famously 100% test coverage.

https://sqlite.org/testing.html

It's amazing that a bug could exist for 16 years but it is sobering.

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#213
post #203

Earlier quoted context omitted.

That strongswan thing is the kind of design HN praises about open protocols by IRC (just the other day...) but in practice is so flexible it can't keep itself upright and it's unusable in practice. Meanwhile tailscale or wireguard, by being actually opinionated, avoids needing much configuration at both ends.

Yes — configuring strongSwan as a bog-standard VPN server was so hard to fathom I made GitHub repo for it [1]. To be fair, some of the complexity comes from OS support that seems specifically designed to make secure setups difficult, presumably at the behest of various Three Letter Agencies. I have now mostly switched to Wireguard for this, which is much more sane [2]. [1] https://github.com/jawj/IKEv2-setup [2] http…

[deleted]

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#216

Earlier quoted context omitted.

I admit to curiosity as to whether static analysis could have caught this. E.g., Rust's type system (yeah yeah I know) catches all data races, unless they originate in unsafe code, which this one might or might not have; a hypothetical Rust SQLite would probably need a lot of unsafe ( https://github.com/tursodatabase/turso has 556 unsafe blocks in the core), and I don't have a sense of whether the particular part tha…

I wouldn't think so, but Go also has a data race detector: https://go.dev/doc/articles/race_detector .

That's dynamic, not static; it doesn't help much with a race that's hard to trigger.

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#219
post #35

SQLite: 92 million lines of tests Dijkstra: Tests can only prove the presence of bugs, never their absence!

Everyone knows that tests don't prevent all bugs. But they are very good at preventing known bugs from recurring in the future.

Everyone doesn’t seem to know that, because tests are often cited as a way to ensure that AI-generated code is correct.

Re: Tracking down the 16-year-old WAL-reset SQLite bug

#220

Earlier quoted context omitted.

I mean, exhaustive tests are one way you can prove something.

You can't even exhaustively test every 64 bit integer value.

Just because you can't exhaustively test one thing doesn't mean you can't exhaustively test anything.
Post reply on HN