Descriptive Problem Summary:
Players playing AI on our SS13 server have been reporting freezes for a while now. These freezes happen whenever the AI players eye teleports from one place to another (specifically, more than one screen away or to another Z-level). This got worse when we swapped to the new map in the summer.

We suspect the issue is map data that's being pushed with rapid jumping (thus invoking large updates to what the client sees) is somehow causing an infinite loop.

To confirm: this happens whenever the player uses an ingame chat control, or whenever they use verbs to teleport their viewport up and down Z-levels. Or from one area to another, basically.

There are two similar issues:
http://www.byond.com/forum/?post=2008870&hl=DMTextPrinter
http://www.byond.com/forum/?post=2082440&hl=DMTextPrinter

(I found them based on searching the name of the function that was at the top of the call stacks whenever I was debugging the freezes.)

Numbered Steps to Reproduce Problem:
There is a very reliable way to reproduce this:
* Set up the Aurora.3 master branch https://github.com/Aurorastation/Aurora.3
* Start the round
* Join as or make yourself into the AI
* Use jump-to-network to teleport yourself to the Research Outpost camera network
* Look around for the Research Outpost elevator (somewhere left and down, it's a 3x3 space)
* Cycle between using move-upwards and move-downwards commands until you crash!

Code Snippet (if applicable) to Reproduce Problem:
N/A

Expected Results:
Serverside runtime or no crash.

Actual Results:
DreamSeeker freezes for the AI player. They are still connected to the server, however, cannot interact with DreamSeeker beyond just closing it.

Does the problem occur:
Every time? Or how often? Multiple times every round for a majority of our AI playerbase.
In other games? Unknown. Related issues were linked up above.
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur?
When you're not playing as the AI. The AI is not the only role which can move rapidly between Z-levels and areas like this, another one is a ghost, but we've not received reports of ghosts crashing. One theory is that the AI additionally has to deal with static (one image per tile unseen) whenever it loads new map data.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Tested with the earliest and latest versions of 511, still crashes. Server is 511 dependent so there's no point testing lower than that.

Workarounds:
Not known.

Debug Data:
When testing, I did find my windows to be running BYOND in compat mode for Win7. But I disabled that and it sitll didn't fix anything.

Yes I have some. I have 3 dumps available upon request and I undertook the stack-trace->gu method described by Lummox in one of the linked threads. The results were as thus:

# Child-SP RetAddr Call Site
00 00000000`00ffd4c8 00ffd4e8`00008afd byondcore!DMTextPrinter::SetLinkStart+0x248af
01 00000000`00ffd4d0 00008afd`0f932661 0x00ffd4e8`00008afd
02 00000000`00ffd4d8 00000000`0dd45b70 0x00008afd`0f932661
03 00000000`00ffd4e0 00000040`00000000 0xdd45b70
04 00000000`00ffd4e8 0f932781`00ffd65c 0x00000040`00000000
05 00000000`00ffd4f0 5971f706`00000000 0x0f932781`00ffd65c
06 00000000`00ffd4f8 00000040`00000050 0x5971f706`00000000
07 00000000`00ffd500 0000ffff`00000002 0x00000040`00000050
08 00000000`00ffd508 0000ffff`0000ffff 0x0000ffff`00000002
09 00000000`00ffd510 0000ffff`0000ffff 0x0000ffff`0000ffff
0a 00000000`00ffd518 00000000`00000000 0x0000ffff`0000ffff

Gu here produces this:
0:000> gu
Unable to insert breakpoint 10000 at 00ffd4e8`00008afd, Win32 error 0n998
"Invalid access to memory location."
The breakpoint was set with BP. If you want breakpoints
to track module load/unload state you must use BU.
go bp10000 at 00ffd4e8`00008afd failed
WaitForEvent failed
ntdll!DbgBreakPoint+0x1:
00007ffe`ef138d61 c3 ret

However, the stack changes. We're now here:
# Child-SP RetAddr Call Site
00 00000000`03e8f688 00007ffe`ef16536b ntdll!DbgBreakPoint+0x1
01 00000000`03e8f690 00007ffe`ef100d5f ntdll!DbgUiRemoteBreakin+0x4b
02 00000000`03e8f6c0 00000000`00000000 ntdll!RtlUserThreadStart+0x2f

Another gu leaves the breakpoint complete and the code starts executing again. If I break again, the stack trace will be the same as the one at the start. byondcore!DMTextPrinter::SetLinkStart always ends up at the top.