2020-05-14 23:41:56.342599+0530 appName[3552:186526] This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.
just want to know what this means [3552:186526].
If I understand correctly, you're specifically asking what the [3552:186526] part of the message means. The number to the left of the colon (3552, in this case) is the process ID of that specific instance of your app. If you run it again, it would generally log a different number.
The number to the right of the color (186526) is a thread identifier for the thread which caused the problem. However, it's mostly useless because it's hard to correlate that to the thread IDs presented by the debugger. Also, again, it would be different for every run of the app.
Related
I've been developing our company's credential provider for windows 10 for almost a year now.
Now, I encountered a problem. I don't usually ask questions on forums, blogs, because in most cases I find the solution, but this time I've been struggling with an issue for a month now and I found the root of the problem.
Brief description of the problem itself: The credential provider uses a combobox, which worked before without a problem. Now, I rewrote the whole code to manage a big update, but a strange bug got into the system. The bug only occurs at a specific scenario. I'm developing and testing the code on my personal laptop.
The scenario:
1) The laptop is plugged in to my monitor / power, etc.
2) I make it go sleep.
3) I unplug all cables (including power).
4) I wake it up from sleep.
Than, the combobox doesn't show a default selected item, it's empty. When I drop it down, it shows all the necessary items. Than the credprov crashes and restarts, than everything is fine.
I know, that in similar "strange" scenarios, in most of the cases, a memory leak or something related causes the problem. When I check the event viewer it shows me c0000005, which is access violation. I started to debug where the violation is. Than I found out that the program refers the combobox item list array (actually vector in my case) at a very very high index (out of range could be the reason for the violation). The actual index is obviously stored in the "selectedComboItemIndex" variable (DWORD).
I was curious when did it change to this strange number, than I found an unexpected behavior.
The SetComboBoxSelectedValue method randomly gets called once (when the bug happens) with an insanely high index value. I don't even call this method in my code, so I have no idea, why does it get called. The call happens even when I don't drop down the combobox.
I give it a chance that it could be a bug in the credprov itself. What do you think? Have you seen this problem before?
Thank you in advance!
I solved the problem by stopping to use "SetSelected" and "SetDeselected" methods. Furthermore, I filtered the "SetComboBoxSelectedValue" input parameters to accept valid numbers only. When the index parameter is invalid, I recall the same method with the index parameter replaced to the first item (0).
My Labview Program works like a charm, until I look at the Block Diagram. No changes are made. I do not Save. Just Ctrl+E and then Ctrl+R.
Now it does not work properly. Only a Restart of Labview fixes the problem.
My Program controls two Scanner arrays for Laser Cutting simultaneously. To force parallel working, I use the Error handler and loops that wait for a signal from the Scanner. But suddenly some loops run more often than they should.
What does majorly happen in Labview when I open the Block diagram that messes with my code?
Edit:
Its hard to tell what is happening without violating my non-disclosure agreement.
I'm controlling two independent mirror-Arrays for Laser Cutting. While one is running one Cutting-Job, the other is supposed to run the other Jobs. Just very fast. When the first is finished they meet at the same position and run the same geometry at the same slow speed. The jobs are provided as *.XML and stored as .net Objects. The device only runs the most recent job and overwrites it when getting a new one.
I can check if a job is still running. While this is true I run a while loop for the other jobs. Now this loop runs a few times too often and even ignores WAIT-blocks to a degree. Also it skips the part where it reads the XML job file, changes the speed part back to fast again and saves it. It only runs one time fast.
#Joe: No it does not. It only runs once well. afterwards it does not.
Youtube links
The way it is supposed to move
The wrong way
There is exactly one thing I can think of that changes solely by opening the block diagram.
When the block diagram opens, any commented-out or unreachable-code-compiler-eliminated sections of code will load their subVIs. If one of those commented out sections of code were somehow interfere with your running code, you might have an issue.
There are only two ways I know of for that to interfere... both of them are fairly improbable.
a) You have some sort of "check for all VIs in memory" or "check for all types in memory" that you're using as a plug-in system. When the commented-out sections load, that would change the VIs in memory. Such systems are not uncommon when parsing XML, so maybe.
b) You are using Run VI method for some dynamically invoked VI to execute as a top-level VI, but by loading the diagram, it discovers that it is a subVI of your current program. A VI cannot simultaneously be top-level and a subVI, so the call to Run VI returns an error.
That's it. I can't think of anything else. Both ideas seem unlikely, but given your claim and a lack of a block diagram, I figured I'd post it as a hypothesis.
In the improbable case someone has a similar problem. The problem was a xml file that was read during run time. Sometimes multiple instances tried to access it and this produced the error.
Quick point to check: are Debug and "retain data in wires" disabled? While it may not change the computations, but it may certainly change the timing of very tight loops, and that was one of the unexpected program behaviors, OP was referring to.
My App suddenly crashes at one point (reproducible) when run on a 512mb phone emulator (only have a 920 to test). There wasn't any exception, it just went black. I then ran the analysis tool on the application and found out the memory reaches its limit at the point the app crashed. The app exits with an error code. The most recent one I found was 0x887a0005, but I'm pretty sure I saw another one a little time back. Sadly, I don't have that one anywhere.
I load about 600 images from the web into BitmapImages with the CreateBackground option, and handle the ImageOpened event.
I'm not asking for help managing the problem itself, I'll find a way to work around it. I'm just wondering why the App isn't throwing any exceptions, and instead just crashes. Any ideas her
This is expected behavior. Depending on which piece of code is executing at the very moment you run out of memory, an out of memory exception may be thrown - if one can be thrown by that specific .NET class or under laying class. But the operating system is not going to wait for this to happen, and will usually just terminate your app. It's not sending your app a "terminate" or "out of memory" signal, it just kills it.
VB.NET, .NET 4
Hello all,
I have an application that controls an industrial system. It has a GUI which, once a process is started, principally displays the states of various attached devices. It basically works like this:
A System.Timers.Timer object is always running. At each Elapsed event, it polls the devices for their current values and invokes controls on the GUI, updating them with the new values.
A start button is clicked, a process time Stopwatch object is created and started (Labels on the GUI are now invoked and updated on the System.Timers.Timer's Elapsed event, in addition to the other work that is taken care of on this event)
A new thread is created which runs a Process() subroutine
Some Stopwatch objects are created and started (these Stopwatches are periodically restarted during the process via their Restart() method.
Some logic is executed on the new Stopwatchs' Elapsedmilliseconds properties to determine when to do things like write new setpoints to the devices, update the data log, etc...
Here's my problem: The program occasionally freezes. My ignorant efforts at tracking down the problem have led me to suspect that read/writes to the subset of devices that are RS-232 controlled are the culprits most of the time. However, I occasionally see other strange things upon program freeze, e.g., one of the time Labels whose Text property is determined by a Stopwatch's Elapsedmilliseconds property sometimes will show an impossible value (e.g., -50 hours or something).
For the RS-232 problems, I suspect something like a read event is being executed at the same time as a write event and this causes a freeze(?). I tried to prevent this by making sure that all communication with an RS-232 device is funneled through a Transmit() subroutine which has the following attribute:
Which, as far as my ignorance permits me to understand, should force one Transmit() execution to finish completely before another one can start. Perhaps another risk is the code getting blocked here if one Transmit() never finishes?
Regarding the Stopwatch trouble, I speculate that the problem is that the Timer is trying to update a GUI Label at the same time that the Stopwatch's Restart() method is being executed. I'm unsure if this could cause a problem. All I know is that this problem has only occurred at a point in the process when a Restart() call would be made.
I am wondering if I could use a SyncLock or something to lock a Stopwatch while the Label is being updated (or, conversely, while its being restarted)? Or, perhaps I should stop the Timer, restart the Stopwatch, and then start the timer again, like so?:
Timer.Stop
Stopwatch.Restart
Timer.Start
My trepidation regarding how to proceed is due to my complete lack of understanding of how .NET synchronization objects actually work. I've tried slapping a few SyncLocks in various places, but I really have no idea if they're implemented correctly or not. I'm wondering if, having provided all this context, someone really smart might be able to tell me how I'm stupid and how to do this right. I would really appreciate any input. If it would be useful to provide some code snippets, I'd be happy to, I just worry that everything's so convoluted that it would just detract from what I'm hoping is a conceptual question.
Thanks in advance!
Brian
I would consider a shift to a task scheduling framework instead of relying on manual manipulation of timers if your working on anything SCADA related. A simple starting point would be something similar to the hardcodet.Scheduling classes and you can move to something like the beast that is Quartz. Most of these types of frameworks will provide you with a way to pause and resume scheduled actions.
If I'm working with Modbus, I normally keep a local cache of the register values and make changes to any value fire a change event. This has the benefit of allowing you to implement things like refreshing values manually without interfering with your process scheduling and checking for deadband when evaluating your polled response. This happened to be the side effect of implementing a polled protocol to a subset of the OPC DA interface.
I am working with a free app that calculates grades for norwegian high school students. The different subjects are stored in a sqlite database. Everything works fine, except for one thing: If i close the app and restart quickly (faster than, say, one second), it crashes. Also, this only happens if I close the app in specific circumstances involving selecting/checking subjects in a UITableView (the changes are immediately stored in the database). Anyway if I wait for more than one second before restarting the app, it never crashes.
The error is not traced in any way in the console window.
Instruments has found some memory leaks in my app, but they are very small (16 bytes). I presume that is not the reason for the crash (but I will try to stop the leaks). I have also tried deleting and reinstalling the app, and turning the iPod/iPhone on and off. No change...
I understand that I cannot ask anyone to find the error in the extensive code of my app. My questions to you guys are:
Have any of you experienced similar errors? Related to sqlite?
Do you think App store will reject the app because of this?
Does anyone have any idea where to start looking for the error?
I am very thankful for any response!
When you say "it crashes," what is the actual error you get in the stack on the phone? Is it an actual crash, or are you getting a "failed to launch in time error?"
On iPhone, it's possible for an app's main thread to terminate while still running background nondetached threads. In this sense, despite all the claims that you cannot run in the background, you actually can... for a few seconds. When the main thread terminates, you go back to Springboard, and eventually the OS will kill your process if it doesn't terminate on its own. Do you manage any of your sqlite work on a background thread? Do you create any nondetached threads (this generally requires pthreads, so if you don't know, you probably aren't, but sqlite might; check in Instruments).
It's possible that your last instance still has a lock on your database, and that your re-launch doesn't react well to that lock. Do you have proper error handling around your open?