On 04/14/2013 10:58 PM, Rene Gollent wrote:
On 4/14/13, Matt Madia <mattmadia@xxxxxxxxx> wrote:Deleted referenceable object with non-zero ref count.After some further debugging with Matt, the problem is as follows: The check for a ref count of 1 + object on the stack fails to correctly detect that the object is in fact a stack object, because we're either unable to get thread_info, or the info object returned has stack_base and stack_end set to 0, which of course causes us to be unable to determine that the object is in the thread's stack range. Any ideas how to get around that? I suppose it's too early in the boot process to reliably get thread information?
Yes, at that point the thread management structures have just been initialized and the running "thread" is not actually a thread. I haven't really checked, but I think find_thread() returns 0 (an ID that doesn't refer to any actual thread) until the scheduler is started.
Since get_thread_info() for the current thread normally cannot fail, if a pointer to valid storage for the thread info is provided, the easiest solution is probably to change the code in the BReferenceable destructor to skip the debugger call when get_thread_info() fails. OTOH it is worth checking why the heuristic doesn't work in this case, since neither resume_thread() nor the Signal destructor seem to use a lot of stack.
CU, Ingo
