Chapel: Zipped right into oblivion

[buddha314]

I know Bruce hates pithy titles, so I'll add this kitten for good measure.

I have two arrays and I tried zipping them. I maybe be using zip wrong, but this is quite the error

    const o = crystal.originalElements.sorted();
    const od = for p in o do subG.degree(p);
    var odo = for z in zip(o, od) do z;
    writeln("\tcrystal.originalElements: ", odo);

> timedexec: target program died with signal 11, without coredump

Feeling pretty burl right now....

[buddha314]

This does work, however.

var x = [1,2,3,4];
var a = ['a','b','c','d'];

for z in zip(a,x) {
  writeln("zippin'");
  writeln(z);
}


zippin'
(a, 1)
zippin'
(b, 2)
zippin'
(c, 3)
zippin'
(d, 4)

[bradcray]

Are you compiling with --fast (which turns off all execution time error checks) by any chance?

[buddha314]

Thought I would try to re-create the error, so I put in a print statement and it also barfed

    writeln(o.type:string);
    writeln(od.type:string);
> timedexec: target program died with signal 11, without coredump

@bradcray I am using start_test which I believe uses --fast by default.

[bradcray]

start_test doesn't use --fast by default unless it's a performance test (one that has a .perfkeys file). Is it definitely the zip line causing the segfault, or could it be something earlier? (i.e., if you put a writeln() between each statement, which is the last to be printed out?). I don't see anything obviously wrong, but also can't run the program fragment to reproduce.

Pro tip: Since the compiler knows the types of things, you can put compilerWarning(o.type:string); into your code and the compiler will print out o's type as it's compiling the code (it'll be labeled as a warning, so you just have to not get freaked out by that).

[buddha314]

Like the pro tip! Good one!

I am also trying to find a way to reproduce outside of my code. Hopefully I can. But right now I have to be done. I'll chew on this over the weekend.

[mppf]

As far as I know, the sizes of things zippered has to match for zip to work - that might have been the original problem.

[bradcray]

Shouldn't have caused a segfault, though, should it have Michael?

[mppf]

If it was compiled without bounds checking, a segfault is a possible outcome, as far as I understand. Certainly it'd be nice to understand what went wrong there in any case.

[buddha314]

Howdy folks, trying to re-create this error out of the original context. Haven't been able to simplify it yet.

[buddha314]

Got it! Don't ask me how I got to here...

const x = [1,2,3,4];

proc makevec(x:int) {
  var o: [1..0] int;
  o.push_back(x);
  return o;
}

const p = for y in x do makevec(y);
writeln(p);
writeln(p.type:string);
var zs = for z in zip(p, p) do z;

writeln(zs);

Gives me

[Working on file ziphell.chpl]
[Starting /Users/buddha/github/chapel/util/test/sub_test Mon Oct 23 16:20:26 PDT 2017]
[Starting subtest - Mon Oct 23 16:20:26 PDT 2017]
[test: /Users/buddha/sandbox/chapel/ziphell.chpl]
[Executing compiler /Users/buddha/github/chapel/bin/darwin/chpl -o ziphell --cc-warnings ziphell.chpl < /dev/null]
[Elapsed compilation time for "/Users/buddha/sandbox/chapel/ziphell" - 6.292 seconds]
[Success compiling /Users/buddha/sandbox/chapel/ziphell]
[Executing program ./ziphell  < /dev/null]
[Elapsed execution time for "/Users/buddha/sandbox/chapel/ziphell" - 0.033 seconds]
[Error cannot locate program output comparison file /Users/buddha/sandbox/chapel/ziphell.good]
[Execution output was as follows:]
   *** My emphasis
timedexec: target program died with signal 11, without coredump
   ***
[Elapsed time to compile and execute all versions of "/Users/buddha/sandbox/chapel/ziphell" - 6.334 seconds]
[Finished subtest "/Users/buddha/sandbox/chapel/ziphell" - 6.581 seconds]

I have no idea what this means. It's probably user error but it took me a long time to isolate the problem.

[ben-albrecht]

Some further simplifications lead me to believe this error can be described more concisely as:

Arrays of tuples of arrays result in dereference nil error (seg fault)

See simplifications below.

// Simplification 1 - still gives dereference nil error (or seg faults without `--devel`)
var p = [[1],[2],[3],[4]];
var zs = for z in zip(p, p) do z;

// Simplification 2 - still gives dereference nil error (or seg faults without `--devel`)
var p = [[1],[2],[3],[4]];
var zs = for z in p do (z,z);

// Simplification 3 - still gives dereference nil error (or seg faults without `--devel`)
var zs = [([1,2], [1,2])];

[buddha314]

Sure, you could summarize it that way if you wanted to BORE ME TO DEATH!

[buddha314]

Also, for clarity, my original use case is to zip different arrays, I did zip(p,p) for simplicity.

[bradcray]

I split @ben-albrecht's observation above into its own issue (#13149) as I'd never have found it here. I'm half tempted to close this issue as a duplicate of the now boiled down one, but am going to leave it open so that we can verify that resolving it will also resolve the loop-based zippering patterns that led to it.