How can I find why Thread block? - jprofiler

This picture is a part of my pressure test, it looks fine in the previous part, but block for an unknown reason, how can I know what going on between my bookmark area? What causes the block.

I find myself, In Thread Monitor I can find this blocked thread are all cause by IO Logger print

Related

what does this log means when i do nslog

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.

How to panic! in production

Panic! seems to be the right way to stop a program while in development mode. But one should not ship a program that displays such a message for an excepted error:
thread '<main>' panicked at 'error message: ()', x.rs:785
Is there any way to exit a program early with an error code, without displaying developer oriented text? I could use process::exit but I've read that it does not perform cleanup, so what should we use?
panic! is not the right way to stop a program.
Its sole purpose is to abort when everything is about to go south and you have no way to recover. If you are expecting some wrong behaviour anywhere, use Result and recover from that behaviour by printing a nice message and cleanly exiting.
If you have panic!s or assert!ions in your code and they trigger, the message you showed is the only correct thing that should be displayed, because it's a bug in your code and there's no clean way to recover from a bug.
Note that panic! does not necessarily perform cleanup. If you panic, and another panic happens in a Drop impl, the program simply aborts. Also there's a setting for rustc that turns off the cleanup on panic and simply aborts on the panic!.

vb.net Run on crash

My program runs for about 10 hours during the night, sometimes I wake up to see that it has crashed (for whatever reason). It is usually a "Program Name" has stopped working, and the only button there is to close the program. I have tried watching and waiting for it to crash but the problem seems very hard to reproduce (and I can't watch it 24/7). I have used try and catch statements in my program in potentially problematic areas and told the program to dump to a text file if it catches an exception. But this isn't good enough it seems.
TLDR: Is it possible to tell my program to run a particular function when an exception has been detected in the program in general (without specifics) so that I can dump the stacktrace to a text file and investigate later?
Is it possible to tell my program to run a particular function when an exception has been detected...
Yes, but the specifics depend on the platform that you are using:
If you have a Console application, put a big Try ... Catch around Sub Main.
If you use WPF, add an event handler to AppDomain's or Dispatcher's UnhandledException event. Specifics can be found in the following question:
WPF global exception handler
In you use WinForms, you can also wrap Sub Main (which might be auto-generated) or attach to AppDomain.UnhandledException, see here for details:
WinForms Global Exception Handling?
For completeness, global exception handling in web applications is done in global.asax's Application_Error method:
How to catch unhandled exceptions in an asp.net application?
It's generally not a good idea to do this. You could, however, look at AppDomain.UnhandledException. This is pretty much restricted to one domain, and you'll also receive (potentially) notifications for all unhandled exceptions unrelated to your program.
This is usually used for class libraries, but I think with a bit of fiddle, you might get it to work.

No SystemOutOfMemoryException

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.

Application terminated at middle

Here My problem is when Im running my build in the device sometimes my application is terminated at middle with displaying the message in the console as:
Program received signal: "0".
warning: check_safe_call:could not restore current frame
Can anyone help why this was happening like this? Anyones's help will be appreciated.
Thank you,
Monish Kumar.
This is very possibly caused by an infinite loop which is causing you to run out of memory and the debugger can't unwind the stack because there's too much recursion.
Set a breakpoint in the debugger at some point directly preceding the crash and then step through the operations in your code to find where the problem is occurring.
It looks like crash caused by low memory. Try to implement -applicationDidReceiveMemoryWarning: in your application delegate and free unnecessary resources there.