• What version of Go are you using (go version)?
  • 1.4 RC (release-branch.go1.4); latest https://godoc.org/golang.org/x/mobile
• What operating system and processor architecture are you using?
  • darwin/amd64 targetting android/arm
• What did you do?
  • Passed a 300 character string parameter from Java to Go.
• What did you expect to see?
  • The Go function receive the parameter correctly.
• What did you see instead?
  • Heap corruption is reported and the Android process crashes.

There appears to be a bug in the buffer resize logic in mem_write in mobile/bind/java/seq_android.c? The buffer is resized to at most 2x its previous capacity, even if the new data to be appended is much longer. Ultimately the data is written to the buffer even though the buffer is too small, and the heap is corrupted and the program crashes. In the case of a serialized string parameter, mem_write is called from Java_go_Seq_writeUTF16 which is also the function that actually writes to the undersized buffer.

To reproduce, pass a long string to Go code using the bind parameter serialization mechanism. For a function that takes a single string, the default buffer size of a Seq is 64 bytes, and mem_write will at most double it to 128 bytes, and each character requires 2 bytes, and there's a 4 byte length prefix, so any string over ~62 characters will corrupt the heap (but only significantly longer strings will crash the program consistently, a 300 character string in my test case).

In the gobind generated Java code, immediately after the _in.writeUTF16(s), for example, you can call Seq.log() to log the buffer state and observe that the len > cap. At some random point after the buffer overflow, Android logcat displays "heap corruption detected by dlmalloc" and the process terminates.

This is the current resize logic (https://github.com/golang/mobile/blob/551dbd1f07f5826104e50893b453bcf6273fbeaa/bind/java/seq_android.c#L81):

...
    if (m->off+size > m->cap) {
        m = mem_resize(m, 2*m->cap);
    }
    uint8_t *res = m->buf+m->off;
    m->off += size;
    m->len += size;
    return res;

This seems to fix it (with this change the Seq.log() output looks correct and the process doesn't crash):

...
    if (m->off+size > m->cap) {
        uint32_t cap = 2*m->cap;
        if (cap < m->off+size) {
            cap = m->off+size;
        }
        m = mem_resize(m, cap);
    }
    uint8_t *res = m->buf+m->off;
    m->off += size;
    m->len += size;
    return res;