Consider the following example: ``` global a; probe oneshot { a[1] <<< 32; a[2] <<< 78; a[2] <<< 0; a[2] <<< 0; a[3] <<< 96; a[3] <<< 0; foreach ([i] in a @count-) { printf("%d: %d\n", i, @sum(a[i])); } } ``` This example generates random output across different runs: ``` $ stap a.stp 1: 32 3: 96 2: 78 $ stap a.stp 2: 78 3: 96 1: 32 $ stap a.stp 3: 96 1: 32 2: 78 ``` The MAP operations generated by the stap translator in the kernel source code misses the COUNT_OP flag in the `_stp_pmap_add_ix()` runtim C function call: ``` { int rc = _stp_pmap_add_ix (global(s___global_a), ((int64_t)1LL), ((int64_t)32LL), 0, 1, 0, 0, 0); if (unlikely(rc)) { c->last_error = "Array overflow, check MAXMAPENTRIES"; goto out; }}; ``` Using the implicit `-` sorting direction in the stap script example above instead of `@count-` has the same problem. Both the kernel and dyninst runtime modes have this issue. Use of the `@count()` operator inside the `foreach()` loop *body* does make the problem disappear. The issue lies in the translator frontend where the use of aggregate operators in the foreach sorting specification does not affect the stat_op combinations of the `stat_op` data structure.
Just committed a fix to master as commit 92ef5f3da.