Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Redundant Crash in CCManager::OnShowCallTip()
Alpha:
--- Quote from: ollydbg on August 12, 2015, 04:10:58 am ---Here, why you use the static_cast<wxScintilla*>(stc)->CallTipCancel();? You want to skip the condition check on m_tabSmartJump? and force to cancel it?
--- End quote ---
Yes; calling base class to force it to cancel.
--- Quote from: ollydbg on August 11, 2015, 03:00:41 pm ---@Alpha, can you explain what the meaning of "// search long term recall" and "// search short term recall" in the function void CCManager::OnShowCallTip(CodeBlocksEvent& event)?
I can't quite understand the related code snippet. Since you have some directory, and hash code in those code.
--- End quote ---
They are remember which page on the calltip was last selected, and show that again first next time it is requested.
Short term recall caches the current calltip, so it can be displayed exactly if a calltip is re-requested in the same location.
Long term recall uses two dictionaries, the first one based on the tip's content, and will display the last shown page when a new calltip is requested that has the same content. The second (fuzzy) dictionary remembers which page was shown based on the typed word prefix (this is to support FortranProject, which uses more dynamic calltips).
ollydbg:
--- Quote from: Alpha on August 12, 2015, 06:13:48 am ---
--- Quote from: ollydbg on August 12, 2015, 04:10:58 am ---Here, why you use the static_cast<wxScintilla*>(stc)->CallTipCancel();? You want to skip the condition check on m_tabSmartJump? and force to cancel it?
--- End quote ---
Yes; calling base class to force it to cancel.
--- End quote ---
OK, thanks, then do we use the wxScintilla::CanTipCancel() in the void CCManager::OnEditorTooltip()?
--- Quote ---
--- Quote from: ollydbg on August 11, 2015, 03:00:41 pm ---@Alpha, can you explain what the meaning of "// search long term recall" and "// search short term recall" in the function void CCManager::OnShowCallTip(CodeBlocksEvent& event)?
I can't quite understand the related code snippet. Since you have some directory, and hash code in those code.
--- End quote ---
They are remember which page on the calltip was last selected, and show that again first next time it is requested.
Short term recall caches the current calltip, so it can be displayed exactly if a calltip is re-requested in the same location.
Long term recall uses two dictionaries, the first one based on the tip's content, and will display the last shown page when a new calltip is requested that has the same content. The second (fuzzy) dictionary remembers which page was shown based on the typed word prefix (this is to support FortranProject, which uses more dynamic calltips).
--- End quote ---
Thanks very much. I briefly understand this.
I'm currently add those text to the comment part in ccmanager.h/cpp files :)
Feel free to adjust.
darksquall57:
Wow ! A lot of work and discussion since my last post :D
--- Quote from: ollydbg on August 11, 2015, 02:30:11 pm ---You see, there is a check "!m_NativeParser.GetParser().Done()", This means there is no other thread running on the TokenTree(At least in the active Parser object), so my question is: do you open several cbp projects in C::B?
--- End quote ---
I'm working only with 1 project opened at the same time.
--- Quote from: ollydbg on August 11, 2015, 02:30:11 pm ---EDIT: Maybe, you have two ccPlugins, and with one plugin, you have update the iterator, but this iterator point to the vector updated by another ccPlugin. (This is just a guess)
--- End quote ---
I don't know, how can I figure this out ?
ollydbg:
--- Quote from: darksquall57 on August 12, 2015, 11:10:01 am ---
--- Quote from: ollydbg on August 11, 2015, 02:30:11 pm ---You see, there is a check "!m_NativeParser.GetParser().Done()", This means there is no other thread running on the TokenTree(At least in the active Parser object), so my question is: do you open several cbp projects in C::B?
--- End quote ---
I'm working only with 1 project opened at the same time.
--- End quote ---
OK, so even a single project could cause the crash bug.
--- Quote ---
--- Quote from: ollydbg on August 11, 2015, 02:30:11 pm ---EDIT: Maybe, you have two ccPlugins, and with one plugin, you have update the iterator, but this iterator point to the vector updated by another ccPlugin. (This is just a guess)
--- End quote ---
I don't know, how can I figure this out ?
--- End quote ---
The Fortran code completion plugin is a SVN external module of our C::B's SVN repo, you can see its source in "\src\plugins\contrib\FortranProject" if you use SVN. If you have already build this plugin, you can disable it from the Plugin manager in the Menu->Plugins->Manager plugins.
ollydbg:
I think I may find the reason why the crash happens by reading the source code. ;)
We have such code:
--- Code: ---void CCManager::OnShowCallTip(CodeBlocksEvent& event)
{
event.Skip();
int tooltipMode = Manager::Get()->GetConfigManager(wxT("ccmanager"))->ReadInt(wxT("/tooltip_mode"), 1);
// 0 - disable
// 1 - enable
// 2 - force single page
// 3 - keybound only
if (tooltipMode == 0)
return;
cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (!ed)
return;
cbCodeCompletionPlugin* ccPlugin = GetProviderFor(ed);
if (!ccPlugin)
return;
cbStyledTextCtrl* stc = ed->GetControl();
if (!stc)
return;
int pos = stc->GetCurrentPos();
int argsPos = wxSCI_INVALID_POSITION;
// save the current tip shown text for later recalling
wxString curTip;
if (!m_CallTips.empty())
curTip = m_CurCallTip->tip;
m_CallTips = ccPlugin->GetCallTips(pos, stc->GetStyleAt(pos), ed, argsPos);
// since m_CallTips get updated, we should update the m_CurCallTip
// But what about if m_CallTips is empty?
if (!m_CallTips.empty() && (event.GetInt() != FROM_TIMER || argsPos == m_CallTipActive))
{
...
Here, we update the m_CurCallTip
...
}
--- End code ---
Please see my comments
--- Code: --- // since m_CallTips get updated, we should update the m_CurCallTip
// But what about if m_CallTips is empty?
--- End code ---
I mean, if m_CallTips is modified, we should update the m_CurCallTip, since m_CurCallTip is an iterator points to the m_CallTips. If m_CallTips is empty, we have no chance to update the m_CurCallTip, then m_CurCallTip becomes a wild pointer.
Am I right? I haven't tested and debug the code, I just read the cc related code time and time again. ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version