Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
About the Class browser crash....
rickg22:
I just noticed something.
m_pTreeTop->Expand(root);
if(platform::gtk)
{
// seems like the "expand" event comes too late in wxGTK,
// so make it happen now
ExpandItem(root);
}
Maybe this is the cause of the crash... ExpandItem seems to be called by the main thread in Windows, while in Linux is called by the worker thread. But I can't really be sure, there are other places where the code changes in the Windows platform.
thomas:
The crash is reproducible under Windows XP here, but it does not occur when running in the debugger, so it will be next to impossible to find it (other than by sheer luck).
Biplab:
--- Quote from: thomas on July 02, 2007, 03:28:54 pm ---The crash is reproducible under Windows XP here, but it does not occur when running in the debugger, so it will be next to impossible to find it (other than by sheer luck).
--- End quote ---
The crash can be reproduced in Debugger, too.
Please see the backtrace generated using GDB in the following thread.
--- Quote ---https://developer.berlios.de/bugs/?func=detailbug&bug_id=11433&group_id=5358
--- End quote ---
thomas:
I found the reason: You delete or Release() the pointer at some point, but you don't invalidate it.
Commenting out the code accessing m_pTreeTop around line 640 in classbrowserbuilderthread.cpp fixes the crash. Thus, the first logical conclusion is that the pointer is null.
However, adding a check for null-ness does not fix the crash. Ergo: the pointer in non-null and non-valid.
Find a delete without m_pTreeTop = 0, or a Release() without, and you have your bug.
mandrav:
--- Quote from: thomas on July 02, 2007, 04:58:22 pm ---I found the reason: You delete or Release() the pointer at some point, but you don't invalidate it.
--- End quote ---
Close but wrong. Anyway, the bug has been closed.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version