stack: 0xb7da6014 has value 3084541972Code:stack = new char[STACK_SIZE];
0xb7da6012 has value 3084541970
0xb7da6016 has value 3084541974
Right before
stack: 0xb7da6014 has value 3084541972Code:delete[] stack;
0xb7da6012 has value 3084541970
0xb7da6016 has value 3084541974
Sorry, is this "stack" the block of memory you actually pass as the pointer to "stack" in your thread, or is it some other form of stack?
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
You must monitor stack + SIZE_STACK * sizeof(char), not stack + 4.
Data is written either at the end of the allocated memory or at the beginning (though the beginning is more likely).
Originally Posted by Adak
Ok, well I'm just copying the sample code that we were given to set up the ucontext_t. I also have other stacks that I set up the same way, only difference is that they are part of a struct, and this one isn't. I'll try using stack/vector/smart_ptr once I figure out how they fit in to what I'm doing.
This is how the thread gets set up
Code:cleanup = new ucontext_t; getcontext(cleanup); stack = new char[STACK_SIZE]; cleanup->uc_stack.ss_sp = stack; cleanup->uc_stack.ss_size = STACK_SIZE; cleanup->uc_stack.ss_flags = 0; cleanup->uc_link = NULL; makecontext(cleanup,(void(*)())((thread_startfunc_t)thread_finish),1,arg);
std::stack is basically a stack. You push onto it or pop something off.
std::vector is a dynamic array. You can fill it with information and it will grow if the size is insufficient. It works like any C-style array.
std::tr1::smart_ptr handles the pointers for you, saving you from calling delete. By handling the resource management, it gives much less change for leaks or errors.
And do not cast function pointers. If done properly, a cast will not be necessary. If it does not compile, then you are not passing a compatible function.
And you create only one stack, yes?
As Elysia says, maybe you need to check the memory immediately AFTER the stack too.
Also, I think ss_sp should point at the BASE of the stack, which would be ((stack + STACK_SIZE) & ~15) [aligned to 16 bytes at no extra charge].
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
STACK_SIZE * sizeof(char) gets printed as 262144 so that converted to hex is 40000.
stack starts at 0xb7d13014
+40000 is 0xb7d53014 with value 3083837460
-40000 is 0xb7cd3014 with value 3083313172
values don't change
I create several stacks, one for each thread.
Just for fun I moved the delete of the stack to right after I create it and no segfault, so I guess that means that it gets corrupted somewhere in between when I make it and when I delete it, as opposed to being screwed up before I make it.
Are you sure you're in sync? Have you done a clean rebuild with -g? If that line of code has truly already executed, there's no reason for valgrind to complain about it.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
I think I know why it's segfaulting. For those not familiar with ucontext_t, theres a uc_link parameter that says, when a thread (ucontext_t) is finished executing, execute this thread (ucontext_t) next. All threads I create, I want to execute my cleanup function at the end. The cleanup function is it's own ucontext_t. When there are no more remaining threads, I want to delete my cleanup thread and exit the program. The problem is, I suppose, I'm trying to delete the stack belonging to the cleanup thread, while I'm currently running the cleanup thread.
Basically the last chain of events are:
Thread Z finishes executing
Thread Z swaps context with Cleanup Thread
Cleanup Thread adds Z to list of Threads that will be deleted
Cleanup Thread sees that there are no more active threads
Cleanup Thread deletes all of the threads
Cleanup Thread tries to delete it's own stack --> segfault
Last edited by jcafaro10; 02-04-2009 at 11:44 AM.
...Then it would not segfault on the delete, but the accessing of freed memory...
But the result would be the same. Suppose that freeing the memory unmaps it, so that those addresses will cause a segfault. You call delete -- it pushes a return address onto the stack. It frees the stack. In order to return, it must read the stack, which has just been deallocated -- boom.
It's not the same sort of failure as when the heap management walks off into neverland, but it would sure look like it.
Having said all that, I think it's unlikely that the pages are unmapped when the memory is freed, unless these stacks are rather large. Honestly, my hunch is that something somewhere else is buggy, and trashing the heap. It might not have anything to do with the stack at all.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
It makes sense I guess because there isn't really any difference between this stack and the stack associated with any of the other thread contexts. I can delete all of those stacks just fine. The only difference is, I'm deleting them from a different context. When I try and delete the stack belonging to the context I'm running on, I segfault. Nothing can be accessing the stack after I delete it because I call exit(0) so perhaps it's something else. I'll look into it more. Thanks for the help all, I appreciate it
