Hi Michael, Yes, I'll have a full program with the bug. I couldn't get a small test case to reproduce it (like the snippet below), because it didn't seem to allocate/free the matches array. It'll come with the other test cases.
Greg Michael Ferguson wrote: > Hi Greg - > > I'd like to try to reproduce this problem. Can > you easily share the input program with me? > Even if it's big, it will help if it compiles easily. > > If not, could you try to minimize the failing program > to a small example that reproduces the problem? > > Thanks, > > -michael > > On 5/27/15, 4:10 PM, "Greg Kreider" <[email protected]> wrote: > >> >> We've tracked down an "array reference count is negative!" problem, >> and think it's in the generated C code. >> >> The error occurs in a procedure that picks random elements from >> two arrays as seeds to determine how well two images match up. >> It looks like: >> >> proc pick_seeds(const corners1 : [] corner, >> const corners2 : [] corner, rand : RandomStream, >> inout try : tryinfo) : bool { >> var matches : [corners2.domain] int; >> var nmatch : int; >> var pick : int; >> var ind31, ind32 : int; >> >> /* Pick random seeds, verify they are similar, store in try. >> The list of possible matches is kept in the array, and nmatch >> contains the number of seeds we've stored. If it's 0, then >> there are no seeds and we can return. If it's not, then we >> need to pick one by choosing a random number between 1 and >> nmatch. ind31 is the first half of the pair that's already >> been determined; ind32 is the second half. >> */ >> if (0 == nmatch) then return false; >> pick = random_bound(rand, 1, nmatch); >> ind32 = matches(pick); >> try.seed3 = (ind31, ind32); >> >> return true; >> } >> >> The problem is that the program crashes in the line with the >> (0 == nmatch) test; the error message is "halt reached - array >> reference count is negative!" >> >> We scattered writeln's through the procedure so we could see in >> the generated C code where these lines were. At the (0 == nmatch) >> test: >> >> call_tmp_chpl299 = (INT64(0) == nmatch_chpl); >> if (call_tmp_chpl299) { >> ret_chpl = false; >> chpl__autoDestroy5(matches_chpl, INT64(224), "ransac_rst.chpl"); >> chpl__autoDestroy2(call_tmp_chpl6, INT64(227), "ransac_rst.chpl"); >> chpl__autoDestroy2(call_tmp_chpl7, INT64(228), "ransac_rst.chpl"); >> goto _end_pick_seeds_chpl; >> } >> call_tmp_chpl300 = random_bound_chpl(rand_chpl, INT64(1), nmatch_chpl); >> >> and at the end of the procedure: >> >> /* code between the call to random_bound and the try.seed3 >> assignment is skipped */ >> ret_chpl = true; >> _end_pick_seeds_chpl:; >> chpl___ASSIGN_17(try_chpl, &_formal_tmp_try_chpl); >> chpl__autoDestroy2(call_tmp_chpl7, INT64(228), "ransac_rst.chpl"); >> chpl__autoDestroy2(call_tmp_chpl6, INT64(227), "ransac_rst.chpl"); >> chpl__autoDestroy5(matches_chpl, INT64(224), "ransac_rst.chpl"); >> return ret_chpl; >> >> It looks like matches_chpl is being destroyed twice, once at the >> if .. then site, and once at the end. Which would explain the >> reference count problem. >> >> >> Hopefully this code snippet is enough to track down the problem; >> the full program and test case is fairly big ... Please let me >> know if there's any other information you need. >> >> Greg >> >> >> >> -------------------------------------------------------------------------- >> ---- >> _______________________________________________ >> Chapel-bugs mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/chapel-bugs > ------------------------------------------------------------------------------ _______________________________________________ Chapel-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-bugs
