User forums > Help
crash: codeblocks wx2.6.1 unicode
rickg22:
The "crash protection" avoids crashes by avoiding objects from being deleted twice. how does it work? Simple, it skips the wxYield() in message manager :lol:.
It happened to me that I would get crashes in an event handler, but that event happened to be triggered BEFORE exiting C::B. Other events deleted the object in the middle of the call, and it would wreak havoc. It costed me many hours to figure out what was going on...
That was the reason to add the switch. Crashes due to mishandled events shouldn't concern us, since they could be fixed by enabling the option (yes, the UI becomes a bit staggering but that's a separate problem). If you get a crash with the "crash protection" enabled, it means the problem is not in the events, but something else.
rickg22:
--- Quote from: grv575 on August 23, 2005, 07:30:21 pm ---yeah !topwin && !bottomwin looks right. problem is that having either of those lines (|| or &&) prevents it from crashing if the splitter is on
the Projects tab, but if the splitter is on the Watches tab, I still get the crash.
--- End quote ---
That's because the crash is in wxSplitterWindow, _NOT_ SplitPanel. They're different classes, and the watches tab doesn't use splitpanel.
Mind explaining further (a screenshot before exiting perhaps) how to reproduce the bug? I also need a stack trace with the crash protection enabled. Those stacked idle events in the original report don't look good at all...
grv575:
Screen right before file->close then crash after 1-2 seconds. Enable crash protection, exit, reload, exit - that's what's in this .rpt log.
Btw, same exact behavior with all plugins disabled & code completion disabled.
[attachment deleted by admin]
grv575:
Isolated it to this line:
sdk\xtra_classes.cpp:56
m_splitter->SetSashPosition(ConfigManager::Get()->Read(m_SplitterConfig, (long int)150));
With that commented out, it does not crash at all.
Maybe m_SplitterConfig is no longer valid and it's reading from memory no longer in the address space.
Edit: breakpoint on line 56 right before the crash. GDB backtrace attached.
[attachment deleted by admin]
grv575:
More info:
1 - the crash happens before the destructor - wxSplitPanel::~wxSplitPanel() is called
this (original code) crashes:
m_splitter->SetSashPosition(ConfigManager::Get()->Read(m_SplitterConfig, (long int)150));
this does not:
ConfigManager::Get()->Read(m_SplitterConfig, (long int)150);
this does:
if (m_splitter)
m_splitter->SetSashPosition((long int)307); // hard code value
so it can read the config registry key fine (editor/opened_files_tree_height = 307), but setting the sashposition crashes (even though the wxSplitter is not null).
--- Code: ---wxSplitterWindow::SetSashPosition
void SetSashPosition(int position, const bool redraw = TRUE)
Sets the sash position.
Parameters
position
The sash position in pixels.
redraw
If TRUE, resizes the panes and redraws the sash and border.
Remarks
Does not currently check for an out-of-range value.
--- End code ---
still debugging, but I don't see why it sets the sash position on openfiletree() refresh from the registry on _every_ refresh?
shouldn't this be changed when it is created (splithorizontally(width, height, sashposfromregistry))?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version