Working with C and Win32, I have a problem where my program freezes instead of closing when a quit message is posted(Alt-F4 for example), and I have to end the process with task manager.
I have this in my main loop:(problem solved)
MSG msg;
while(1)
{
while(PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE))
{
if(msg.message == WM_QUIT)
{
terminate = 1;
while(terminate != 3) //each thread increments "terminate" by 1 before returning
{
Sleep(1);
}
return 0;
}
DispatchMessage(&msg);
}
Sleep(1);
}
It will print "OK!" in the console and then freeze.
I think this could be because I have multiple threads and they are not terminated properly (but I read that if I return from my main() function the other threads should be killed automatically). If it helps one of those threads is an OpenGL rendering thread.
The main function is only just a thread, you are terminating just that one. However, for a process to end, all threads need to be properly terminated or it will run forever. You'll need to keep a reference the threads and terminate them once you receive the WM_QUIT message.
Exit is to exit from the entire process. Your process will clean up when you call exit, e.g. Call the function registered with atexit, or call destructor of global object in case of c++. What about abort(), or terminateProcess.
Related
The perfect way to run and terminate threads in Windows using C is mentioned in the answer below!
There are 2 problems I'm facing with the current implementation method :
I can't forcibly stop the thread. For some reason it still continues. For example I have a for loop, it runs a function of which this thread example is a part. When this function is called 4-5 times, I see multiple animations on the screen suggesting that the previous threads didn't stop even when I called TerminateThread function at the end of my function.
At times the thread doesn't run at all and no animation is displayed on the screen. Which is if my function code runs really fast or for some other reason, I feel like the thread is being killed before it initializes. Is there a way to wait until init of thread?
How do I fix these issues?
Correct way of terminating threads is to signal the thread and let it finish gracefully, i.e.:
(updated to use interlocked intrinsics instead of a volatile flag, as per #IInspectable's comment below)
HANDLE eventHnd;
HANDLE threadHnd;
LONG isStopRequested = 0; // 1 = "stop requested"
static DWORD WINAPI thread_func(LPVOID lpParam)
{
do
{
// wait until signalled from a different thread
WaitForSingleObject(eventHnd, INFINITE);
// end thread if stop requested
if (InterlockedCompareExchange(&isStopRequested, 0, 0) == 1)
return 0;
// otherwise do some background work
Sleep(500);
} while (true);
}
The eventHnd variable is initialized using the CreateEvent function, and the stopRequested variable is just a boolean flag you can set from your main program:
// this creates an auto-reset event, initially set to 'false'
eventHnd = CreateEvent(NULL, false, false, NULL);
InterlockedExchange(&isStopRequested, 0);
threadHnd = CreateThread(NULL, 0, Processing_Thread, NULL, 0, NULL);
So, whenever you want to tell the thread do perform a task, you will simply set the event:
SetEvent(eventHnd);
And when you want to end the thread, you will set the flag to true, signal the event, and then wait for the thread to finish:
// request stop
InterlockedExchange(&isStopRequested, 1);
// signal the thread if it's waiting
SetEvent(eventHnd);
// wait until the thread terminates
WaitForSingleObject(threadHnd, 5000);
I am setting a PLOAD_IMAGE_NOTIFY_ROUTINE to detect a specific image name and if there's a match, then terminate it. I am getting a KERNEL_APC_PENDING_DURING_EXIT BSOD though. The BSOD is happening somewhere in my KillProcess function which simply just opens a kernel handle with ObOpenObjectByPointer then calls ZwTerminateProcess on that handle.
What could be wrong? The code works fine outside the routine. Do I have to post it? I am getting a BSOD in my PLOAD_IMAGE_NOTIFY_ROUTINE when I call KillProcess.
Here is my KillProcess function:
NTSTATUS KillProcess(HANDLE ProcessId)
{
PEPROCESS Process;
HANDLE newProcessHandle = NULL;
NTSTATUS status = PsLookupProcessByProcessId(ProcessId, &Process);
do
{
if (!NT_SUCCESS(status))
{
#ifdef DEBUGPRINT
DbgPrint("Process with id %d does not exist\n", ProcessId);
#endif
break;
}
if (NT_SUCCESS(status = ObOpenObjectByPointer(
Process,
OBJ_KERNEL_HANDLE,
NULL,
PROCESS_TERMINATE,
*PsProcessType,
KernelMode,
&newProcessHandle
)))
{
if (newProcessHandle != NULL)
{
status = ZwTerminateProcess(newProcessHandle, 0);
ZwClose(newProcessHandle);
}
else
{
ObDereferenceObject(Process);
break;
}
if (NT_SUCCESS(status))
{
#ifdef DEBUGPRINT
DbgPrint("Successfully killed process with id %d\n", ProcessId);
#endif
}
else
{
#ifdef DEBUGPRINT
DbgPrint("Failed to kill process with id %d\n", ProcessId);
#endif
}
}
else
{
#ifdef DEBUGPRINT
DbgPrint("Failed to open process with id %d\n", ProcessId);
#endif
}
ObDereferenceObject(Process);
} while (FALSE);
return status;
}
The documentation for PsSetLoadImageNotifyRoutine says:
When the main executable image for a newly created process is loaded, the load-image notify routine runs in the context of the new process.
(It also seems likely that when a DLL is loaded, the call is made in the context of the process loading the DLL.)
So from the sounds of it, you are terminating the process whose context you are running in. What's more, you're doing it at a particularly vulnerable point, during a callback for an image load operation. It is not surprising that this causes trouble.
The documentation for ZwTerminateProcess implies that a driver can terminate the current process, provided that it ensures that resources have been freed from the kernel stack, but I don't think that applies in this situation. (Also, I don't know how you'd go about doing that.)
It might instead be possible to suspend the process, and terminate it later from a system thread.
The problem is I was trying to terminate the process in its own context which lead to a BSOD.
Solution:
Create a global variable holding the pid
Set the global variable
In a system thread, check if the global variable has changed
terminate the process
So far I've worked with processes and threads only on Linux platform.
Now I tried to move on Windows. And I got immediately stopped on very simple program.
Can you tell me why my program doesn't write anything if I remove the line with getch?
I want my thread to finish without me pressing anything.
Thank you in advance
#include <windows.h>
#include <stdio.h>
DWORD WINAPI ThreadFunc()
{
printf("lets print something");
return 0;
}
VOID main( VOID )
{
DWORD dwThreadId;
HANDLE hThread;
hThread = CreateThread(
NULL, // default security attributes
0, // use default stack size
ThreadFunc, // thread function
NULL, // argument to thread function
0, // use default creation flags
&dwThreadId); // returns the thread identifier
// Check the return value for success.
if (hThread == NULL)
{
printf( "CreateThread failed (%d)\n", GetLastError() );
}
else
{
_getch();
CloseHandle( hThread );
}
}
If your box is relatively idle, the OS is quilte likely to signal the thread creation request to another core, so allowing the 'main' thread, (the one created by the process loader), to run on quickly. By the time your new thread gets round to calling the OS with the printf call, the main thread has already returned, the state of all threads for that process has been set to 'never run again' and a termination request queued up for it on its inter-processor core driver. The new thread is exterminated there and then and the now-redundant termination request discarded.
I am building a simple debugger for my university class and I have a problem in handling SIGINT.
What I want to do is when the debugger process (from now on PDB) takes a SIGINT signal passes that to the child process (the one that is being actually debugged by PDB).
I am doing this:
pid_t childid;
void catch_sigint(int sig)
{
signal(SIGINT,SIG_DFL);
kill(childid,sig);
}
int debuger (char *address, parm *vars)
{
int ignore=1;
int status;
childid = fork();
signal(SIGINT,catch_sigint);
if(childid==0)
{
ptrace(PTRACE_TRACEME,0, NULL,NULL);
if(execve(address,NULL,NULL)==-1)
{
perror("ERROR occured when trying to create program to trace\n");
exit(1);
}
}
else
{
int f_time=1;
while(1)
{
long system_call;
wait(&status);
if(WIFEXITED(status))break;
if(WIFSIGNALED(status))break;
system_call = ptrace(PTRACE_PEEKUSER,childid, 4 * ORIG_EAX, NULL);
if(!strcmp(vars->category,"process-control") || !strcmp(vars->category,"all"))
ignore = pr_calls(system_call,ignore,limit,childid,vars->mode); //function that takes the system call that is made and prints info about it
if(!strcmp(vars->category,"file-management") || !strcmp(vars->category,"all"))
ignore = fl_calls(system_call,ignore,limit,childid,vars->mode);
if(f_time){ignore=1;f_time=0;}
ptrace(PTRACE_SYSCALL,childid, NULL, NULL);
}
}
signal(SIGINT,SIG_DFL);
return 0;
}
This program runs and forks a child process and execs a program to trace its system calls. That works fine when it doesn't get any signal.
But when in the middle of some tracing I press ctrl+c I expect the child process to stop and PDB to continue and stop (because of this line if(WIFSIGNALED(status))break;. That never happens. The program it traces continues its system calls and prints.
The tracing program is that:
#include <stdio.h>
int main(void)
{
for(;;) printf("HELLO WORLD\n");
return 0;
}
That program continues printing HELLO WORLD even after I hit ctrl+c.
I also observed that the system calls that ptrace gives after ctrl+c are -38 and that the status in wait changes only once after the signal from 1407 (I think is the normal value) to 639 and then back again to 1407 on the next wait.
So what I am doing wrong in that?
The problem it's on this line:
ptrace(PTRACE_SYSCALL,childid, NULL, NULL);
It has to be like that:
ptrace(PTRACE_SYSCALL,childid, NULL, signal_variable);
Where signal_variable is an int declared in global scope so the handler and the debugger can see it. It has a starting value of 0.
The signal handler now takes the signal and passes it in this variable and at the next loop when the ptrace orders the tracee program to continue it sends it the signal too.
That happens because when you trace a program the tracee stops execution when it receives a signal and waits further instruction for what to do with the signal from the tracer through ptrace.
I seem to be running in to a possible deadlock with a pthreads conditional variable.
Here is the code
thread function(){
for (condition){
do work
/* should the thread continue? */
if (exit == 1){
break; /* exit for */
}
} /* end for */
pthread_mutex_lock(&mtxExit);
exit = 0;
pthread_cond_signal(&condVar);
pthread_mutex_unlock(&mtxExit);
}
The main function is as follows:
function main(){
if (thread is still active){
pthread_mutex_lock(&mtxExit);
exit = 1;
pthread_mutex_unlock(&mtxExit);
} /* end if */
while (exit == 1){
pthread_mutex_lock(&mtxExit);
/* check again */
if (exit == 1)
pthread_cond_wait(&condVar, &mtxExit);
pthread_mutex_unlock(&mtxExit);
}
create new thread()
....
}
The code is always getting stuck at cond_wait. :(
EDIT:
Let me add some clarification to the thread to explain what I am doing.
At any given time, I need only one thread running. I have a function that starts the thread, tells it what to do and the main thread continues it work.
The next time the main thread decides it needs to spawn another thread, it has to make sure the thread that was previously started has exited. I cannot have two threads alive at the same time as they will interfere with each other. This is by design and by definition of the problem I am working on.
That is where I am running in to problems.
This is my approach:
Start the thread, let it do its job.
the thread checks in every step of its job to see if it is still relevant. This is where "exit" comes in to picture. The main thread sets "exit" to 1, if it needs to tell the thread that it is no longer relevant.
In most cases, the thread will exit before the main thread decides to spawn another thread. But I still need to factor in the case that the thread is still alive by the time the main thread is ready to start another one.
So the main thread sets the value of "exit" and needs to wait for the thread to exit. I dont want to use pthread_kill with 0 as signal because then main thread will be in a loop wasting CPU cycles. I need the main thread to relinquish control and sleep/wait till the thread exits.
Since I only need one thread at a time, I dont need to worry about scaling to more threads. The solution will never have more than one thread. I just need a reliable mechanism to test if my thread is still alive, if it is, signal it to exit, wait for it to exit and start the next one.
From my testing, it looks like, the main thread is still entering the conditional variable even if the thread may have exited or that the signal is not getting delivered to the main thread at all. And its waiting there forever. And is some cases, in debugger I see that the value of exit is set to 0 and still the main thread is waiting at signal. There seems to be a race condition some where.
I am not a fan of how I set up the code right now, its too messy. Its only a proof of concept right now, I will move to a better solution soon. My challenge is to reliably signal the thread to exit, wait on it to exit.
I appreciate your time.
Did you forget to initialize your condition variable?
pthread_cond_init(&condVar, NULL)
while (exit == 1) {
In the code you quote, the way you quote I do not see any particular problem. It is not clean, but it appears functional. What leads me to believe that somewhere else you are setting exit to 0 without signaling that. Or the thread is getting stuck somewhere doing the work.
But considering the comments which hint that you try to signal one thread to terminate before starting another thread, I think you are doing it wrong. Generally pthread condition signaling shouldn't be relied upon if a signal may not be missed. Though it seems that state variable exit covers that, it is still IMO wrong application of the pthread conditions.
In the case you can try to use a semaphores. While terminating, the thread increments the termination semaphore so that main can wait (decrement) the semaphore.
thread function()
{
for (condition)
{
do work
/* should the thread continue? */
if (exit == 1) {
break; /* exit for */
}
} /* end for */
sem_post(&termSema);
}
function main()
{
if (thread is still active)
{
exit = 1;
sem_wait(&termSema);
exit = 0;
}
create new thread()
....
}
As a general remark, I can suggest to look for some thread pool implementations. Because using a state variable to sync threads is still wrong and doesn't scale to more than one thread. And error prone.
When the code is stuck in pthread_cond_wait, is exit 1 or 0? If exit is 1, it should be stuck.
If exit is 0, one of two things are most likely the case:
1) Some code set exit to 0 but didn't signal the condition variable.
2) Some thread blocked on pthread_cond_wait, consumed a signal, but didn't do whatever it is you needed done.
You have all sorts of timing problems with your current implementation (hence the problems).
To ensure that the thread has finished (and its resources have been released), you should call pthread_join().
There is no need for a pthread_cond_t here.
It might also make more sense to use pthread_cancel() to notify the thread that it is no longer required, rather than a flag like you are currently doing.
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
void *thread_func(void *arg) {
int i;
for (i = 0; i < 10; i++) {
/* protect any regions that must not be cancelled... */
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
/* very important work */
printf("%d\n", i);
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
/* force a check to see if we're finished */
pthread_testcancel();
/* sleep (for clarity in the example) */
sleep(1);
}
return NULL;
}
void main(void) {
int ret;
pthread_t tid;
ret = pthread_create(&tid, NULL, thread_func, NULL);
if (ret != 0) {
printf("pthread_create() failed %d\n", ret);
exit(1);
}
sleep(5);
ret = pthread_cancel(tid);
if (ret != 0) {
printf("pthread_cancel() failed %d\n", ret);
exit(1);
}
ret = pthread_join(tid, NULL);
if (ret != 0) {
printf("pthread_join() failed %d\n", ret);
exit(1);
}
printf("finished...\n");
}
It's also worth noting:
exit() is a library function - you should not declare anything with the same name as something else.
Depending on your specific situation, it might make sense to keep a single thread alive always, and provide it with jobs to do, rather than creating / cancelling threads continuously (research 'thread pools')