6 ms·

This is one of the cases where not having null pointers in Rust really doesn't seem to help: % touch test % lapce test thread 'main' panicked at 'Erro

This is one of the cases where not having null pointers in Rust really doesn't seem to help: % touch test % lapce test thread 'main' panicked at 'Error in Surface::configure: parent device is lost', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.12.0/src/backend/direct.rs:214:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace % RUST_BACKTRACE=full lapce test thread 'main' panicked at 'Error in Surface::configure: parent device is lost', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.12.0/src/backend/direct.rs:214:9 stack backtrace: 0: 0x56474aaac84c - <unknown> 1: 0x56474aad958c - <unknown> 2: 0x56474aaa38f8 - <unknown> 3: 0x56474aaaeea7 - <unknown> 4: 0x56474aaaeb6f - <unknown> 5: 0x56474aaaf60a - <unknown> 6: 0x56474aaaf2f7 - <unknown> 7: 0x56474aaaccf4 - <unknown> 8: 0x56474aaaeff9 - <unknown> 9: 0x5647494db8e3 - <unknown> 10: 0x56474a7d8499 - <unknown> 11: 0x56474a7d8f62 - <unknown> 12: 0x56474a6b7345 - <unknown> 13: 0x56474984e455 - <unknown> 14: 0x564749657184 - <unknown> 15: 0x56474953e4a5 - <unknown> 16: 0x5647494ee8b6 - <unknown> 17: 0x5647494dc243 - <unknown> 18: 0x5647494dc2b9 - <unknown> 19: 0x56474aaabf31 - <unknown> 20: 0x5647494dc282 - <unknown> 21: 0x7f084a6d3310 - __libc_start_call_main 22: 0x7f084a6d33c1 - __libc_start_main@GLIBC_2.2.5 23: 0x5647494dc165 - <unknown> 24: 0x0 - <unknown> Arch Linux, lapce 0.0.10, Rust 1.61.0-nightly, Sway/Wayland.

filmor 5y ago
A panic is a different kind of crash than a segfault, it can not be used to get your credit card information.
- sitkack 5y ago
  And there is a stack trace. Worlds apart.
  - eatonphil 5y ago
    Well stack traces are just a gdb session away, no changes to code/binary needed. No?
    - lanstin 5y ago
      But most crashes can be turned into an exploit.
      - eatonphil 5y ago
        I was just responding to the stack traces bit, no argument about the exploit potential.
    - sitkack 5y ago
      Not all crashes in C or C++ can give you a meaningful stack trace. Lots of time there is heap corruption, or stack corruption. Safe Rust has the same properties as a managed language, one is going to spend an order of magnitude less time hunting for bugs.
      - eatonphil 5y ago
        Gotcha, thanks for clarifying!
        sitkack 5y ago
        I should have elaborated in my original comment. Next time!
    - 3836293648 5y ago
      Panics are usually at or close to the root of the bug. Segfaults can be anywhere later in the program
- xyproto 5y ago
  Sure, but that is not a worry I have when I launch Neovim.
cyber_kinetist 5y ago
Probably an error in the WGPU rendering code. Rendering APIs have all sorts of implicit constraints and edge cases you need to be aware of (because of the complexity of using a specialized computation device that doesn't work like a CPU), and Rust's memory safety won't help you with most of it (since these are more of domain-specific logic errors rather than memory safety errors). Though Rust might help in designing a better API because it can use other features such as sum types, result types, and traits to model states and errors in a less error-prone way. (At least the WGPU experience seems better than OpenGL, when you don't even get an assert or a stack trace, just an invisible error that you can only fetch by using glGetError() and is going to be hell of a shitty time trying to debug it and then sometimes you get to the conclusion that it might actually be a driver bug...)

filmor 5y ago

A panic is a different kind of crash than a segfault, it can not be used to get your credit card information.

sitkack 5y ago
And there is a stack trace. Worlds apart.
- eatonphil 5y ago
  Well stack traces are just a gdb session away, no changes to code/binary needed. No?
  - lanstin 5y ago
    But most crashes can be turned into an exploit.
    - eatonphil 5y ago
      I was just responding to the stack traces bit, no argument about the exploit potential.
  - sitkack 5y ago
    Not all crashes in C or C++ can give you a meaningful stack trace. Lots of time there is heap corruption, or stack corruption. Safe Rust has the same properties as a managed language, one is going to spend an order of magnitude less time hunting for bugs.
    - eatonphil 5y ago
      Gotcha, thanks for clarifying!
      - sitkack 5y ago
        I should have elaborated in my original comment. Next time!
  - 3836293648 5y ago
    Panics are usually at or close to the root of the bug. Segfaults can be anywhere later in the program
xyproto 5y ago
Sure, but that is not a worry I have when I launch Neovim.

cyber_kinetist 5y ago

Probably an error in the WGPU rendering code. Rendering APIs have all sorts of implicit constraints and edge cases you need to be aware of (because of the complexity of using a specialized computation device that doesn't work like a CPU), and Rust's memory safety won't help you with most of it (since these are more of domain-specific logic errors rather than memory safety errors). Though Rust might help in designing a better API because it can use other features such as sum types, result types, and traits to model states and errors in a less error-prone way. (At least the WGPU experience seems better than OpenGL, when you don't even get an assert or a stack trace, just an invisible error that you can only fetch by using glGetError() and is going to be hell of a shitty time trying to debug it and then sometimes you get to the conclusion that it might actually be a driver bug...)