goretk/gore

Linux type kind parsing fails

stevemk14ebr opened this issue · 11 comments

When running the following script on a installation of pygore on a debian system i sometimes see erroneous values for kind. These are parsed correctly on a windows installation, using the same binary. I've verified the binaries are not corrupted by checking their hashes.

import pygore
import sys

testfile = sys.argv[1]

f = pygore.GoFile(testfile)
c = f.get_compiler_version()

types = f.get_types()
f.close()
for t in types:
    val,  = t.kind
    if val > 30 :
        print(val)

Output:

140033113718791
140033113718785
140033113718803
140033113718803
140033113718786
140033113718809
140033113718807

Can you share the file?

No i cannot unfortunately, i will try to do some reproduction myself to give you more info. This bug seems weird though because i see you are already masking the kind field?

Does the Go library parse it correctly? You can either use it directly or use redress "https://github.com/goretk/redress/releases" to extract the information. redress -type should print out all types in a format you will find in the source code.

When using the python library, the data is transferred from Go to C to Python. The issue can be anywhere in this chain... I suspect the C layer...

i'm trying with the C bindings now. I'll do the same logic as the python script

the C library does NOT exhibit this issue with the following code:

include <stdio.h>
#include "libgore.h"

int main(int argc, char** argv)
{
   int v;
   char* fp = argv[1];
   printf("loading: %s", fp);
   v = gore_open(fp);
   struct compilerVersion* c = gore_getCompilerVersion(fp);
   printf("Compiler version: %s\n", c->name);
   struct types* ts = gore_getTypes(fp);
   printf("found %d types\n", ts->length);
   for(int i =0; i < ts->length; i++) {
       struct type* t = ts->types[i];
       if(t->kind > 30) {
           printf("got a bad one\n");
       }
   }
   gore_close(fp);
   return 0;
}

This suggest the python bindings have an issue. Or that the binary in the python package is malformed.

This is just a complete guess here, but could this be a bignum and/or rounding problem?

x.ref numpy/numpy#8433

i've seen stuff like this before when the field being assigned into is wider than the value being assigned and is not zeroed before.

EDIT: I looked, this is the bug. In the python wrapper library an unsigned long is used, but in the c library it's an unsigned int. This causes whatever random upper bits of the unsigned long to be undefined and occasionally these are set giving weird results. Must of been lucky that it only occured on linux

_Type._fields_ = [('kind', c_ulong),

struct type {
    unsigned int kind;

From memory this is because Windows malloc() initialises memory to zero, whereas Linux malloc() doesn't.

Ah cool thanks for sharing that! Also appreciate the library alot.

I just pushed a new patch update to pypi https://pypi.org/project/pygore. Please let me know if 0.2.3 does not solve the issue.

Tested. The bug is resolved.