Dream Seeker hangs when clicking links

Page: 1 2 3 4 5
May 16 2016, 6:58 am
Here is a minidump: http://puu.sh/oTThk/7608ae298e.dmp
(BYOND Version being 509.1319)
And here's my process list:
http://puu.sh/oTTk9/756dfcfba9.txt
May 16 2016, 9:02 am
Your process list doesn't show any obvious problems, except for that fact that it's freaking ginormous. I consider myself a mondo multitasker in terms of what I have open at any time, but your process list is huge. It seems like a great deal is going on there.

I found a huge red flag in your new minidump: One of its last calls is to AcLayers.dll. I did some digging, and although Google was spectacularly unhelpful, I finally figured out that this is for Windows' compatibility mode. The takeaway I get from that is that you're running BYOND (specifically, dreamseeker.exe and/or byondwin.dll) in compatibility mode, which you shouldn't be.
May 16 2016, 9:09 am
I will need to do some more testing to see if that TRULY fixed it... Another thing is i don't know why the FUCK Windows 10 assigned byond.exe compatibility on Windows 7. It just did that without my consent, and i didn't do it either. Oh well. But as i said, i need to test this more.
May 16 2016, 9:11 am
If you upgraded from Windows 7, it's possible the upgrade simply put everything in compatibility mode itself, thinking that was the best thing to do.
May 16 2016, 9:13 am
As for the process list, that is a export of ALL user's processes, including system, oh, and i also run a lot of background invisible stuff, that takes 0 cpu literally. The process list is very big, yes, but most of these are needed/on purpose, and do not cause ANY kind of strain. And i didn't even had BYOND installed back when i upgraded from Windows 7, not even that, but i installed Windows 10 throught a flashdrive and not Windows Update. This IS curious.
May 16 2016, 9:16 am
Most of it did look harmless, yes, but for sheer quantity it's really astounding. I've never seen a process list that big on a well-behaved system, although in fairness I couldn't see anything I'd disable except for some Skype and gaming add-ons you may not need to have running all the time.
May 16 2016, 9:30 am
My system runs pretty much fine with all this stuff. It's kinda normal a system managed by me having so much stuff on the backgroud.
May 16 2016, 10:39 am
Apparently disabling compatibility did NOT fix it. Here is a dump that i've taken when DS frozen when i clicked on a link: http://puu.sh/oU5yG/be28e925cd.dmp
May 16 2016, 12:37 pm
This keeps getting weirder. This time the hang is shown in SetSel(). There's one issue I could find on Google regarding such a thing, but no answer to it. However the fact that this isn't consistent with your other dumps suggests that maybe it isn't so much hanging here, as that that's where you're catching it.

About the only other thing I can think to suggest is to try stepping through the program once you've caught the hang in the debugger, to see what happens at each step of the way.

First I'd go to the hanging thread--it appears to always be 0, so use "~0s" to switch to it--and type "k" to see the stack. If you're not in a BYOND .exe or .dll, type "gu" to step out of the current function. Continue to do so until you're back in BYOND's territory. Then keep trying "gu" to see if you can get out of the function, documenting at each step of the way where you are in the execution. If at any point it can't escape, that's the top level where the hang is occurring.
May 18 2016, 5:24 pm
Here is the dump i've taken following your instructions:
http://puu.sh/oWXy4/985a3a086e.dmp
May 18 2016, 8:15 pm
Something's wrong with that latest dump. There's no information in it; it's one thread that doesn't have anything to do with BYOND.
May 18 2016, 8:16 pm
When i took the stack it mentioned a LOT of BYOND in it. I'm wondering what the hell...
May 18 2016, 8:26 pm
May 18 2016, 9:19 pm
Okay, that has some BYOND info on thread 0's stack, but it's not the first thing on there. You used the "gu" command to keep going up until it couldn't go further?
May 18 2016, 9:20 pm
By "go further" you mean go until the debugger unfreezes dream seeker and let it run? If yes, then yeah, i did.
May 18 2016, 9:48 pm
If it's frozen when you break into the process, then the debugger should never reach a point where "gu" just lets it run. The gu command should instead keep trying to return from the current function, and once it reaches the main one responsible for the freeze, it should be unable to return because it's caught in a loop or something.
May 20 2016, 5:37 pm
I redid one with a loop because i though i screwed up... Oh well.
May 21 2016, 3:21 pm
I just saved a minidump again, and this is the correct one. This is also from 510.1344 since 509 had some problems and i had to upgrade.
Link: http://puu.sh/p0hqM/d939e9ac62.dmp
And yes, this time it got into a loop after "gu"ing too many times.
May 21 2016, 4:24 pm
This dump is hanging in a completely different place. The last call in BYOND's code is to ReplaceSel(), rather than SetSel() as in the other dumps.

The big question is, though, what did the stack trace look like before the last "gu" that got into a loop? That's where the real loop is happening. You didn't document where you were at each step of the gu so I can't tell which function was the true top of this. Curiously, not one of the dumps so far has indicated that the link click is a trigger, which is very strange. (I don't doubt your report, but I'm wondering why the click event isn't showing up in the stack trace.)

One very important point also worth addressing: Does this hang happen in a simple vanilla project?

client/Topic(href)
    usr << href

mob/Login()
    ..()
    src << "<a href=\"byond://?hello\">Test link</a>"

I expect it would, but it'd be nice to rule that out.
May 21 2016, 4:27 pm (Edited on May 22 2016, 6:25 am)
I am going to:
1. Save the .dmp again, but this time i will trace the "gu"
2. Test your code and see if it hangs. Most probably will.
Page: 1 2 3 4 5