4 ms·

Have you tried ASAN? If you like valgrind, you will be in love with ASAN, it's really surpassed it at this point IMHO.

klyrs 5y ago
I have tried ASAN, and I'm fully prepared to love it, but last time I tried to use it with Cython, it was pretty fidgety to configure my build system to get it running -- unlike valgrind, you need to understand how programs are compiled and linked. If you want ASAN to see into the Python that's calling/consuming your Cython, you need to build a custom Python. It's certainly a sharper tool, but valgrind has the learning curve of a hammer.
- jcalvinowens 5y ago
  Ugh yeah, it just doesn't work well with Python. A friend of mine went down the same rabbit hole trying to debug a C extensions... it's a shame.
  - klyrs 5y ago
    Yeah, I'll be honest... I know how to build Python and all that, but I stopped dead once I realized that it was a requirement. Much faster to just valgrind/[print-]debug an issue than set up all that tooling. Making all that happen is on a distant back-burner, as it will take about 10+ uses to pay off and segfaults are typically rare and shallow for me.
jedisct1 5y ago
Be careful with ASAN on cryptographic code, though. It can introduce side channels.
- skeetmtp 5y ago
  ASAN is not meant to be used in production though. Or I missed something in your comment.
  - chrsig 5y ago
    I've seen it advised to periodically release to production with ASAN/UBSAN/TSAN enabled, with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation. I don't have a citation to share, so take with as many grains of salt as you feel appropriate. If nothing else, I appreciate the advisement that it can have security implications.
    - wizzwizz4 5y ago
      > with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation You can't unleak secrets.
      - chrsig 5y ago
        I agree with you, but I don't understand intent of your comment.
        wizzwizz4 5y ago
        If you leak all the secrets 1% of the time, that's not leaking 1% of the secrets. All of the secrets have been leaked, albeit over a short stretch of time.
- jcalvinowens 5y ago
  That's definitely a good point, and worth thinking about. But most people don't go to the trouble to rebuild dependencies like openssl. Unless you're actually implementing crypto, it seems unlikely you'd expose anything, although you do have to consider the possibility that a crypto library could call an instrumented function which could leak state.

I have tried ASAN, and I'm fully prepared to love it, but last time I tried to use it with Cython, it was pretty fidgety to configure my build system to get it running -- unlike valgrind, you need to understand how programs are compiled and linked. If you want ASAN to see into the Python that's calling/consuming your Cython, you need to build a custom Python. It's certainly a sharper tool, but valgrind has the learning curve of a hammer.

jcalvinowens 5y ago
Ugh yeah, it just doesn't work well with Python. A friend of mine went down the same rabbit hole trying to debug a C extensions... it's a shame.
- klyrs 5y ago
  Yeah, I'll be honest... I know how to build Python and all that, but I stopped dead once I realized that it was a requirement. Much faster to just valgrind/[print-]debug an issue than set up all that tooling. Making all that happen is on a distant back-burner, as it will take about 10+ uses to pay off and segfaults are typically rare and shallow for me.

jedisct1 5y ago

Be careful with ASAN on cryptographic code, though. It can introduce side channels.

skeetmtp 5y ago
ASAN is not meant to be used in production though. Or I missed something in your comment.
- chrsig 5y ago
  I've seen it advised to periodically release to production with ASAN/UBSAN/TSAN enabled, with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation. I don't have a citation to share, so take with as many grains of salt as you feel appropriate. If nothing else, I appreciate the advisement that it can have security implications.
  - wizzwizz4 5y ago
    > with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation You can't unleak secrets.
    - chrsig 5y ago
      I agree with you, but I don't understand intent of your comment.
      - wizzwizz4 5y ago
        If you leak all the secrets 1% of the time, that's not leaking 1% of the secrets. All of the secrets have been leaked, albeit over a short stretch of time.
jcalvinowens 5y ago
That's definitely a good point, and worth thinking about. But most people don't go to the trouble to rebuild dependencies like openssl. Unless you're actually implementing crypto, it seems unlikely you'd expose anything, although you do have to consider the possibility that a crypto library could call an instrumented function which could leak state.