6 ms·

Hilarious. I was evaluating Zig, I took a look at Bun, probably the most well known Zig project. Multiple issues related to seg faults.

saagarjha 4y ago
Those are safe depending on what kind they are.
kristoff_it 4y ago
Take a look at TigerBeetle which is also written in Zig, if you find segfaults there they even give you money :^) https://github.com/tigerbeetledb/tigerbeetle https://github.com/tigerbeetledb/tigerbeetle
- rosetremiere 4y ago
  It's hard to understand what tigerbeetle is about. Can anyone ELI5 it for me? As far as I can tell, it's some kind of a library/system geared at distributed transactions? But is it a blockchain, a db, a program ? (I did look at the website)
  - deleted 4y ago
    [deleted]
  - laserbeam 4y ago
    It's a special purpose DB. No relation to blockchains.
  - eatonphil 4y ago
    Hey thanks for the feedback! We've got concrete code samples in the README as well [0] that might be more clear? It's a distributed database for tracking accounts and transfers of amounts of "thing"s between accounts (currency is one example of a "thing"). You might also be interested in our FAQ on why someone would want this [1]. [0] https://github.com/tigerbeetledb/tigerbeetle#quickstart https://github.com/tigerbeetledb/tigerbeetle#quickstart [1] https://docs.tigerbeetle.com/FAQ/#why-would-i-want-a-dedicated-distributed-database-for-accounting https://docs.tigerbeetle.com/FAQ/#why-would-i-want-a-dedicat...
    - rosetremiere 4y ago
      The faq helped, thanks! So, an example of typical use would be, say, as the internal ledger for a company like (transfer)wise, with lots of money moving around between accounts? But I understand it's meant to be used internally to an entity, with all nodes in your system trusted, and not as a mean to deal with transactions from one party to another, right?
      - eatonphil 4y ago
        Yes that's a good example! And you can model external accounts that have their own confirmation process using our two-phase transfer support. https://docs.tigerbeetle.com/FAQ#what-is-two-phase-commit https://docs.tigerbeetle.com/FAQ#what-is-two-phase-commit
      - jorangreef 4y ago
        Great to hear! Joran from TigerBeetle here. Yes, exactly. You can think of TigerBeetle as your internal ledger database, where perhaps in the past you might have had to DIY your own ledger with 10 KLOC around SQL. And to add to what Phil said, you can also use TigerBeetle to track transactions with other parties, since we validate all user data in the transaction—there are only a handful of fields when it comes to double-entry and two-phase transfers between entities running different tech stacks. The TigerBeetle account/transfer format is meant to be simple to parse, and if you can find user data that would break our state machine, then it's a bug. Happy to answer more questions!
  - ngrilly 4y ago
    It's a distributed database for financial transactions, using double entry accounting, written in Zig, and with a very innovative design: - LMAX inspired - Static memory allocation - Zero copy with Direct I/O - Zero syscalls with io_uring - Zero deserialization - Storage fault tolerance - Viewstamped Replication consensus protocol - Flexible Quorums - Deterministic simulation like FoundationDB
    - Yoric 4y ago
      Zero deserialization? That sounds rather scary. This means absolute trust in data read from disk or received from other nodes?
      - rom-antics 4y ago
        What is the threat model you're worried about? If an attacker can write data to your disk or authenticate to your cluster, aren't you already screwed?
        Yoric 4y ago
        Yes, these are exactly my threats. First, because I'm a strong believer in defense-in-depth. Secondly because both disk corruption and network packet corruption happen. Alarmingly often, in fact, if you're operating at large scale.
        jorangreef 4y ago
        Ours too! For example, our deterministic simulation testing does storage fault corruption up to the theoretical limit of f according to our consensus protocol. Details in our other reply to you.
      - jorangreef 4y ago
        Great question! Joran from TigerBeetle here. "This means absolute trust in data read from disk or received from other nodes?" TigerBeetle places zero trust in data read from the disk or network. In fact, we're a little more paranoid here than most. For example, where most databases will have a network fault model, TigerBeetle also has a storage fault model (https://github.com/tigerbeetledb/tigerbeetle/blob/main/docs/DESIGN.md#safety https://github.com/tigerbeetledb/tigerbeetle/blob/main/docs/...). This means that we fully expect the disk to be what we call “near-Byzantine”, i.e. to cause bitrot, or to misdirect or silently ignore read/write I/O, or to simply have faulty hardware or firmware. Where Jepsen will break most databases with network fault injection, we test TigerBeetle with high levels of storage faults on the read/write path, probably beyond what most systems, or write ahead log designs, or even consensus protocols such as RAFT (cf. “Protocol-Aware Recovery for Consensus-Based Storage” and its analysis of LogCabin), can handle. For example, most implementations of RAFT and Paxos can fail badly if your disk loses a prepare, because then the stable storage guarantees, that the proofs for these protocols assume, is undermined. Instead, TigerBeetle runs Viewstamped Replication, along with UW-Madison's CTRL protocol (Corruption-Tolerant Replication) and we test our consensus protocol's correctness in the face of unreliable stable storage, using deterministic simulation testing (ala FoundationDB). Finally, in terms of network fault model, we do end-to-end cryptographic checksumming, because we don't trust TCP checksums with their limited guarantees. So this is all at the physical storage and network layers. "Zero deserialization? That sounds rather scary." At the wire protocol layer, we: * assume a non-Byzantine fault model (that consensus nodes are not malicious), * run with runtime bounds-checking (and checked arithmetic!) enabled as a fail-safe, plus * protocol-level checks to ignore invalid data, and * we only work with fixed-size structs. At the application layer, we: * have a simple data model (account and transfer structs), * validate all fields for semantic errors so that we don't process bad data, * for example, here's how we validate transfers between accounts: https://github.com/tigerbeetledb/tigerbeetle/blob/d2bd4a6fc240aefe046251382102b9b4f5384b05/src/state_machine.zig#L867-L952. No matter the deserialization format you use, you always need to validate user data. In our experience, zero-deserialization using fixed-size structs the way we do in TigerBeetle, is simpler than variable length formats, which can be more complicated (imagine a JSON codec), if not more scary.
speed_spread 4y ago
Well, Zig would not be such a good C replacement if it did not also allow segfaulting all over the place.
jeroenhd 4y ago
Looking at the bugs themselves, I don't think any low level language would've caught those. C/C++ would've crashed as well (hopefully, at least, many of these problems would be UB and the compiler might just ignore the problem or patch out the offending code) and Rust would've panic'd. There are a few cases where Rust wouldn't have allowed the code to panic but the surrounding code would be pretty unreadable in safe Rust (without stacking types like Box+RefCell+Rc and clone()ing a bunch) so it's hard to compare the two. The advantage of Rust would be a nice and readable stack trace to the crashing method, but a core dump would've included even more information for the person debugging the binary, so I think it ends up quite even.
- cormacrelf 4y ago
  I don’t know what’s going on in this thread where encountering UB has somehow been morphed into some kind of guaranteed immediate core dump that’s basically better than panicking anyway. Yes, people are talking about segfaults. But it’s memory corruption. Maybe you get a crash at some point, maybe you do not. A reminder for all that have forgotten: UB is the one that can email your local council and submit a request to bulldoze the house you’re in. It is not a free core dump.
  - sfink 4y ago
    You appear to have particularly vengeful nasal demons.
  - AndyKelley 4y ago
    A sementation fault is well-defined behavior. If you look at Jarred's comment nearby he reveals that the pointers in question are special pointers, e.g. 0x0, 0x1, 0x2, etc. It is 100% well-defined behavior to dereference these pointers. It always segfaults, which as Jarred mentioned is a lot like a panic. Rust evangelists need to be careful because in their zeal they have started to cause subtle errors in the general knowledge of how computers work in young people's minds. Ironically it's a form of memory corruption.
    - 4y ago
Jarred 4y ago
Most of what manifests as a segfault in Bun have been due to assuming a JSValue is a heap allocated value when it is (the JavaScript representation) “null”, “undefined”, “true”, “false” etc. These are invalid pointers, the operating system signals the memory access was invalid, Bun runs the signal handler, prints some metadata, and exits. This is a lot like a panic

saagarjha 4y ago

Those are safe depending on what kind they are.

kristoff_it 4y ago

Take a look at TigerBeetle which is also written in Zig, if you find segfaults there they even give you money :^) https://github.com/tigerbeetledb/tigerbeetle https://github.com/tigerbeetledb/tigerbeetle

rosetremiere 4y ago
It's hard to understand what tigerbeetle is about. Can anyone ELI5 it for me? As far as I can tell, it's some kind of a library/system geared at distributed transactions? But is it a blockchain, a db, a program ? (I did look at the website)
- deleted 4y ago
  [deleted]
- laserbeam 4y ago
  It's a special purpose DB. No relation to blockchains.
- eatonphil 4y ago
  Hey thanks for the feedback! We've got concrete code samples in the README as well [0] that might be more clear? It's a distributed database for tracking accounts and transfers of amounts of "thing"s between accounts (currency is one example of a "thing"). You might also be interested in our FAQ on why someone would want this [1]. [0] https://github.com/tigerbeetledb/tigerbeetle#quickstart https://github.com/tigerbeetledb/tigerbeetle#quickstart [1] https://docs.tigerbeetle.com/FAQ/#why-would-i-want-a-dedicated-distributed-database-for-accounting https://docs.tigerbeetle.com/FAQ/#why-would-i-want-a-dedicat...
  - rosetremiere 4y ago
    The faq helped, thanks! So, an example of typical use would be, say, as the internal ledger for a company like (transfer)wise, with lots of money moving around between accounts? But I understand it's meant to be used internally to an entity, with all nodes in your system trusted, and not as a mean to deal with transactions from one party to another, right?
    - eatonphil 4y ago
      Yes that's a good example! And you can model external accounts that have their own confirmation process using our two-phase transfer support. https://docs.tigerbeetle.com/FAQ#what-is-two-phase-commit https://docs.tigerbeetle.com/FAQ#what-is-two-phase-commit
    - jorangreef 4y ago
      Great to hear! Joran from TigerBeetle here. Yes, exactly. You can think of TigerBeetle as your internal ledger database, where perhaps in the past you might have had to DIY your own ledger with 10 KLOC around SQL. And to add to what Phil said, you can also use TigerBeetle to track transactions with other parties, since we validate all user data in the transaction—there are only a handful of fields when it comes to double-entry and two-phase transfers between entities running different tech stacks. The TigerBeetle account/transfer format is meant to be simple to parse, and if you can find user data that would break our state machine, then it's a bug. Happy to answer more questions!
- ngrilly 4y ago
  It's a distributed database for financial transactions, using double entry accounting, written in Zig, and with a very innovative design: - LMAX inspired - Static memory allocation - Zero copy with Direct I/O - Zero syscalls with io_uring - Zero deserialization - Storage fault tolerance - Viewstamped Replication consensus protocol - Flexible Quorums - Deterministic simulation like FoundationDB
  - Yoric 4y ago
    Zero deserialization? That sounds rather scary. This means absolute trust in data read from disk or received from other nodes?
    - rom-antics 4y ago
      What is the threat model you're worried about? If an attacker can write data to your disk or authenticate to your cluster, aren't you already screwed?
      - Yoric 4y ago
        Yes, these are exactly my threats. First, because I'm a strong believer in defense-in-depth. Secondly because both disk corruption and network packet corruption happen. Alarmingly often, in fact, if you're operating at large scale.
        jorangreef 4y ago
        Ours too! For example, our deterministic simulation testing does storage fault corruption up to the theoretical limit of f according to our consensus protocol. Details in our other reply to you.
    - jorangreef 4y ago
      Great question! Joran from TigerBeetle here. "This means absolute trust in data read from disk or received from other nodes?" TigerBeetle places zero trust in data read from the disk or network. In fact, we're a little more paranoid here than most. For example, where most databases will have a network fault model, TigerBeetle also has a storage fault model (https://github.com/tigerbeetledb/tigerbeetle/blob/main/docs/DESIGN.md#safety https://github.com/tigerbeetledb/tigerbeetle/blob/main/docs/...). This means that we fully expect the disk to be what we call “near-Byzantine”, i.e. to cause bitrot, or to misdirect or silently ignore read/write I/O, or to simply have faulty hardware or firmware. Where Jepsen will break most databases with network fault injection, we test TigerBeetle with high levels of storage faults on the read/write path, probably beyond what most systems, or write ahead log designs, or even consensus protocols such as RAFT (cf. “Protocol-Aware Recovery for Consensus-Based Storage” and its analysis of LogCabin), can handle. For example, most implementations of RAFT and Paxos can fail badly if your disk loses a prepare, because then the stable storage guarantees, that the proofs for these protocols assume, is undermined. Instead, TigerBeetle runs Viewstamped Replication, along with UW-Madison's CTRL protocol (Corruption-Tolerant Replication) and we test our consensus protocol's correctness in the face of unreliable stable storage, using deterministic simulation testing (ala FoundationDB). Finally, in terms of network fault model, we do end-to-end cryptographic checksumming, because we don't trust TCP checksums with their limited guarantees. So this is all at the physical storage and network layers. "Zero deserialization? That sounds rather scary." At the wire protocol layer, we: * assume a non-Byzantine fault model (that consensus nodes are not malicious), * run with runtime bounds-checking (and checked arithmetic!) enabled as a fail-safe, plus * protocol-level checks to ignore invalid data, and * we only work with fixed-size structs. At the application layer, we: * have a simple data model (account and transfer structs), * validate all fields for semantic errors so that we don't process bad data, * for example, here's how we validate transfers between accounts: https://github.com/tigerbeetledb/tigerbeetle/blob/d2bd4a6fc240aefe046251382102b9b4f5384b05/src/state_machine.zig#L867-L952. No matter the deserialization format you use, you always need to validate user data. In our experience, zero-deserialization using fixed-size structs the way we do in TigerBeetle, is simpler than variable length formats, which can be more complicated (imagine a JSON codec), if not more scary.

speed_spread 4y ago

Well, Zig would not be such a good C replacement if it did not also allow segfaulting all over the place.

jeroenhd 4y ago

Looking at the bugs themselves, I don't think any low level language would've caught those. C/C++ would've crashed as well (hopefully, at least, many of these problems would be UB and the compiler might just ignore the problem or patch out the offending code) and Rust would've panic'd. There are a few cases where Rust wouldn't have allowed the code to panic but the surrounding code would be pretty unreadable in safe Rust (without stacking types like Box+RefCell+Rc and clone()ing a bunch) so it's hard to compare the two. The advantage of Rust would be a nice and readable stack trace to the crashing method, but a core dump would've included even more information for the person debugging the binary, so I think it ends up quite even.

cormacrelf 4y ago
I don’t know what’s going on in this thread where encountering UB has somehow been morphed into some kind of guaranteed immediate core dump that’s basically better than panicking anyway. Yes, people are talking about segfaults. But it’s memory corruption. Maybe you get a crash at some point, maybe you do not. A reminder for all that have forgotten: UB is the one that can email your local council and submit a request to bulldoze the house you’re in. It is not a free core dump.
- sfink 4y ago
  You appear to have particularly vengeful nasal demons.
- AndyKelley 4y ago
  A sementation fault is well-defined behavior. If you look at Jarred's comment nearby he reveals that the pointers in question are special pointers, e.g. 0x0, 0x1, 0x2, etc. It is 100% well-defined behavior to dereference these pointers. It always segfaults, which as Jarred mentioned is a lot like a panic. Rust evangelists need to be careful because in their zeal they have started to cause subtle errors in the general knowledge of how computers work in young people's minds. Ironically it's a form of memory corruption.
  - 4y ago

Jarred 4y ago

Most of what manifests as a segfault in Bun have been due to assuming a JSValue is a heap allocated value when it is (the JavaScript representation) “null”, “undefined”, “true”, “false” etc. These are invalid pointers, the operating system signals the memory access was invalid, Bun runs the signal handler, prints some metadata, and exits. This is a lot like a panic