I have this very strange problem on a big flex app where it would run fine with the debug swf if the user has debug flash installed but will have some disparities for people with standard version of flash.
These disparities include:
No pop ups
loose all event catching
Weird positioning of a button
I read somewhere that updatedisplaylist was handled differently ?
For now i will try the export release way instead of the bin-debug swf, and to go back in the commits to see what was the turning point.
Any similar experiences ?
I've been using Flex for a long time and have never heard of any problems like these being related to using the debug vs standard versions of the Flash player, but I have experienced problems similar to what you're experiencing.
When an exception occurs in your application, like attempting to access something in a null class or trying to access element 10 in an array that only has 9, the debug player will pop up a window stating that an exception has occurred and give you a stack trace, even if you're not actively debugging the app. The standard player does not, so the user will have no way of knowing that something went wrong.
In my experience after an uncaught exception occurs it can make all running code from that point on very unstable, causing all of the problems you list and more.
I doubt your problem has anything to do with the two different players beyond the standard one not giving you any feedback about the state of your app.
Related
My app is using Firebase Analytics and I believe starting in iOS 13.2 started getting the errors described here: Why I get the console warning: [Process] kill() returned unexpected error 1 when I load a WKWebView in iOS13.2?
I guess it wasn't a big deal
Since I planned for my app to go live in January, I began bigger tests in physical devices. I noticed after a while the app started to behave erratically, specially after receiving a [general] Connection to daemon was invalidated error. This doesn't occur in the simulator
Searching the internet I found a post that describes the same problem: https://forums.developer.apple.com/thread/124306
In my case, only Firebase seems to be calling WKWebView, but every time I open the UIMenuController I get the error described in the console and the app appears to be missing inputs. This is specially troublesome with UIScrollViews, which my app uses a lot. The pinch gesture seems to work at will. On an iPhone 6s, the issue isn't as noticeable, on an iPad, it's like a 50% chance the pinch gesture will work properly
Outside of removing Firebase, is there a way to mitigate this issue?
1 June 2020: The console message still persists, however, I have seemed to resolve the UIScrollView issue by deactivating delaysContentTouches, now the pinch gesture seems to work most of the time
23 October 2020 If anyone notices their app starting to behave erratically with no apparent reason I HIGHLY suggest to test it on an iOS 13 physical device if possible. Seems that Apple removed the warning from iOS 14, but testing it on iOS 13 you can pin point the exact reason after the warning appears in the console
Upon further testing, I've reduced the view down to a dead-simple UI view with a single SwiftUI TextField and the 'Connection to daemon was invalidated' still appears after I type the first character into the field. Soon thereafter the app crashes with a sigAbort. (So I don't think the reason is the UITextView wrapper I was using in the previous post). Once the invalidated message appears the app is doomed to crash, not right away but soon thereafter.
I have no idea what causes the 'invalidate' message and a Google search seems to imply that no-one else does either. Some folks appear to have made (experimental?) changes to their UI that stops the message but it appears to be impossible to determine a definite cause. (and like before it only occurs on a real phone)
Same issue without using Firebase at all. What I did: Delete build folder and compile again. Issue does not appears again.
On Xcode:
Clean the Build Folder
This will delete all of the products and intermediate files in the build folder. To clean the build folder you can use the shortcut Command+Option+Shift+K or Menu Bar → Product → Hold Option Key → Clean build Folder.
On Flutter:
Just delete build folder.
I am working on a QT application for which I've integrated DirectX 11 into a custom widget. The application renders a scrolling display - a graphical representation of data being read from a file. The user can speed up and slow down the scrolling speed.
For the most part, this is working great. The DirectX 11 rendering is presented to my custom widget just as I'd expect. The problem is that the graphics driver randomly hangs and crashes my program. I say "random" because I have been testing this with the same data file and it never seems to crash at the same point in the file, after a specific amount of time, or at a specific scrolling speed (the faster the scrolling speed, the more work being done by the GPU per frame).
When the application hangs, my screen freezes for a moment, goes black, then returns with a nice message from NVidia that it has recovered from a driver crash. The Debug Output in Visual Studio contains the following:
D3D11: Removing Device.
D3D11 ERROR: ID3D11Device::RemoveDevice:
Device removal has been triggered for the following reason
(DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of
time to execute its commands, or the hardware crashed/hung. As a
result, the TDR (Timeout Detection and Recovery) mechanism has been
triggered. The current Device Context was executing commands when the
hang occurred. The application may want to respawn and fallback to
less aggressive use of the display hardware). [ EXECUTION ERROR #378:
DEVICE_REMOVAL_PROCESS_AT_FAULT]
I have discovered that by simply commenting out the IDXGISwapChain1::Present call, the application will run through the file at blazing speed. Graphics-wise it is still pushing data to the GPU and drawing to render targets, it just never gets displayed to my window.
What I'm hoping for is help with ideas of what types of things cause driver hangs. My shaders are incredibly simple - basically just positioning my vertices using a projection matrix. And considering what I described in the above paragraph, shaders should still be cranking through vertices and pixels even when Present isn't being called, yes?
I was suspicious that this could be a compatibility issue with Qt - I know DirectX isn't officially supported by Qt. So I tried creating a separate window using CreateWindowEx and using that for my swap chain instead of the custom Qt widget. It rendered to that window but also hung the driver just like before.
I was also suspicious of a driver bug in my laptop, so I tried running the application on a beefier desktop PC that regularly runs another DirectX 11 application (non-Qt) without a hitch (worth mentioning that this other application renders similar data in a scrolling display as well, using shaders that are a lot more complex). But my QT application hangs the driver on that PC as well.
Anyone know of a way I can get a more detailed description of what is causing the driver to hang?
Thank you in advance for any help you can offer.
UPDATE: 2013-08-01 17:16 CST
I am currently investigating a possible thread syncing issue that may be the culprit. Will continue tomorrow morning and post if I solve this on my own.
After some testing today, it appears to have been a threading issue. I have run several times today with no graphics crash. So my problem must be fixed, unless I've just been getting lucky with my tests today (or unlucky, rather - if this shows its ugly face again in a day or two).
I was aware that the immediate device context is not thread safe. Rather than using deferred contexts, though, I was using critical sections to sync my threads and coordinate use of the device context. What I did not realize is that it is not safe to call IDXGISwapChain1::Present while another thread is using the device context. Makes sense, but since it is not call directly from the device context itself, I overlooked it. I literally moved my Present() call a few lines up into my critical section block, and it hasn't given me a crash since.
I am trying to debug a project, suddenly I'm running into an issue where enumerating any object collections results in a timeout if I try to view it.
If I run the program normally I have no issues. If I try to view any collection, such as a list, I get a timeout error and the whole thing bombs out.
I thought something might be going on with one of my more complex collections so I tried creating just a normal list of strings as follows...
List<string> blah = new List<string>{"fsdf","fsdg","Gt","gsersg","ser","gersgxdrsd"};
The same thing happens. I can hover over the object, I can even see the object count, however if I view the collection it dies.
I've ensured that the project/class library is in debug mode, disabled all extensions, restarted the system, tried percusive maintnence - nothing has worked.
Does anyone have any ideas? I'm completely losing my mind here.
I should also mention that this is a web application, I didn't notice before but a w3wp debug window pops up after I stop debugging. Sorry to leave out important info - was too frustrated to think straight when I wrote the post. I can still execute my code normally, and while debugging. I can examine all other objects without issue, it is only looking at collections in the watch window (or by hovering) that breaks.
Have a look at How to correctly debug web applications on local IIS 7.5 with VS 2010 Beta2?
I need to disable flash from showing these error messages when an error occurs. I am completely aware of the error I'm receiving, and it does not cause my application from working correctly. I simply need to disable these messages. Is there a setting in flash or a flex compiler command or something? Thanks, David.
There are a lot of things you can do with your mm.cfg file (google it's usage)
For instance if you put:
SuppressDebuggerExceptionDialogs=1
In there it will prevent the debugger version of flash from popping up error windows in your browser.
No, unfortunately there's no such thing. Though, the errors will not be displayed to users that have the release version of the flash player installed, and not the debugger one.
There's a very hot feature request for the flash player but the implementation seems far from happening: Ability to intercept system error dialogs. There are a lot of comments some heated, some sarcastic but Adobe seems to still ignore this issue.
UPDATE
The feature has since been implemented. Last comment says:
This has been fixed with Flash player 10.1
http://labs.adobe.com/technologies/flashplayer10/features.html
Global error handler The new global error handler enables developers
to write a single handler to process all runtime errors that were not
part of a try/catch statement. Improve application reliability and
user experience by catching and handling unexpected runtime errors and
present custom error messages. When using the global error handler in
a SWF running in the debug player, error pop-ups will not be shown.
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.