I'm not really understanding the following description about fibers in Microsoft's Win32 documentation:
a fiber assumes the identity of the thread that runs it. For example, if a fiber accesses thread local storage (TLS), it is accessing the thread local storage of the thread that is running it.
What does "assumes the identity of the thread" in the first sentence mean? Can anyone explain this sentence in other way?
Related
When I add the asynchronous timer, it gets stuck. How can I fix this?
It's not connected with the "asynchronous timer" (whatever it means), it's classic OutOfMemoryError exception
The reason is that JVM asks the underlying operating system to create a new native thread and the process fails somewhere somehow, the reasons could be in:
Java process doesn't have sufficient address space
The underlying OS lacks virtual memory
There is a limitation on the underlying OS level which doesn't allow that many native threads, i.e. /proc/sys/kernel/threads-max
So you either need to amend your JVM/OS configuration or will have to allocate another machine and switch to Distributed Testing
More information: java.lang.OutOfMemoryError: Unable to create new native thread
The Windows Antimalware scan Interface (AMSI) contains abstractions which can be used to call the currently active virus scanner in Windows:
https://learn.microsoft.com/en-us/windows/desktop/amsi/antimalware-scan-interface-functions
There are 2 methods related to initialization:
AmsiInitialize
AmsiUninitialize
AmsiInitialize returns "A handle of type HAMSICONTEXT that must be passed to all subsequent calls to the AMSI API.".
After initialization is complete, I can use AmsiScanBuffer to scan a buffer for malware.
My question:
Can I use the same context concurrently from many threads in my application, or do I need to create one per thread from which I'm going to call the methods?
Reading the documentation, for AsmiUnitialize, it tells me that When the app is finished with the AMSI API it must call AmsiUninitialize.. This tells me that the context can be used for many calls, but it doesn't tell me anything about thread safety or concurrency.
Generally, API calls that are not specifically marked as thread-safe are not (this is usually true for any library). The easiest solution is to open an AMSI handle per thread.
(P.S. This only works with Windows Defender so far as I 've tested).
I see there are threads in hang in the websphere application server. How can I troubleshoot this problem? What documentation should I send to the application developer?
Thanks.
The most important thing is the thread stack - that should show up with the message indicating the hung thread, and it'll tell you what that thread was doing.
That, on its own, might not be enough, particularly if that thread is waiting on some other thread. In that case, you might need a thread dump. That can be triggered with "kill -3" against the process ID on non-Windows systems (I'd have to do more research to tell you the equivalent process on Windows, although there are tools that can simulate "kill -3"), and the server also can be configured to do that when it detects a hung thread, using the JVM system property com.ibm.websphere.threadmonitor.dump.java (set to either "true" or an integer value representing the maximum number of thread dumps you want).
The thread dump will go to a file called "javacore...txt" (the "..." will be a long string representing stuff like the timestamp), except on Solaris, where it will go to the server's native_stdout.log. The javacore has a lot more than just thread stacks, so you can search for "Thread Details" to find that section quickly. You'll need to search on the thread name/stack from the server log to figure out which thread is the hung one and go from there.
If you are experiencing performance, hang, or high CPU issues with WebSphere Application Server, there is a procedure documented by IBM support team to collect the data necessary to diagnose and resolve the kind of issues. This procedure is based essentially on
enabling Application Server verboseGC
running a script, at the time of the problem, which collects 3 javacores for the problematic JVM
At the end of this procedure, you need to collect:
*.tar.gz file generated by the script
javacores generated by the script
server logs (SystemOut.log, native_stderr.log,...)
and send the results to IBM Support.
To get the script and for additional information about this procedure, I suggest to give a look to the following articles:
WebSphere MustGather procedure on Linux
WebSphere MustGather procedure on Windows
A similar document exists also for AIX platform.
I am in the process of designing a crash handler solution for one of our applications that creates a crash dump file using the MiniDumpWriteDump() function. While reading up on the topic I have seen the recommendations to invoke MiniDumpWriteDump() from an external process to maximize the chance that the dump file contains the correct information. The common solution seems to be to run a watchdog process in parallel to the application process. When the application crashes it somehow contacts the watchdog process, providing it with the information that is required to create the crash dump. Then the application goes to sleep until it is terminated by the watchdog process.
I can imagine such a watchdog process being run continually as a background service. This has many implications, starting with "who creates the service?", but also "which user does the service run as?", and "how does the application contact the service?" etc. It seems a pretty heavy-weight solution which I don't feel is appropriate for the scope of my task.
A simpler approach is suggested by this SO answer: Launch a guard process on application startup that is tightly coupled to the application process. This is pretty good, but it still leaves me with the tasks of 1) keeping the information somewhere in the application how I can contact the guard process in case of a crash; and 2) making sure to terminate the guard process if the application process shuts down normally.
The simplest solution of all would be to launch the crash dump handler process at the time the crash occurs, passing all the information that is required to create the crash dump as arguments to the process. This information consists of
The process ID of the application process that crashed
The thread ID of the thread that crashed
The adress of the EXCEPTION_POINTERS structure that describes the exception that caused the crash
This "fire and forget" approach is compelling because it does not require any state retention, nor any complicated over-time process management. In fact, the approach seems so overwhelmingly simple that I cannot help but feel that I am overlooking something.
What are the arguments against such an approach?
The main argument against the "fire and forget" approach, as I called it, is that it is not safe to launch a new process at a time when the application is already in a state where it is about to crash.
Because of that I went for the "guard process" approach. It brings a number of challenges with it, for which Hans Passant has outlined a solution.
I also added a bit of code in this answer that should help with deep-copying the all-important EXCEPTION_POINTERS data structure.
Using WER, as proposed in the comments, also looks like a good alternative to writing your own guard process. I must admit I have not investigated this any further, though.
There are some discrepancies relating to ObRegsterCallbacks in the documentation and sample code that contradict one another. I'm hoping someone from Microsoft reads this board and can provide a straight answer.
First, here is some background:
Kernel Data and Filtering Support For Vista SP1 page 12
"The OB callback is always made in the context of the originating process & thread."
MSDN documentation on OB_PRE_OPERATION_CALLBACK
"This routine is called at PASSIVE_LEVEL in an arbitrary thread context with normal kernel APCs disabled."
ObCallback Callback Registration Driver sample code in the WDK
Uses PsGetCurrentXXX routines to compare against the target object.
It seems the utility of these callbacks is pretty limited if you can't accurately determine the originating process/thread but per the current documentation that seems to be the case. Any insight would be appreciated.
I'm guessing you got your answer on OSR Online, though it would be helpful for other users if you could notify them of the answer you got there:
The callbacks are invoked in the context of the thread that initiates the handle
operation in question. The documentation could be more precise on this point.
- S (Msft)