Re: [maybe OT] What kind of bug was that? Non-deterministic result with C integer overflow?

It is an array bounds error. Take a look at PDL-2.016/Changes:

* Bugs fixed:
    ...
    414   ccNcompt (i.e. cc4compt and cc8compt) breaks with byte data type

Which refers to this bug.

The algorithm allocates an equiv[] array to store label equivalence lists. When your running label wraps (a short int), it becomes a (small) negative value. This in turn is used as an index to chase the equiv[] list. In other words, you are accessing memory before the allocated object. Perhaps it would hang or fault if heap poisoning were applied.

Count of 28299 is smaller than maximum short value after label equivalences are removed.

Comment on Re: [maybe OT] What kind of bug was that? Non-deterministic result with C integer overflow? Download Code

Replies are listed 'Best First'.
Re^2: [maybe OT] What kind of bug was that? Non-deterministic result with C integer overflow? by vr (Curate) on Dec 18, 2017 at 16:46 UTC
Thank you for answers. A bit carried away with "non-determinism", it's just random data in unrelated memory. And now I see why I couldn't repeat this bug with checker-board pattern -- rather something like right-leaning triangles are required: `my $bin = ( xvals( short, 1024, 400 ) % 4 + yvals( short, 1024, 400 ) % 4 * 2 ) > 6; say $bin-> info; say $bin-> slice( ([ 0, 7 ]) x 2 ); say $bin-> cc8compt-> max; say $bin-> long-> cc8compt-> max;` [download] `PDL: Short D [1024,400] [ [0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0] [0 0 0 1 0 0 0 1] [0 1 1 1 0 1 1 1] [0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0] [0 0 0 1 0 0 0 1] [0 1 1 1 0 1 1 1] ] 31344 25600` [download]	[reply] [d/l] [select]
Re^2: [maybe OT] What kind of bug was that? Non-deterministic result with C integer overflow? by Anonymous Monk on Dec 18, 2017 at 16:23 UTC
I will never forget the very first time that this same (type of) bug bit me in the ass – in another context and in another life, long ago.	[reply]