Stack trace doesn't always show all entries it should

ID:2138288
 
Aug 25 2016, 3:35 am
BYOND Version:510.1346
Operating System:Linux
Web Browser:Chrome 52.0.2743.85
Applies to:Dream Daemon
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:
When the stack trace begins to remove the middle entries, sometimes entries near the bottom of the stack are skipped too, without this being shown in the result

Numbered Steps to Reproduce Problem:
Run the below code, changing 17 to other numbers

Code Snippet (if applicable) to Reproduce Problem:
/world/New()
    test(2) // call to test(2) will be the 2nd entry in the trace, after /world/New()

/proc/test(n)
    if(n == 25) CRASH()
    test(n+1)


Expected Results: If the stack trace was too long (appears to be if it is longer than 21 entries), some entries in the middle would be skipped but the first n and last m entries would be shown, with nothing inbetween, OR some entries would be skipped, but this would be made clear by the formatting of the trace.

Actual Results:
If the stack trace is 22 entries long, only entries 1, 3-10, and 13-22 are shown, skipping entry 2.
If 23 entries, only entries 1, 2, 4-11, and 14-23 are shown.
24 entries, only 1, 3, 5-11, and 15-24.
25 entries, only 1, 2, 4, 6-12, and 16-25.
26 entries, only 1, 3, 5, 7-12, and 17-26.
27 entries, only 1, 2, 4, 6, 8-13, and 18-27.
28 entries, only 1, 3, 5, 7, 9-13, and 19-28.
[...]
35 entries, only 1, 2, 4, 6, 8, 10, 12, 14, 16-17, and 26-35.

n (even, >35) entries, only 1, 3, 5, 7, 9, 11, 13, 15, 17, and n-9 to n.
n (odd, >35) entries, only 1, 2, 4, 6, 8, 10, 12, 14, 16, 18 and n-9 to n.

In each case, the only displayed split (indicated by "..." in the trace) is before the last segment, where the above lists have their 'and'; for example, with 28 entries, the trace is (my comments as DM-style comments):
test(28)
test(27)
test(26)
test(25)
test(24)
test(23)
test(22)
test(21)
test(20)
test(19)
...
test(13)
test(12)
test(11)
test(10)
test(9)
test(7) // where's 8?
test(5) // where's 6?
test(3) // where's 4?
world: New() // where's 2?


Does the problem occur:
Every time? Or how often? Every time
In other games? N/A
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur? Unknown

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Unknown

Workarounds: Don't trust the early section of the trace.

Aug 25 2016, 2:21 pm
What are you referring to exactly? The hard crash stack trace should only show internal calls and recent procs, and the built-in debug in an exception shouldn't go back that far IIRC.
Aug 25 2016, 2:28 pm
I believe it should be either showing a consecutive set of frames at either end, or be clearly showing that some have been omitted; as it is, it shows either frames 1, 2, 4, 6... or 1, 3, 5, 7... depending on whether the total number of frames is odd (1, 2, 4, 6) or even (1, 3, 5, 7).

If you run the code in the above post, the full output (plus comments of my own addition) is:
Thu Aug 25 22:24:29 2016
Auto-safety mode: ultrasafe (no file access)
World opened on network port 5000.
Welcome BYOND! (5.0 Public Version 510.1346)
runtime error:
proc name: test (/proc/test)
  usr: (src)
  src: null
  call stack:
test(25) // |
test(24) // |
test(23) // |
test(22) // |
test(21) // |
test(20) // |-  16-25, ALL frames in this range are shown
test(19) // |
test(18) // |
test(17) // |
test(16) // |
...
test(12)     // |
test(11)     // |
test(10)     // |
test(9)      // |
test(8)      // |
test(7)      // |-  1-12, but only 1, 2, 4, and 6-12 are shown;
test(6)      // |    I believe this should be either 1-10, or
test(4)      // |    should clearly show that frames 3 and 5
test(2)      // |    have been omitted.
world: New() // |
Aug 25 2016, 6:11 pm
turn on loop checks then intentionally create a stack overflow to really show it.