I have been searching information on process info. I would like to know whether
a process is critical one or not. I have already done it within the application layer. However, I cannot judge whether a process is critical at the Driver layer(kernal)
I need to know whether a process is critical
so that I do not kill a critical process to avoid windows crash.
Can you help me on this issue?
Lots of love,
If you insist on doing the check from the kernel, you can use ZwQueryInformationProcess with the BreakOnTermination class.
You can also use two-way IPC to communicate with a Windows service which will perform the check for you.
Related
I'm having exactly the same problem described here:
timer_create() : -1 EAGAIN (Resource temporarily unavailable)
in short, some process is reserving a lot of timers via timer_create but never release them.
What I cannot figure out is how to determine the process affected by the leak in our production environment.
How could I know what process is the bad one, without randomly killing all the running stuff?
Any /proc/`pidof myprocess`/ debug info that tell me how many timers are reserved?
Thank you in advance!
Why yes, actually. Use the stap tool to trace system calls and determine which calls processes make most often.
The SystemTap Beginners Guide is a good resource. In particular, see the script on this page for an example of counting specific system calls per process.
I'm trying to understand what the mechanism is for getting a string from a c++ daemon I've written to Java for use by a UI. I'll post a picture of what I envision, then continue the question afterward:
There are two issues that I envision here:
1) The semaphore needs to be available to the library. In Windows, that could've been done with a named semaphore and access to it's handle. In Linux, I've been pointed toward using a semaphore in shared memory and making processes aware of it through a key to the shared memory. It's vague to me, but will that concept work to synchronize Java and the daemon?
2) Do I have to place the queue in shared memory in order to make the ??? link in the above chart work? Can and should the queue reside in the .so?
So those are my concerns. I'd love and welcome any and all help, challenges, and pleas for sanity and will do my best to provide all additionally necessary information. Thanks in advance.
You're running both applications in a separate process, in vanilla Linux this means you cannot communicate between these processes via memory directly. The Java VM is a process, and the C++ daemon is a process. It's in separate memory locations which are btw scrambled by the Memory Manager (MMU). So there is no way of getting memory access.
Google on "inner process communication" if you'd like. I prefer to run with socketpair for bi-directional parent-child communication.
Usually developing applications I am used to print to console in order to get useful debugging/tracing information. The application I am working now since it is multi-threaded sometimes I see my printf overlapping each other.
I tried to synchronize the screen using a mutex but I end up in slowing and blocking the app. How to solve this issue?
I am aware of MT logging libraries but in using them, since I log too much, I slow ( a bit ) my app.
I was thinking to the following idea..instead of logging within my applications why not log outside it? I would like to send logging information via socket to a second application process that actually print out on the screen.
Are you aware of any library already doing this?
I use Linux/gcc.
thanks
afg
You have 3 options. In increasing order of complexity:
Just use a simple mutex within each thread. The mutex is shared by all threads.
Send all the output to a single thread that does nothing but the logging.
Send all the output to a separate logging application.
Under most circumstances, I would go with #2. #1 is fine as a starting point, but in all but the most trivial applications you can run in to problems serializing the application. #2 is still very simple, and simple is a good thing, but it is also quite scalable. You still end up doing the processing in the main application, but for the vast majority of applications you gain nothing by spinning this off to it's own, dedicated application.
Number 3 is what you're going to do in preformance-critical server type applications, but the minimal performance gain you get with this approach is 1: very difficult to achieve, 2: very easy to screw up, and 3: not the only or even most compelling reason people generally take this approach. Rather, people typically take this approach when they need the logging service to be seperated from the applications using it.
Which OS are you using?
Not sure about specific library's, but one of the classical approaches to this sort of problem is to use a logging queue, which is worked by a writer thread, who's job is purely to write the log file.
You need to be aware, either with a threaded approach, or a multi-process approach that the write queue may back up, meaning it needs to be managed, either by discarding entries or by slowing down your application (which is obviously easier if it's the threaded approach).
It's also common to have some way of categorising your logging output, so that you can have one section of your code logging at a high level, whilst another section of your code logs at a much lower level. This makes it much easier to manage the amount of output that's being written to files and offers you the option of releasing the code with the logging in it, but turned off so that it can be used for fault diagnosis when installed.
As I know critical section has less weight.
Critical section
Using critical section
If you use gcc, you could use atomic accesses. Link.
Frankly, a Mutex is the only way you really want to do that, so it's always going to be slow in your case because you're using so many print statements.... so to solve your question then, don't use so many print_f statements; that's your problem to begin with.
Okay, is your solution using a mutex to print? Perhaps you should have a mutex to a message queue which another thread is processing to print; that has a potential hang up, but I think will be faster. So, use an active logging thread that spins waiting for incoming messages to print. The networking solution could work too, but that requires more work; try this first.
What you can do is to have one queue per thread, and have the logging thread routinely go through each of these and post the message somewhere.
This is fairly easy to set up and the amount of contention can be very low (just a pointer swap or two, which can be done w/o locking anything).
I have a very large, complex (million+ LOC) Windows application written in C++. We receive a handful of reports every day that the application has locked up, and must be forcefully shut down.
While we have extensive reporting about crashes in place, I would like to expand this to include these hang scenarios -- even with heavy logging in place, we have not been able to track down root causes for some of these. We can clearly see where activity stopped - but not why it stopped, even in evaluating output of all threads.
The problem is detecting when a hang occurs. So far, the best I can come up with is a watchdog thread (as we have evidence that background threads are continuing to run w/out issues) which periodically pings the main window with a custom message, and confirms that it is handled in a timely fashion. This would only capture GUI thread hangs, but this does seem to be where the majority of them are occurring. If a reply was not received within a configurable time frame, we would capture a memory and stack dump, and give the user the option of continuing to wait or restarting the app.
Does anyone know of a better way to do this than such a periodic polling of the main window in this way? It seems painfully clumsy, but I have not seen alternatives that will work on our platforms -- Windows XP, and Windows 2003 Server. I see that Vista has much better tools for this, but unfortunately that won't help us.
Suffice it to say that we have done extensive diagnostics on this and have been met with only limited success. Note that attaching windbg in real-time is not an option, as we don't get the reports until hours or days after the incident. We would be able to retrieve a memory dump and log files, but nothing more.
Any suggestions beyond what I'm planning above would be appreciated.
The answer is simple: SendMessageTimeout!
Using this API you can send a message to a window and wait for a timeout before continuing; if the application responds before timeout the is still running otherwise it is hung.
One option is to run your program under your own "debugger" all the time. Some programs, such as GetRight, do this for copy protection, but you can also do it to detect hangs. Essentially, you include in your program some code to attach to a process via the debugging API and then use that API to periodically check for hangs. When the program first starts, it checks if there's a debugger attached to it and, if not, it runs another copy of itself and attaches to it - so the first instance does nothing but act as the debugger and the second instance is the "real" one.
How you actually check for hangs is another whole question, but having access to the debugging API there should be some way to check reasonably efficiently whether the stack has changed or not (ie. without loading all the symbols). Still, you might only need to do this every few minutes or so, so even if it's not efficient it might be OK.
It's a somewhat extreme solution, but should be effective. It would also be quite easy to turn this behaviour on and off - a command-line switch will do or a #define if you prefer. I'm sure there's some code out there that does things like this already, so you probably don't have to do it from scratch.
A suggestion:
Assuming that the problem is due to locking, you could dump your mutex & semaphore states from a watchdog thread. With a little bit of work (tracing your call graph), you can determine how you've arrived at a deadlock, which call paths are mutually blocking, etc.
While a crashdump analysis seems to provide a solution for identifying the problem, in my experience this rarely bears much fruit since it lacks sufficient unambiguous detail of what happened just before the crash. Even with the tool you propose, it would provide little more than circumstantial evidence of what happened. I bet the cause is unprotected shared data, so a lock trace wouldn't show it.
The most productive way of finding this—in my experience—is distilling the application's logic to its essence and identifying where conflicts must be occurring. How many threads are there? How many are GUI? At how many points do the threads interact? Yep, this is good old desk checking. Leading suspect interactions can be identified in a day or two, then just convince a small group of skeptics that the interaction is correct.
I have a program that I would like to run on just one CPU so it doesn't take up too much system resources. The problem is, it makes a call into an external DLL that automatically uses all available CPU cores. I do not have the source code to the external DLL. How can I limit the DLL to only using one CPU?
EDIT: Thanks for the help, here is the code I used to limit to one CPU (Windows):
// Limit the process to only 1 thread so we don't chew up system resources
HANDLE ProcessHandle = GetCurrentProcess();
DWORD ProcessAffinityMask;
DWORD SystemAffinityMask;
if(GetProcessAffinityMask(ProcessHandle,&ProcessAffinityMask,&SystemAffinityMask)
&& SystemAffinityMask != 0)
{
// Limit to 1 thread by masking all but 1 bit of the system affinity mask
DWORD NewProcessAffinityMask = ((SystemAffinityMask-1) ^ SystemAffinityMask) & SystemAffinityMask;
SetProcessAffinityMask(ProcessHandle,NewProcessAffinityMask);
}
EDIT: Turns out Brannon's approach of setting process priority works even better for what I want, which is to keep the process from chewing up resources. Here's that code (Windows):
// Make the process low priority so we don't chew up system resources
HANDLE ProcessHandle = GetCurrentProcess();
SetPriorityClass(ProcessHandle,BELOW_NORMAL_PRIORITY_CLASS);
You could set the CPU affinity of your program. Try the SetProcessAffinityMask function on Windows or sched_setaffinity on Linux.
Setting processor affinity is the wrong approach. Let the OS handle scheduling.
If the machine is sitting idle, you want to use as much processor as you can. Otherwise you're doing less work for no reason. If the machine is busy, then you want to make use of "free" cycles and not adversely affect other processes.
Windows has this functionality built-in. The proper solution for this is to set the base priority of the process.
See http://msdn.microsoft.com/en-us/library/ms686219(VS.85).aspx for details on SetPriorityClass().
If you want to test this without writing any code, use Task Manager to change the priority of your process.
Normally, a dll lives in the same thread/memory space as the code that calls it. The act of calling a DLL itself should not create threads. If calling the DLL seems to create more threads, that means that the DLL itself is creating the threads somewhere in it's code. If you don't have any source code or documentation for the DLL, there isn't much you can do about it (and if you want the DLL to do its job, there isn't much you should do about this).
You might try playing with the priority of your application - setting it to low might change the CPU usage even if it doesn't change what threads are created. But it seems likely that what you will really want is to get documentation for this beast. Without knowing how code works, in general, there isn't much you can do to change how it works. No super genius can change that.
Er...... why? Seriously, why would you limit a library that's capable of giving you additional performance in such a way? Are you trying to access a shared resource or something? One would think that a multi-threaded library would be capable of handling this safely.
Unless there's something you're not mentioning, I can't see any valid reason for even trying to limit a multi-threaded library to a single thread.
So your program uses one thread, but you don't want the external DLL to use more than one thread? You don't have much control over what the external DLL does, but some approaches might be:
Use the "Half-Sync/Half-Async: An Architectural Pattern for Efficient and Well-structured Concurrent I/O" design pattern to queue work items from your one thread to the external DLL.
Or since the other DLL will be loaded in your process, you might be able to set your process or threads' processor affinity to just one CPU. See Raymond Chen's "Psychic debugging: Why your expensive four-processor machine is ignoring three of its processors".
You didn't say what platform this is for. I'm going to assume windows here.
Create the child process and associate it with a Job Object. You can then set the processor affinity for that job object to include only one of the available CPU cores. The child process is not able to change the affinity mask to anything that is not a subset of the processor affinity for the job object. Additionally, you should remember not to set the limit JOB_OBJECT_LIMIT_BREAKAWAY_OK or the extended limit JOB_OBJECT_LIMIT_SILENT_BREAKAWAY_OK on the job or else the child process will be able to break out of the job.
Additionally, you can set the priority and scheduling class for the job. Perhaps it will be sufficient to create the child process at a lower CPU and/or IO priority level?