I have looked all over the internet for a single thread on this topic and found none.
In version 277 (maybe prior since this is the first version I try Intel XDK), the webkit inspector does not stop on breakpoints, ever! In fact, the UI seems to have quite a lot of difficulty to deal with just setting up a break points. Several odd behaviours are noticed:
In the inspector, in the 'sources' tab, open a js file, than click on the left margin (on line numbers) and you will notice :
1) that it will not show the breakpoint.
2) therefore you start clicking several times, and you notice that a break point is found in the breakpoint list (found on the right column of the inspector) for every click I made.
Important notes:
I'm very used to using the webkit inspector in Chrome, so I know that stopping on breakpoints works in other contexts or environments.
In this sense, I've tried to go ahead and prove this to myself, so I've tried this functionality in Node Webkit (since the XDK IDE is based on it), and I was surprise to observe that indeed this worked there as well.
This is why I believe it must be because I'm running the XDK on Windows 8.1. So I installed the SDK on my Mac at home. Same issue. So I tried Windows 7: same issue again.
The questions are, why the debugger doesn't work in the XDK? Has it worked in the past? How come no-one in the world seems to complain about this bug?
Related
I have encountered a critical issue that Unity Editor freezes. I've spent many hours debugging step by step of my codes but still can't find where the problem is. So I think maybe I should try thinking from another angle, generally speaking what reasons would cause Unity Editor freezes and not responding?
I can't find a general case discussion about this topic.
From my experience, infinite loop is one reason for sure. Deadlock is critical issue, but not sure if it causes Unity Editor freezes. Unity Editor bug that I encountered only makes the whole editor crashes, instead of freezing. Any other experiences are welcomed. Thank you!
In such case, what kind of tools or methods could I use to debug it? Right now since the editor freezes I can't use "print" to find out what happens after it freezes. So I use Visual studio to debug the Editor thread, in this way I can see all the prints that I wrote. It appears the game is still running, only the editor not responding. And I can use VS click "attach to Unity and play" and put some debugging points, then debug step by step.
The first thing that I would check out is for an infinite loop. At the hang/freeze moment, you can attatch the debugger of your choice and pause the execution. In the case that it is an infinite loop that it is executing, at the exec time pause you might find the execution in a forever running while (true) {...}
Other thing that I would check is the plugins in use. Several Unity plugins like Parse, FMOD, UMP (Universal Media Player), ZFBrowser, or Embedded Browser are using native threads. It’s an issue when a plugin ends up attaching a native thread to the runtime, which then does blocking calls to the OS. This means Unity can't interrupt that thread for the debugger (or domain reload) and hang. Source
To check that you can check the active threads in the visual studio command window af the freeze is reproduced:
View->OtherWindows->CommandWindow and type in this command:
Debug.ListCallStack /AllThreads /ShowExternalCode
In the stack you can check if some thread is there with no need, or if its related with the plugins mentioned above.
Also an interesting point is to check in the windows task manager (in the case that you are using windows) if the CPU usage is to 0%. It can lead you to the type of hang that is taking place.
Good luck.
Edit: I forgot to mention, you need to check also the unity logfiles
I notice this all the time, and its super frustrating.
Unfortunately, this could be any number of issues. I notice this issue most often when working in projects that are made for the Universal Windows Platform.
Try using the Task manager to monitor specific processes / threads running.
Some follow up questions:
What platform is your project currently targeting?
What version of Unity are you running? Have you tried other versions?
What are your computers specs? Is the OS up to date? Graphics Drivers?
Does it happen (or happen more often) when an external code editor is open? Perhaps try going to Preferences>External Editor > Regenerate Project files.
Are you using Unity Collab by chance? I've had issues where collab is stuck trying to communicate with Unity Servers / looking for changes. Try logging out of your Unity account through the editor, and log back in.
Have you tried looking for a Unity editor crash dump, or error log files? I think they can be found here C:\Users\username\AppData\LocalLow\Unity by default. Those files may give you more specific data concerning your problem.
Unity's new versions are getting more slower and slower. From my experience 2019 versions are the best and more stable.
I solved my issue. It's fundamentally an infinite loop.
It's not a simple case such as "while(true)". I'll try to explain.
My game was a PvP game, and I'm making a local AI. Usually my design pattern works fine, however I just turned off the simulation of "AI thinking time", and since the AI codes and server codes all run in local mode, the transmitting of data between server and client are replaced by local method call(meaning instantly executed before everything else).
There is a loophole in my server code. I use "Update" and a flag on server to change a specific game state, however in this particular case, it got into an infinite loop because the local method call is executed before the "Update". And because my AI now doesn't need real time to "think", it "acts" and transmits the event data to server right away. And since the transmitting doesn't need time any more, it calls the server method instantly, hence forming the infinite loop.
Using Visual Studio Code I have installed a few extensions (like Guidelines showing vertical dotted lines between pairs of matching brackets). When I start VS Code I can see all my extensions working fine in the Editor window.
However, when I switch to another tab within VS Code, I no longer see the Guidelines or evidence of any extension working in the new editor tab. Worst of all, when I then switch back to my original tab, all the guidelines etc that were there a few seconds ago are gone!
To fix the issue I have to restart VS Code. This can't be right! Has anyone hit the same problem?
I have tried uninstalling VS Code where it warns me some components could not be uninstalled and I have to do them manually. It doesn't tell me which. When I then reinstall, the extensions are visible (without me reinstalling them) but again I hit the same issues as above.
Please help?
Seems like having too many extensions installed, or perhaps one that is misbehaving behind the scenes, causes this problem. Reduce the number of installed extensions. Use Help->Developer Tools -> Console to see if there are any messages relating to the Extensions server
Bounty Update
I am leaving the question essentially the same, but I just want to point out at the beginning here that I'm most interested in help trying to get the socket between flash (Adobe Animate) and the native debugger working again, as I believe that is the issue I'm having. Or is it a socket between flash and Windows?
Original Question
I've apparently turned something off? Even when I write really bad code (like trying to call a function that isn't there or divide an integer into a fraction), the flash player boots, shows a background color and stops there. No messages in the output window or compiler errors window. If I fix my code, it all runs fine, but for about 30 minutes (ever since I started trying to work with bitmaps for a sprite sheet) I get no runtime errors no matter what kind of mistake I type in my code. Anyone know how to turn it back on?
I've checked my actionscript settings and I have both warning mode and strict mode checked on.
Could it be a socket issue? I admit I have little to no experience working with sockets and only a surface understanding of what that even means. I've added the socket tag. If someone can see that this is clearly nothing to do with sockets, by all means, I'll remove the tag.
UPDATE: 6/22/16
I just reinstalled Adobe Animate CC 2015.2 and no change. I'll try compiling it in flash builder when I get a chance to help pigeon hole the problem. (Edit 6/24: flash builder worked! But my trial version expired the next day so is no longer a viable option).
And I just tried something in the command prompt in Windows 10 as an administrator:
netsh winsock reset catalog
netsh int ip reset reset.log hit
which I found another user on flashdevelop.org used to fix a similar issue, but no change.
And I just tried debugging in Flash Builder. It worked fine (debugger caught bugs) but my trial version expired the next day.
update 6/24
I've tried launching debugger for AIR from within the Adobe Animate CC IDE and it works fine if there are no bugs; it fails to do anything visible (no Iphone emulator, no swf window) if I put a typo or error in the code.
I also just deleted winsock and winsock2, rebooted Windows, then reinstalled winsock and winsock2. No change.
update 6/25
Just tried a system restore in Windows to set all my files and settings and drivers etc. to the way it was a week and a half ago... Also completely uninstalled all Adobe products and reinstalled. No change. I can only imagine that wiping my hard drive and reinstalling Windows would do the trick, but come on, it hasn't come to that has it?
As VC.One suggested, I checked the compile error window (cannot believe I didn't check before! Maybe when I checked before there were no compile errors... Only runtime errors?) and the errors are showing up there. Does this mean that it's catching compile errors but just not runtime errors?
When you force/test a runtime error... make sure you check
Compiler Errors (ALT+F2) and also Output (F2). By Output I mean the window that shows traces (and runtime issues). One of those two should have some feedback for you.
A possible solution is to save a new Workspace. So with those windows for Compiler Errors and Output both open (or tabbed, I tab them next to my Timeline) go to Window (in top options like File/Edit/Debug etc) and choose Workspace, then into that you choose New Workspace. Give it a name in the pop-up and okay everything.
Flash should always load that current workspace (next time, go to Workspace option again, check that your specified workspace [by name] has a tick next to it...).
Possible pitfalls:
1 - Use the debug player
2 - Make sure there isn't somewhere a try/catch enclosing the portion of code that triggers the event that may lead to an error
3 - Socket issue: may be exported in debug mode but swf cannot connect to debugger (it waits in a blank state for 60 seconds I guess)
4 - Does it compile ok? If there are compilation errors you may get an SWF anyway but then it will not start
...
Linux Mint 17.2 64x
MonoDevelop 5.9.5, writing a D application with D language binding
I've been having a problem with Monodevelop for a long time where it'll just stop showing relevant autocomplete entires. I'll write a class or have one from from a library and sometimes I'll get what's in the class and sometimes I'll only gent entries like sizeof (which I think apply to everything). Occasionally I'll get nothing at all.
Like this.
I've tried uninstalling and reinstalling, I've tried deleting project files, and these solutions work in some cases until I start adding more code and then at some point they break again and I get nothing relevant in my autocomplete pop-ups. I've even tried deleting Monodevelop folders in .local .cache and .config on my system, but the problem persists.
I've been trying to ignore it, and when I had a duel monitor setup it wasn't so bad because I could have references to what I'm working on in another window... but right now I'm this close to having zero monitors from getting so frustrated with having to tab around back and forth every 2.5 seconds, I'm just going to lose it and embed my mouse in the screen.
I'd switch to another IDE but I haven't been able to get most of my other options working with D/Dub...
(Running MATLAB 8.1.0.604 (R2013a), Mac OS 10.8.3)
When I use the doc command, for example, doc fwrite;, or when I click the "more help" item in the popup help bubble for a command, the documentation window opens, but MATLAB subsequently hangs (the spinning beachball appears). This lasts indefinitely, and I inevitably have to force quit MATLAB. This also happens when using the Publish option from the editor.
Anyone have any ideas for diagnosing this? I tried taking a process sample but I didn't see any info I could interpret, I think since it's in Java the relevant information is obfuscated behind the JVM.
See this post on MatlabCentral: http://www.mathworks.com/matlabcentral/answers/71718 ... and more specifically this bug report which includes a "workaround." They don't suggest what could be the cause, but you might make sure that OS X is updated and that you have the latest version of Java. If you do other work with Java or with WebKit these might cause issues.
I hope you have already solved the problem. Otherwise a solution has been found, the bug resides in the Access for Assistive devices (only for version 2012b and later). If you can turn them all off from System Preferences, do that. If you can't, type this in the command window:
com.mathworks.mlwidgets.html.HtmlComponentFactory.setBrowserProperty('JxBrowser.BrowserType','Mozilla15');
From http://www.mathworks.com/support/bugreports/870843
I had the same problem with Matlab R2014a on OS 10.10.4. For me the solution involved disabling Cinch (a window management tool I had installed). This can be done by clicking on the Cinch icon in the menu bar then Disable Cinch, or from System Preferences > Security and Privacy > Accessibility (as MarcoB detailed in his answer).
More suitable as comments (but I don't have enough rep yet):
I just updated to Java 1.8.0_73 and to Safari 9.1 and the patch horchler posted no longer works.
MarcoB's command still works for fixing the crashes. But with this, no longer retina resolution in the Doc browser (so it looks ugly).