1. 4
  1.  

  2. 6

    If I’ve followed this right, it’s a fairly regular leak and they were just really lucky that go 1.3 was forgiving about it. The code is hard to read with so many parameters and casts, but I suspect a simple test case would make it obvious where the allocation is and who is responsible for freeing it.

    1. 5

      What if this leak exposes something sensitive?

      Wat?

      1. 3

        Yeah, what?

        Leaking memory is not a security issue at all.

      2. [Comment removed by author]

        1. 2

          This was my understanding as well. The thought that the Go GC would garbage collect your C libraries is terrifying and would be a massive security violation.

          Just imagine if you could plug the Go GC into any C application. Would it work 100% of the time for 100% of the C code in existence?

        2. 1

          It was hard to determine exactly how they broke it. I was looking for a normal, natural access pattern that lead inevitably to a leak.