« previous next »
Pages: 1 2 [3] 4 5 6 7 8   Go Down

Author Topic: Is CC crash, or Debugger plugin?  (Read 73085 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #30 on: July 14, 2011, 01:56:39 pm »
Loaden: Why are you using global critical section? Why don't you make it a member of the tokens tree (and then add Lock/Unlock methods or getCriticalSection() one)?

I'll test if this fixes my problems, because I had to disable CC, because it was unbearable...

p.s. can't test it before it is merged in the branch...
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Is CC crash, or Debugger plugin?
« Reply #31 on: July 14, 2011, 02:31:49 pm »
Quote from: oBFusCATed on July 14, 2011, 01:56:39 pm
Loaden: Why are you using global critical section? Why don't you make it a member of the tokens tree (and then add Lock/Unlock methods or getCriticalSection() one)?
I agree with you. the critical section should be the member of Tokenstree or maybe Parser class. using a global variable is a bad idea.

But as loaden said, the wxString use reference counting, and not sure it is stable on the multi-thread usage. :D

EDIT
I mean this issue http://forums.wxwidgets.org/viewtopic.php?f=23&t=29705

especially this post:
http://forums.wxwidgets.org/viewtopic.php?f=23&p=127941#p127380
« Last Edit: July 14, 2011, 04:35:29 pm by ollydbg »
Logged
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #32 on: July 22, 2011, 01:27:03 pm »
The tooltip crash seems to be gone, but I've got a deadlock probably...
Here is the backtrace
Code
#0  0x000000373d60d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000373d608e1a in _L_lock_1034 () from /lib64/libpthread.so.0
#2  0x000000373d608cdc in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003744cfa3e9 in wxMutexInternal::Lock (this=<value optimized out>) at ./src/unix/threadpsx.cpp:248
#4  0x00002afe0c53b2f7 in wxCriticalSection::Enter (this=0x2aaab3e98a80) at /usr/include/wx-2.8/wx/thread.h:271
#5  0x00002afe0c53b321 in wxCriticalSectionLocker::wxCriticalSectionLocker (this=0x7fff5b905210, cs=...) at /usr/include/wx-2.8/wx/thread.h:286
#6  0x00002aaab3baca52 in ClassBrowserBuilderThread::ExpandItem (this=0x1f2e7000, item=...) at classbrowserbuilderthread.cpp:1009
#7  0x00002aaab3ba4206 in ClassBrowser::OnTreeItemExpanding (this=0x1f2ce770, event=...) at classbrowser.cpp:798
#8  0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#9  0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#10 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#11 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#12 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#13 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#14 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#15 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#16 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#17 0x0000003b39b3f2a1 in wxGenericTreeCtrl::Expand (this=<value optimized out>, itemId=<value optimized out>) at ./src/generic/treectlg.cpp:1792
#18 0x00002aaab3ba5a7f in ClassBrowser::OnSearch (this=0x1f2ce770, event=...) at classbrowser.cpp:746
#19 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#20 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#21 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#22 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#23 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#24 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#25 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#26 0x0000003b39a3839a in wxComboBox::OnChar (this=<value optimized out>, event=<value optimized out>) at ./src/gtk/combobox.cpp:1193
#27 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#28 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#29 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#30 0x0000003b399f8e7e in gtk_window_key_press_callback (widget=<value optimized out>, gdk_event=<value optimized out>, win=<value optimized out>) at ./src/gtk/window.cpp:1156
#31 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#32 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#33 0x000000373f61b2ed in ?? () from /lib64/libgobject-2.0.so.0
#34 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#35 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#36 0x0000003b3882d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#37 0x0000003b3883b7fb in gtk_window_propagate_key_event () from /usr/lib64/libgtk-x11-2.0.so.0
#38 0x0000003b3883e57b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#39 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#40 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#41 0x000000373f61b8e6 in ?? () from /lib64/libgobject-2.0.so.0
#42 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#43 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#44 0x0000003b3882d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#45 0x0000003b38729785 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#46 0x0000003b3872a6d1 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#47 0x0000003b3824689c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#48 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#49 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#50 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#51 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#52 0x0000003b399e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#53 0x0000003b39a72378 in wxAppBase::MainLoop (this=<value optimized out>) at ./src/common/appcmn.cpp:312
#54 0x0000000000448d0a in CodeBlocksApp::OnRun (this=0x1debc050) at app.cpp:788
#55 0x0000003744c99cc1 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at ./src/common/init.cpp:448
#56 0x000000000044c7bc in main (argc=1, argv=0x7fff5b906d08) at app.cpp:260

What I've done is:
1. Searched for a function in the symbol browser
2. The multi choice dlg showed
3. I've double clicked on a result
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: Is CC crash, or Debugger plugin?
« Reply #33 on: July 22, 2011, 05:12:51 pm »
The crashes still exist?
Logged

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #34 on: July 22, 2011, 05:20:58 pm »
Quote from: Loaden on July 22, 2011, 05:12:51 pm
The crashes still exist?
The original crash is 99% fixed. C::B has not crashed for the last couple of days.

The backtrace I've posted in the previous post is a different problem.
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Is CC crash, or Debugger plugin?
« Reply #35 on: July 22, 2011, 09:20:19 pm »
Quote from: oBFusCATed on July 22, 2011, 01:27:03 pm
The tooltip crash seems to be gone, but I've got a deadlock probably...
[...]

What I've done is:
1. Searched for a function in the symbol browser
2. The multi choice dlg showed
3. I've double clicked on a result

I get the same deadlock, but it happens immediately after I type the searcgstring and hit enter.

I think it happens, because ClassBrowser::OnSearch uses s_TokensTreeCritical and calls m_Tree->Expand(start); in line 746, which leads to a call of ClassBrowser::OnTreeItemExpanding and than ClassBrowserBuilderThread::ExpandItem.
ClassBrowserBuilderThread::ExpandItem also uses s_TokensTreeCritical to create a locker and here it hangs (of course), because we are still in the lock created in ClassBrowserBuilderThread::ExpandItem.
Logged

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #36 on: July 22, 2011, 11:44:32 pm »
Another problem with the tree is that it is flickering very badly during code editing, on my Centos.
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Is CC crash, or Debugger plugin?
« Reply #37 on: July 23, 2011, 01:43:33 pm »
Quote from: oBFusCATed on July 22, 2011, 11:44:32 pm
Another problem with the tree is that it is flickering very badly during code editing, on my Centos.
did you enable the real time parsing (which means parsing while editing), see the code below:
Code
void NativeParser::OnParserEnd(wxCommandEvent& event)
{
    if (!Manager::IsAppShuttingDown())
        Manager::Get()->GetLogManager()->DebugLog(_("NativeParser received parser end event."));

    Parser* parser = static_cast<Parser*>(event.GetEventObject());
    cbProject* project = static_cast<cbProject*>(event.GetClientData());
    const ParsingType type = static_cast<ParsingType>(event.GetInt());

    switch (type)
    {
    case ptCreateParser:
        {
            wxString log(F(_("Project '%s' parsing stage done!"), project
                         ? project->GetTitle().wx_str() : _T("*NONE*")));
            Manager::Get()->GetLogManager()->Log(log);
            Manager::Get()->GetLogManager()->DebugLog(log);
            CC_PROFILE_TIMER_LOG();
        }
        break;

    case ptAddFileToParser:
        Manager::Get()->GetLogManager()->DebugLog(F(_T("Add files to parser for project '%s'"), project
                                                  ? project->GetTitle().wx_str() : _T("*NONE*")));
        break;

    case ptReparseFile:
        Manager::Get()->GetLogManager()->DebugLog(F(_T("Reparsing modified files for project '%s'"), project
                                                  ? project->GetTitle().wx_str() : _T("*NONE*")));
        if (parser != m_Parser)
        {
            std::pair<cbProject*, Parser*> info = GetParserInfoByCurrentEditor();
            if (info.second && info.second != m_Parser)
            {
                Manager::Get()->GetLogManager()->DebugLog(_T("Start switch from OnParserEnd::ptReparseFile"));
                SwitchParser(info.first, info.second);
            }
        }
        break;

    case ptUndefined:
        Manager::Get()->GetLogManager()->DebugLog(F(_T("Parser event handling error of project '%s'"), project
                                                  ? project->GetTitle().wx_str() : _T("*NONE*")));
        return;
    }

    if (!event.GetString().IsEmpty())
        Manager::Get()->GetLogManager()->DebugLog(event.GetString());

    UpdateClassBrowser();
    m_TimerParsingOneByOne.Start(500, wxTIMER_ONE_SHOT);

    event.Skip();
}

look, the UpdateClassBrowser() will always be called after one parse finishes.
Logged
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #38 on: July 23, 2011, 08:02:33 pm »
Of course I have it enabled :)
Probably Freeze and Thaw should be used?
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Is CC crash, or Debugger plugin?
« Reply #39 on: July 25, 2011, 04:40:48 am »
Quote from: oBFusCATed on July 23, 2011, 08:02:33 pm
Of course I have it enabled :)
Probably Freeze and Thaw should be used?
I just read some source code, and find that it use Freeze and Thaw, see:
Code
void ClassBrowserBuilderThread::BuildTree(bool useLock)

You can disable realtime parsing to see whether it happened again.
Logged
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #40 on: July 25, 2011, 12:57:06 pm »
Quote from: oBFusCATed on July 22, 2011, 05:20:58 pm
Quote from: Loaden on July 22, 2011, 05:12:51 pm
The crashes still exist?
The original crash is 99% fixed. C::B has not crashed for the last couple of days.
Unfortunately it crashed again :(
Same backtrace... and again it has happened, when I was hovering with the mouse over a variable :(
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #41 on: July 26, 2011, 01:30:43 pm »
And another lockup (dead lock probably!):

Code
(gdb) bt
#0  0x000000373d60d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000373d608e1a in _L_lock_1034 () from /lib64/libpthread.so.0
#2  0x000000373d608cdc in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003744cfa3e9 in wxMutexInternal::Lock (this=<value optimized out>) at ./src/unix/threadpsx.cpp:248
#4  0x00002b847045a2f7 in wxCriticalSection::Enter (this=0x2aaab3e98a80) at /usr/include/wx-2.8/wx/thread.h:271
#5  0x00002b847045a321 in wxCriticalSectionLocker::wxCriticalSectionLocker (this=0x7fffa337bb30, cs=...) at /usr/include/wx-2.8/wx/thread.h:286
#6  0x00002aaab3c04248 in Parser::Reparse (this=0xde2c9e0, filename=..., isLocal=true) at parser/parser.cpp:692
#7  0x00002aaab3beb227 in NativeParser::ReparseFile (this=0xa1fbd50, project=0xbe0e160, filename=...) at nativeparser.cpp:1229
#8  0x00002aaab3bb5dd9 in CodeCompletion::OnRealtimeParsing (this=0xa1fbcd0, event=...) at codecompletion.cpp:3267
#9  0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#10 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#11 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#12 0x0000003b39af2106 in wxTimerBase::Notify (this=<value optimized out>) at ./src/common/timercmn.cpp:57
#13 0x0000003b399ed2e3 in timeout_callback (data=<value optimized out>) at ./src/gtk/timer.cpp:45
#14 0x000000373ee2d2bb in ?? () from /lib64/libglib-2.0.so.0
#15 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#16 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#17 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#18 0x0000003b386b88ca in gtk_dialog_run () from /usr/lib64/libgtk-x11-2.0.so.0
#19 0x0000003b39a5a7ba in wxMessageDialog::ShowModal (this=<value optimized out>) at ./src/gtk/msgdlg.cpp:117
#20 0x00002b84704b4611 in cbMessageBox (message=..., caption=..., style=256, parent=0x9901230, x=-1, y=-1) at globals.cpp:1219
#21 0x00002aaab3bb78c1 in CodeCompletion::OnGotoDeclaration (this=0xa1fbcd0, event=...) at codecompletion.cpp:2821
#22 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#23 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#24 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#25 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#26 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#27 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#28 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#29 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#30 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#31 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#32 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#33 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#34 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#35 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#36 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#37 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#38 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#39 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#40 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#41 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#42 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#43 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#44 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#45 0x0000003b39a55ed5 in gtk_menu_clicked_callback (widget=<value optimized out>, menu=<value optimized out>) at ./src/gtk/menu.cpp:653
#46 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#47 0x000000373f61b2ed in ?? () from /lib64/libgobject-2.0.so.0
#48 0x000000373f61c748 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#49 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#50 0x0000003b38831e1b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#51 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#52 0x000000373f61b2ed in ?? () from /lib64/libgobject-2.0.so.0
#53 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#54 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#55 0x0000003b3865f3ee in gtk_accel_group_activate () from /usr/lib64/libgtk-x11-2.0.so.0
#56 0x0000003b3865f4ef in gtk_accel_groups_activate () from /usr/lib64/libgtk-x11-2.0.so.0
#57 0x0000003b3883e559 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#58 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#59 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#60 0x000000373f61b8e6 in ?? () from /lib64/libgobject-2.0.so.0
#61 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#62 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#63 0x0000003b3882d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#64 0x0000003b38729785 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#65 0x0000003b3872a6d1 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#66 0x0000003b3824689c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#67 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#68 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#69 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#70 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#71 0x0000003b399e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#72 0x0000003b39a72378 in wxAppBase::MainLoop (this=<value optimized out>) at ./src/common/appcmn.cpp:312
#73 0x0000000000448d0a in CodeBlocksApp::OnRun (this=0x9520050) at app.cpp:788
#74 0x0000003744c99cc1 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at ./src/common/init.cpp:448
#75 0x000000000044c7bc in main (argc=1, argv=0x7fffa337e0b8) at app.cpp:260
« Last Edit: July 26, 2011, 01:33:19 pm by oBFusCATed »
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Is CC crash, or Debugger plugin?
« Reply #42 on: July 26, 2011, 02:37:59 pm »
Quote from: oBFusCATed on July 26, 2011, 01:30:43 pm
And another lockup (dead lock probably!):
Code
#8  0x00002aaab3bb5dd9 in CodeCompletion::OnRealtimeParsing (this=0xa1fbcd0, event=...) at codecompletion.cpp:3267
Unfortunately it seems the real-time parser causes more problems than benefits. I've disabled this for a while now and in fact all my crashes are gone (well also, due to the latest fixes in CC).
Logged
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Is CC crash, or Debugger plugin?
« Reply #43 on: July 26, 2011, 02:40:11 pm »
Quote from: oBFusCATed on July 26, 2011, 01:30:43 pm
Code
#8  0x00002aaab3bb5dd9 in CodeCompletion::OnRealtimeParsing (this=0xa1fbcd0, event=...) at codecompletion.cpp:3267
[...]
#20 0x00002b84704b4611 in cbMessageBox (message=..., caption=..., style=256, parent=0x9901230, x=-1, y=-1) at globals.cpp:1219

#21 0x00002aaab3bb78c1 in CodeCompletion::OnGotoDeclaration (this=0xa1fbcd0, event=...) at codecompletion.cpp:2821
Interesting to note that you had queried to goto a declaration with a resulting message box (true?!) while Re-parsing kicked in - but there should actually be no changes when swapping header/source, or what did you do?
Logged
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #44 on: July 26, 2011, 02:56:20 pm »
Yes, C::B locks and a message box is shown.
I'm not sure what I did exactly, probably I've hit the shortcut for goto declaration. I was over an incomplete include directive.

I was editing the source code. Almost all crashes/lockups happen after I've edit the source code.
Logged
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]
Pages: 1 2 [3] 4 5 6 7 8   Go Up
« previous next »