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

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

Offline Loaden

  • Lives here!
  • ****
  • Posts: 1014
Re: Is CC crash, or Debugger plugin?
« Reply #90 on: August 28, 2011, 04:11:38 pm »
Oh, waiting.
I forgot test one parser per whole workspace. :(

EDIT: Test done, works well for me.
« Last Edit: August 28, 2011, 04:39:13 pm by Loaden »
Logged

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #91 on: August 28, 2011, 04:26:17 pm »
As far as I can tell, the most bugs are coming out when you test in production.
Run it for a week with complex projects and then call it stable :)
But what you do is commit, then do some tests (you can say what tests you do) and then call it stable 15 minutes after the commit. :)

You even don't have an automatic test suite for the parser!
How can you be sure that you've not broken the parser with a simple change somewhere in the code?
And the last commits are not simple changes :)
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 #92 on: August 28, 2011, 04:45:07 pm »
I am now work environment using Eclipse + CDT + CMake, not CB.
So I am afraid there is not enough time to test.
I present all of the commit, just to maintain existing code.
Logged

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5930
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Is CC crash, or Debugger plugin?
« Reply #93 on: August 29, 2011, 07:02:38 am »
Here is my points:
1, we must use some automatic test mechanism, otherwise, it's hard to find bugs.
2, TokensTree are shared resource. and a Token*(or a TokenIdx) can be invalid.
For example:
step one: you create a browser tree
step two: you parserthread has add some more Tokens to the TokensTree, or maybe, it delete some Tokens.
step three: Your browsertree entry will become invalid, this is quite simple, because an browsertree entry use a Token*, if you change the TokensTree, the Token* may become invalid.

look at the declaration:
Code
class CBTreeData : public wxTreeItemData
{
public:
    CBTreeData(SpecialFolder sf = sfToken, Token* token = 0, short int kindMask = 0xffff, int parentIdx = -1) :
        m_Token(token),
        m_KindMask(kindMask),
        m_SpecialFolder(sf),
        m_TokenIndex(token ? token->m_Index : -1),
        m_TokenKind(token ? token->m_TokenKind : tkUndefined),
        m_TokenName(token ? token->m_Name : _T("")),
        m_ParentIndex(parentIdx),
        m_Ticket(token ? token->GetTicket() : 0)
    {
    }
    Token*        m_Token;
    short int     m_KindMask;
    SpecialFolder m_SpecialFolder;
    int           m_TokenIndex;
    TokenKind     m_TokenKind;
    wxString      m_TokenName;
    int           m_ParentIndex;
    unsigned long m_Ticket;
};

So, the solution should be:
1, a browser tree(and tree entry) is only valid when you build it after all parserthreads have finished their work.
2, if the TokensTree is modified by the parserthread, we need update/redraw browsertree.

So, I think if the parserthread is still working, it is not safe to build the browsertree. The only time to build the browsertree is all parserthread are done, and the TokensTree is at that time is frozen, the browsertree is safe to build. Every modification on the Tokenstree should trigger a re-flash on the browsertree.
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 #94 on: September 02, 2011, 12:49:35 pm »
Just started testing the next changes in CC and it seems it is stable. 2-3 hours only.
But there is one problem in the latest versions (not sure when it stopped working): Completion for the includes doesn't work.

I'm typing "#include <st|" then pressing ctrl+space and nothing shows. (| is where my cursor is at the moment, when I pressed ctrl+space).
This feature used to work at some time and it was great:)

Latest debugger branch on Centos Linux 5.6 amd64 with gcc-4.1.2
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 #95 on: September 02, 2011, 12:58:17 pm »
Quote from: oBFusCATed on September 02, 2011, 12:49:35 pm
Just started testing the next changes in CC and it seems it is stable. 2-3 hours only.
But there is one problem in the latest versions (not sure when it stopped working): Completion for the includes doesn't work.

I'm typing "#include <st|" then pressing ctrl+space and nothing shows. (| is where my cursor is at the moment, when I pressed ctrl+space).
This feature used to work at some time and it was great:)

Latest debugger branch on Centos Linux 5.6 amd64 with gcc-4.1.2
I stumbled over it also:
there is a new option: "Settings -> Editor... -> Code completion -> Code completion -> Enable headers code-completion", that is unchecked by default.

@all devs:
I would prefer, not to change former behaviour, if settings are made configurable.
Logged

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Is CC crash, or Debugger plugin?
« Reply #96 on: September 02, 2011, 01:04:07 pm »
Quote from: jens on September 02, 2011, 12:58:17 pm
@all devs:
I would prefer, not to change former behaviour, if settings are made configurable.
me too :)
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 #97 on: September 02, 2011, 01:07:21 pm »
Loaden:
Can you make the header completion to be case insensitive?
(there is option controlling this for the normal completion, which should be taken into account)

My problem is that if I have mixed case header file and If I type only lower cases, the first wrong character closes the completion list :(
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 #98 on: September 02, 2011, 01:29:33 pm »
Quote from: oBFusCATed on September 02, 2011, 12:49:35 pm
Just started testing the next changes in CC and it seems it is stable. 2-3 hours only.
Me too, but I found a crash pretty fast (on Windows), luckily its already fixed in head.
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 #99 on: September 02, 2011, 01:44:16 pm »
Steps to reproduce?
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 #100 on: September 12, 2011, 04:26:17 pm »
I have new deadlock here (debugger branch r7444) :
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  0x00002ba4c8de5b1b in wxCriticalSection::Enter (this=0x2aaab3e9a980) at /usr/include/wx-2.8/wx/thread.h:271
#5  0x00002ba4c8de5b45 in wxCriticalSectionLocker::wxCriticalSectionLocker (this=0x7fffba483d50, cs=...) at /usr/include/wx-2.8/wx/thread.h:286
#6  0x00002aaab3c03ee3 in Parser::IsFileParsed (this=0x4ee4400, filename=...) at parser/parser.cpp:1308
#7  0x00002aaab3bf321c in NativeParser::GetProjectByFilename (this=0x3ede040, filename=...) at nativeparser.cpp:269
#8  0x00002aaab3bb88b0 in CodeCompletion::OnReparsingTimer (this=0x3eddfc0, event=...) at codecompletion.cpp:1935
#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 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#19 0x0000003b399e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#20 0x0000003b39a3b5d1 in wxDialog::ShowModal (this=<value optimized out>) at ./src/gtk/dialog.cpp:146
#21 0x0000003b39b017ed in wxGetSingleChoiceIndex (message=<value optimized out>, caption=<value optimized out>, n=<value optimized out>, choices=<value optimized out>, parent=<value optimized out>) at ./src/generic/choicdgg.cpp:127
#22 0x0000003b39b01915 in wxGetSingleChoiceIndex (message=<value optimized out>, caption=<value optimized out>, aChoices=<value optimized out>, parent=<value optimized out>, x=<value optimized out>, y=<value optimized out>, centre=<value optimized out>, width=Could not find the frame base for "wxGetSingleChoiceIndex(wxString const&, wxString const&, wxArrayString const&, wxWindow*, int, int, bool, int, int)".
)
    at ./src/generic/choicdgg.cpp:146
#23 0x00002aaab3bc7d26 in CodeCompletion::OnGotoDeclaration (this=0x3eddfc0, event=...) at codecompletion.cpp:2932
#24 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#25 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#26 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#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 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#46 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#47 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#48 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#49 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#50 0x0000003744cfce80 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1308
#51 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#52 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#53 0x0000003b39af8b46 in wxWindowBase::TryParent (this=<value optimized out>, event=<value optimized out>) at ./src/common/wincmn.cpp:2661
#54 0x0000003744cfce90 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1314
#55 0x00002aaab6f71ced in wxMenuCmd::Exec (this=0x4e89950, origin=0x2aaaac219ac0, client=0x2aaaac219ac0) at menuutils.cpp:543
#56 0x00002aaab6f64b11 in wxKeyBinder::OnChar (this=0x4e71880, event=..., next=0x2aaaac219ac0) at keybinder.cpp:1429
#57 0x00002aaab6f64c3b in wxBinderEvtHandler::OnChar (this=0x2aaaac21bc70, p=...) at keybinder.cpp:791
#58 0x0000003744cfcbff in wxEvtHandler::ProcessEventIfMatches (entry=<value optimized out>, handler=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1239
#59 0x0000003744cfcd9f in wxEventHashTable::HandleEvent (this=<value optimized out>, event=<value optimized out>, self=<value optimized out>) at ./src/common/event.cpp:906
#60 0x0000003744cfcee9 in wxEvtHandler::ProcessEvent (this=<value optimized out>, event=<value optimized out>) at ./src/common/event.cpp:1301
#61 0x0000003b399f8ef6 in gtk_window_key_press_callback (widget=<value optimized out>, gdk_event=<value optimized out>, win=<value optimized out>) at ./src/gtk/window.cpp:1034
#62 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#63 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#64 0x000000373f61b2ed in ?? () from /lib64/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#65 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#66 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#67 0x0000003b3882d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#68 0x0000003b3883b7fb in gtk_window_propagate_key_event () from /usr/lib64/libgtk-x11-2.0.so.0
#69 0x0000003b3883e57b in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#70 0x0000003b3872ffcd in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#71 0x000000373f60b08a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#72 0x000000373f61b8e6 in ?? () from /lib64/libgobject-2.0.so.0
#73 0x000000373f61c516 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#74 0x000000373f61c923 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#75 0x0000003b3882d79e in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#76 0x0000003b38729785 in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0
#77 0x0000003b3872a6d1 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0
#78 0x0000003b3824689c in ?? () from /usr/lib64/libgdk-x11-2.0.so.0
#79 0x000000373ee2cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#80 0x000000373ee2fc0d in ?? () from /lib64/libglib-2.0.so.0
#81 0x000000373ee2ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#82 0x0000003b3872aa63 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#83 0x0000003b399e456d in wxEventLoop::Run (this=<value optimized out>) at ./src/gtk/evtloop.cpp:76
#84 0x0000003b39a72378 in wxAppBase::MainLoop (this=<value optimized out>) at ./src/common/appcmn.cpp:312
#85 0x0000000000449d8a in CodeBlocksApp::OnRun (this=0x32d5090) at app.cpp:788
#86 0x0000003744c99cc1 in wxEntry (argc=<value optimized out>, argv=<value optimized out>) at ./src/common/init.cpp:448
#87 0x000000000044d83c in main (argc=1, argv=0x7fffba4867f8) at app.cpp:260

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 #101 on: September 12, 2011, 09:30:00 pm »
Loaden:
This is pretty major deadlock here!!!!
Because you are taking the lock in CodeCompletion::OnGotoDeclaration, for very long time (the lock is taken during the dialog.ShowModal()), and if you call a function which takes the lock, you get a deadlock, pretty scary stuff.

One solution is:
0. take the lock
1. generate the list of matches
2. release the lock
3. show the dialog

Keep in mind the the event loop is running when you call ShowModal() and other event handlers could be called.
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 #102 on: September 14, 2011, 01:43:42 am »
Here is a patch that should fix the problem: http://smrt.is-a-geek.org/codeblocks/patches/goto_declr_deadlock.patch

Please test and report if there are problems, if there are no problems in the next couple of days, I'll commit it.
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: 5930
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Is CC crash, or Debugger plugin?
« Reply #103 on: September 14, 2011, 08:26:02 am »
Quote from: oBFusCATed on September 14, 2011, 01:43:42 am
Here is a patch that should fix the problem: http://smrt.is-a-geek.org/codeblocks/patches/goto_declr_deadlock.patch

Please test and report if there are problems, if there are no problems in the next couple of days, I'll commit it.
I review the patch, but I don't think this patch release the lock before showing the selection dialog.
After the patch, it looks like:
Code

    {
        TRACK_THREAD_LOCKER(s_TokensTreeCritical);
        wxCriticalSectionLocker locker(s_TokensTreeCritical);
        THREAD_LOCKER_SUCCESS(s_TokensTreeCritical);

        TokensTree* tokens = m_NativeParser.GetParser().GetTokensTree();

        .......
        .......

        if (token)
        {
            if (   wxGetKeyState(WXK_CONTROL)
                && wxGetKeyState(WXK_SHIFT)
                && (  event.GetId() == idGotoDeclaration
                   || event.GetId() == idGotoImplementation ) )
            {
                // beware this  code can lead to a deadlock (because of double locking from single thread)
                CCDebugInfo info(nullptr, &m_NativeParser.GetParser(), token);
                info.ShowModal();
            }
            else if (isImpl)
            {
                targetEditor = edMan->Open(token->GetImplFilename());
                editorLine = token->m_ImplLine - 1;
            }
            else if (isDecl)
            {
                targetEditor = edMan->Open(token->GetFilename());
                editorLine = token->m_Line - 1;
            }

            tokenFound = true;
        }
    }

Still not safe to show the CCDebugInfo dialog.
Can you give some explanation?
« Last Edit: September 14, 2011, 08:30:03 am 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 #104 on: September 14, 2011, 08:31:55 am »
Unfortunately you're right :(

p.s. I don't care for CCDebugInfo, it is not something a user uses in his daily programming tasks.
« Last Edit: September 14, 2011, 09:46:25 am 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!]
Pages: 1 2 3 4 5 6 [7] 8   Go Up
« previous next »