Originally Posted by Member88
I'm hoping that kernel engineers can help me with a puzzling issue I am encountering.
Doesn't sound like there is any kernel aspect to the problem.
shows a function twice in the call stack.
Lots of possibilities, such as:
Debugger misunderstands the call stack because the debugger isn't perfect.
Debugger misunderstands the call stack because something corrupted the stack.
The code executed something like the recursion you see as a result of some corrupted memory.
In all cases, there is likely some corrupted memory involved (in the actual failure and probably in the strange stack display).
Is it possible for the call stack of a thread to get corrupted somehow by other threads?
Yes, but typically it is more likely to be corrupted by the same thread (the one actually using that stack).
You may have other reasons (such as the pattern of non reproducibility of the failure) for deciding the bug is more likely cross thread.
If you know assembly language, you generally can look at the asm instructions around the point of failure and those at the start of the function, look at the register values at the point of failure and look at the stack yourself and from all that make a good estimate about what eaxactly was corrupted. Then you usually need to debug again from the start to try to catch the memory corruption in the act.
I don't really know how you chase such bugs if you don't know assembler.
In theory the run time tools for catching writes beyond the end of arrays and similar bugs, should catch a fair fraction of the original bugs leading to such memory clobbers. In practice, my co workers who use such tools to find such bugs usually fail to find them and need me to apply assembler expertise and debugging experience to a more manual approach to solving failures like this.
An example of a cross thread bug fitting this symptom would be passing a pointer to a local object from a function creating a new thread to that thread, then exiting the function so the object no longer has valid memory. If the target thread writes to the object, the original thread might crash with a messed up stack.
That is just one example, since you seem to not understand the sort of thing that might corrupt a stack. There are many possibilities and the above overly specific example is not given as a likely theory.