t/winxed/001_load.t intermittently coredumps Parrot #7

Closed
leto opened this Issue Sep 17, 2011 · 6 comments

2 participants

@leto
Leto Labs LLC member

This is because we are giving C functions a StructView PMC instead of the underlying pointer via alloc(). Since Git2.Repository objects are really just StructView PMC's, we should be able to call alloc() on them, but Winxed doesn't see an alloc() method in the Git2.Repository namespace and throws an error.

We could either provide a few pass-through functions that call the underlying StructView function or fix this in a smarter way that I have not though of yet.

@plobsing

Git2.Repository.Repository() has 2 problems.

First, constructors are expected to have (and are threated as having) nullary returns. Thus the return has no effect.

Second, a structview does not have an underlying pointer, so even if the return worked, the results would be not as expected. Git2.Repository objects (which should have an underlying pointer) should therefore not be based on stuctview instances, but rather the pointer instances returned by alloc() (which I would suggest you call in the constructor).

@leto
Leto Labs LLC member

I am almost understanding what you are saying, @plobsing. Could you give a small code sample of what you mean to hammer it into my thick skull?

@plobsing

Nullary constructor returns:

var x = new A();

compiles down into:

  $P0 = new ['A']
  $P0.'A'()

As you can see, the return value for the winxed-level constructor is completely ignored.

Suggested usage of structview (untested):

function get_sv() {
  var sv = new 'StructView'([...]);
  while (1) { yield(sv); }
}

class Git.Repository {
  var ptr;
  function Repository() { var sv = get_sv(); self.ptr = sv.alloc(); }
}
@leto
Leto Labs LLC member

Can you take a look at e1bbadf ? Currently I am getting this:

1..6
ok 1 - test_new_branch
ok 2 - test_new_repo
ok 3 - test_cstring
not ok 4 - open_repo
# Null PMC access in invoke()
# Called from 'open_repo' (t/winxed/001_load.t : 45)
# Called from 'execute_test' (rosella/test.winxed : 851)
# Called from '__run_test' (rosella/test.winxed : 875)
# Called from 'run' (rosella/test.winxed : 826)
# Called from 'test' (rosella/test.winxed : 1153)
# Called from 'main' (t/winxed/001_load.t : 77)
# Called from 'main' (winxed_installed.winxed : 268)
# Called from '(entry)' ( : 0)
not ok 5 - repository_index
# Null PMC access in invoke()
# Called from 'repository_index' (t/winxed/001_load.t : 61)
# Called from 'execute_test' (rosella/test.winxed : 851)
# Called from '__run_test' (rosella/test.winxed : 875)
# Called from 'run' (rosella/test.winxed : 826)
# Called from 'test' (rosella/test.winxed : 1153)
# Called from 'main' (t/winxed/001_load.t : 77)
# Called from 'main' (winxed_installed.winxed : 268)
# Called from '(entry)' ( : 0)
ok 6 - git_index
# Looks like you failed 2 of 6 tests
@plobsing

I would hazard a guess that this means that 'git_repository_open' is null. This would make sense since I see no Git2.ptr namespace declared in the project, but the import statement (using) has been changed to reference that.

@leto
Leto Labs LLC member

I made some recent commits that gets rid of the Null PMC access error, but now the issue is that structview.alloc() seems to be returning a null pointer:

#0  0x00007f6a598e9a75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f6a598ed5c0 in *__GI_abort () at abort.c:92
#2  0x00007f6a598e2941 in *__GI___assert_fail (assertion=0x7f6a593a7fae "repo_out && path", file=<value optimized out>, line=347, 
    function=0x7f6a593a8500 "git_repository_open") at assert.c:81
#3  0x00007f6a59394c50 in git_repository_open (repo_out=0x0, path=0x207a7c0 ".git") at /home/leto/git/libgit2/src/repository.c:347
#4  0x00007f6a5c962afd in pcf_int_ptr_ptr (interp=0x970050, nci=0x20229f8, self_unused=0xa3c960) at src/nci/extra_thunks.c:1996
#5  0x00007f6a5c9c74bb in Parrot_NCI_invoke (interp=0x970050, _self=0x20229f8, next=0x1f6fff8) at src/pmc/nci.c:215
#6  0x00007f6a5c8cd8fd in Parrot_invokecc_p (cur_opcode=0x1f6ffe8, interp=0x970050) at src/ops/core_ops.c:13441
#7  0x00007f6a5c97849a in runops_fast_core (interp=0x970050, runcore_unused=0xa3fdf0, pc=0x1f6ffe8) at src/runcore/cores.c:503
#8  0x00007f6a5c977917 in runops_int (interp=0x970050, offset=57872) at src/runcore/main.c:220
#9  0x00007f6a5c94b890 in runops (interp=0x970050, offs=1385) at src/call/ops.c:126
#10 0x00007f6a5c944664 in Parrot_pcc_invoke_from_sig_object (interp=0x970050, sub_obj=0xa5d680, call_object=0xa760d8) at src/call/pcc.c:337
#11 0x00007f6a5c943dd5 in Parrot_pcc_invoke_sub_from_c_args (interp=0x970050, sub_obj=0xa5d680, sig=0x7f6a5cb036cd "P->") at src/call/pcc.c:139
#12 0x00007f6a5c98e23a in Parrot_pf_execute_bytecode_program (interp=0x970050, pbc=0xa5d6f8, args=0xa44858) at src/packfile/api.c:2693
#13 0x00007f6a5c92077a in Parrot_api_run_bytecode (interp_pmc=0xa37f68, pbc=0xa5d6f8, args=0xa44858) at src/embed/bytecode.c:161
#14 0x0000000000401456 in main (argc=2, argv=0x7fff21d527d8) at winxed.c:943

Any further ideas, @plobsing ?

@leto leto closed this in 0f44d93 Oct 29, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment