Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on September 17, 2011, 03:49:44 pm

Title: The 17 September 2011 build (7452) is out.
Post by: killerbot on September 17, 2011, 03:49:44 pm
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works (http://forums.codeblocks.org/index.php/topic,3232.0.html).

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc452-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc452-TDM.7z

The 17 September 2011 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20110917_rev7452_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 17 September 2011 build (7452) is out.
Post by: Jenna on September 17, 2011, 08:22:18 pm
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo (http://apt.jenslody.de/).
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Dreamy on September 18, 2011, 01:23:34 am
Hi. I've noticed that Start Here page says this build is dated September 13th, About box says it's 4th,
this thread says it's 17th, so I'm curious, what's the actual build date?


If this post does not belong here feel free to remove it.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: killerbot on September 18, 2011, 08:02:41 am
hmm, it was build on the 17th. I have seen such things before too. I guess something are not rebuilding when they should in the incremental build.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Freem on September 18, 2011, 09:58:00 pm
Great job for the CC fixes, thanks a lot! (and for all other stuff too, but CC sounds to have used the most energy)
Title: Re: The 17 September 2011 build (7452) is out.
Post by: scarphin on September 18, 2011, 11:35:00 pm
I'm experiencing a crash on the debuggers nightly branch but I guess it's not related to the debugger so I'm posting it here as advised. Maybe someone can test it on this nightly.
1-Launch cb.
2-Plugins->manage plugins and choose spellchecker plugin.
3-Disable, enable, disable crashes cb.

OS: Win7 SP1
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Static on September 19, 2011, 11:35:11 am
Hi.
Thanks for a great job you have done.
But I want to tell about some inconvenience:
Editor frequently shows a function at the bottom line when I choose it's name in the 'code completion' combobox. So, my first reaction - scroll it! But the focus is still on the combobox and it selects another function as I scroll the mousewheel. Is this a decided behaviour?
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Freem on September 19, 2011, 11:53:13 am
I'm experiencing a crash on the debuggers nightly branch but I guess it's not related to the debugger so I'm posting it here as advised. Maybe someone can test it on this nightly.
1-Launch cb.
2-Plugins->manage plugins and choose spellchecker plugin.
3-Disable, enable, disable crashes cb.

OS: Win7 SP1

The crash occur on win XP pro sp3 too.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: ollydbg on September 19, 2011, 02:25:54 pm
Hi.
Thanks for a great job you have done.
But I want to tell about some inconvenience:
Editor frequently shows a function at the bottom line when I choose it's name in the 'code completion' combobox. So, my first reaction - scroll it! But the focus is still on the combobox and it selects another function as I scroll the mousewheel. Is this a decided behaviour?
My English is not very good, so sorry if I can't understand this inconvenience, can you show us a simple test code? And how to reproduce it.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Static on September 19, 2011, 02:41:51 pm
My English isn't so good too :)
I'll try to explain.

1. Open the file
2. Select some function in the combobox:
(http://img844.imageshack.us/img844/8830/inc1.png)

3. The editor should display this function. I see this almost always:
(http://img59.imageshack.us/img59/6738/inc2.png)
Function name appears at the lowest editor line.

But I want to see the body of this function, I try to scroll it up and... As the combobox is still focused it selects another function.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: oBFusCATed on September 19, 2011, 03:27:02 pm
It happens on linux. The scrolling should be done with the mouse's wheel.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: fubo on September 20, 2011, 09:35:19 am
Still present the issue with Project view:

-Workspace
 - myPrj
   - ..
     - ..
     - app
       + src
   + CMake Files

Turning back to r7288 that is OK.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Calexus on September 20, 2011, 10:28:05 am
Apparently CB still hangs during CC parsing when opening a project in osx. (Snow Leopard me thinks... or possibly Leopard) I haven't verified this my self but it's my understanding that it is the same problem as before and CB works if CC-plug is disabled.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: oBFusCATed on September 20, 2011, 10:35:00 am
fubo: is it possible for you to build C::B from svn sources and bisect the revision where it was broken?

Calexus: Can you give us a backtrace?
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Calexus on September 20, 2011, 02:41:42 pm
Not at the moment no. I'll try to reproduce it my self when I get home.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Calexus on September 20, 2011, 07:49:23 pm
Alright here is a call graph.

I built this using the scripts provided by PaulNavin a couple of weeks ago. Which seems to be working pretty good, I had to move the plugins inside the bundle for cb to find them but other then that everything looks ok. This is revision 7458 but the splash screen says 7456.

I haven't verified this with my friend but I guess it the same problem as he had, cb hangs and the last line in the log is "Create new parser for 'test1'". If I disable cc won't hang.
Code
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6

Call graph:
    2373 Thread_50720   DispatchQueue_1: com.apple.main-thread  (serial)
      2373 start
        2373 main
          2373 wxEntry(int&, wchar_t**)
            2373 CodeBlocksApp::OnRun()
              2373 wxAppBase::MainLoop()
                2373 wxEventLoopManual::Run()
                  2373 wxEventLoop::Dispatch()
                    2373 wxApp::MacDoOneEvent()
                      2373 wxApp::MacHandleOneEvent(void*)
                        2373 wxMacProcessNotifierAndPendingEvents
                          2373 wxAppConsole::ProcessPendingEvents()
                            2373 wxEvtHandler::ProcessPendingEvents()
                              2373 wxEvtHandler::ProcessEvent(wxEvent&)
                                2373 wxEvtHandler::SearchDynamicEventTable(wxEvent&)
                                  2373 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
                                    2373 Parser::OnAllThreadsDone(CodeBlocksEvent&)
                                      2373 Parser::ProcessParserEvent(ParsingType, int, wxString const&)
                                        2373 wxEvtHandler::ProcessEvent(wxEvent&)
                                          2373 wxEvtHandler::SearchDynamicEventTable(wxEvent&)
                                            2373 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
                                              2373 NativeParser::OnParserEnd(wxCommandEvent&)
                                                2373 NativeParser::UpdateClassBrowser()
                                                  2373 ClassBrowser::UpdateView(bool)
                                                    2373 ClassBrowser::BuildTree()
                                                      2373 ClassBrowserBuilderThread::Init(NativeParser*, CBTreeCtrl*, CBTreeCtrl*, wxString const&, void*, BrowserOptions const&, TokensTree*, bool)
                                                        2373 wxMutexInternal::Lock()
                                                          2373 pthread_mutex_lock
                                                            2373 semaphore_wait_signal_trap
    2373 Thread_50731   DispatchQueue_2: com.apple.libdispatch-manager  (serial)
      2373 start_wqthread
        2373 _pthread_wqthread
          2373 _dispatch_worker_thread2
            2373 _dispatch_queue_invoke
              2373 _dispatch_mgr_invoke
                2373 kevent
    2373 Thread_50733: com.apple.CFSocket.private
      2373 thread_start
        2373 _pthread_start
          2373 __CFSocketManager
            2373 select$DARWIN_EXTSN
    2373 Thread_50737
      2373 thread_start
        2373 _pthread_start
          2373 PrivateMPEntryPoint
            2373 wxThreadInternal::MacThreadStart(void*)
              2373 BackgroundThread::Entry()
                2373 wxSemaphore::Wait()
                  2373 wxSemaphoreInternal::WaitTimeout(unsigned long)
                    2373 MPWaitOnSemaphore
                      2373 semaphore_timedwait_trap
    2373 Thread_50738
      2373 thread_start
        2373 _pthread_start
          2373 PrivateMPEntryPoint
            2373 wxThreadInternal::MacThreadStart(void*)
              2373 BackgroundThread::Entry()
                2373 wxSemaphore::Wait()
                  2373 wxSemaphoreInternal::WaitTimeout(unsigned long)
                    2373 MPWaitOnSemaphore
                      2373 semaphore_timedwait_trap
    2373 Thread_50739
      2373 thread_start
        2373 _pthread_start
          2373 PrivateMPEntryPoint
            2373 wxThreadInternal::MacThreadStart(void*)
              2373 BackgroundThread::Entry()
                2373 wxSemaphore::Wait()
                  2373 wxSemaphoreInternal::WaitTimeout(unsigned long)
                    2373 MPWaitOnSemaphore
                      2373 semaphore_timedwait_trap
    2373 Thread_50740
      2373 thread_start
        2373 _pthread_start
          2373 PrivateMPEntryPoint
            2373 wxThreadInternal::MacThreadStart(void*)
              2373 BackgroundThread::Entry()
                2373 wxSemaphore::Wait()
                  2373 wxSemaphoreInternal::WaitTimeout(unsigned long)
                    2373 MPWaitOnSemaphore
                      2373 semaphore_timedwait_trap
    2373 Thread_50754
      2373 thread_start
        2373 _pthread_start
          2373 PrivateMPEntryPoint
            2373 wxThreadInternal::MacThreadStart(void*)
              2373 ClassBrowserBuilderThread::Entry()
                2373 ClassBrowserBuilderThread::BuildTree()
                  2373 ClassBrowserBuilderThread::CollapseItem(wxTreeItemId)
                    2373 wxGenericTreeCtrl::CollapseAndReset(wxTreeItemId const&)
                      2373 wxGenericTreeCtrl::Collapse(wxTreeItemId const&)
                        2373 wxEvtHandler::ProcessEvent(wxEvent&)
                          2373 wxWindowBase::TryParent(wxEvent&)
                            2373 wxEvtHandler::ProcessEvent(wxEvent&)
                              2373 wxWindowBase::TryParent(wxEvent&)
                                2373 wxEvtHandler::ProcessEvent(wxEvent&)
                                  2373 wxWindowBase::TryParent(wxEvent&)
                                    2373 wxEvtHandler::ProcessEvent(wxEvent&)
                                      2373 wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
                                        2373 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
                                          2373 ClassBrowser::OnTreeItemCollapsing(wxTreeEvent&)
                                            2373 ClassBrowserBuilderThread::CollapseItem(wxTreeItemId)
                                              2373 wxMutexInternal::Lock()
                                                2373 pthread_mutex_lock
                                                  2373 semaphore_wait_signal_trap
    2373 Thread_50817
      2373 thread_start
        2373 _pthread_start
          2373 PrivateMPEntryPoint
            2373 wxThreadInternal::MacThreadStart(void*)
              2373 cbThreadPool::cbWorkerThread::Entry()
                2373 wxSemaphore::Wait()
                  2373 wxSemaphoreInternal::WaitTimeout(unsigned long)
                    2373 MPWaitOnSemaphore
                      2373 semaphore_timedwait_trap

Total number in stack (recursive counted multiple, when >=5):
        7       _pthread_start
        7       thread_start
        6       PrivateMPEntryPoint
        6       wxEvtHandler::ProcessEvent(wxEvent&)
        6       wxThreadInternal::MacThreadStart(void*)
        5       MPWaitOnSemaphore
        5       semaphore_timedwait_trap
        5       wxSemaphore::Wait()
        5       wxSemaphoreInternal::WaitTimeout(unsigned long)

Sort by top of stack, same collapsed (when >= 5):
        semaphore_timedwait_trap        11865
        semaphore_wait_signal_trap        4746
        kevent        2373
        select$DARWIN_EXTSN        2373

Edit >> code tags
Title: Re: The 17 September 2011 build (7452) is out.
Post by: oBFusCATed on September 20, 2011, 08:08:03 pm
It looks pretty strange.
There are wx calls in two threads, which is not correct.
If you disable the Symbols browser in Settings -> Editor -> Code completion, the crash should go away.

Loaden: why are you building the tree in a non-gui thread?

p.s. please next time use code tags, so it easier to read.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Calexus on September 20, 2011, 08:17:55 pm
Here is part of the crash report if it's of any help, might be a bit more informative then the call graph.

Code
PID:             47621
Event:           hang
Duration:        5.75s (sampling started after 2 seconds)
Steps:           17 (100ms sampling interval)

Pageins:         1
Pageouts:        0


Process:         CodeBlocks [47621]
UID:             501

  Thread d1a5       DispatchQueue 100
  User stack:
    17 start + 53 (in CodeBlocks) [0x9ef9]
      17 main + 24 (in CodeBlocks) [0xa278]
        17 wxEntry(int&, wchar_t**) + 160 (in libwx_macu-2.8.0.dylib) [0x7db880]
          17 CodeBlocksApp::OnRun() + 32 (in CodeBlocks) [0xc050]
            17 wxAppBase::MainLoop() + 83 (in libwx_macu-2.8.0.dylib) [0x8ebaa3]
              17 wxEventLoopManual::Run() + 136 (in libwx_macu-2.8.0.dylib) [0x9128f8]
                17 wxEventLoop::Dispatch() + 35 (in libwx_macu-2.8.0.dylib) [0x86cc13]
                  17 wxApp::MacDoOneEvent() + 123 (in libwx_macu-2.8.0.dylib) [0x85339b]
                    17 wxApp::MacHandleOneEvent(void*) + 50 (in libwx_macu-2.8.0.dylib) [0x852b72]
                      17 wxMacProcessNotifierAndPendingEvents + 34 (in libwx_macu-2.8.0.dylib) [0x825952]
                        17 wxAppConsole::ProcessPendingEvents() + 105 (in libwx_macu-2.8.0.dylib) [0x7a3b59]
                          17 wxEvtHandler::ProcessPendingEvents() + 123 (in libwx_macu-2.8.0.dylib) [0x82ed0b]
                            17 wxEvtHandler::ProcessEvent(wxEvent&) + 179 (in libwx_macu-2.8.0.dylib) [0x82eeb3]
                              17 wxEvtHandler::SearchDynamicEventTable(wxEvent&) + 86 (in libwx_macu-2.8.0.dylib) [0x82d766]
                                17 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) + 131 (in libwx_macu-2.8.0.dylib) [0x82d6a3]
                                  17 Parser::OnAllThreadsDone(CodeBlocksEvent&) + 848 (in libcodecompletion.so) [0x17f78040]
                                    17 Parser::ProcessParserEvent(ParsingType, int, wxString const&) + 108 (in libcodecompletion.so) [0x17f72ebc]
                                      17 wxEvtHandler::ProcessEvent(wxEvent&) + 179 (in libwx_macu-2.8.0.dylib) [0x82eeb3]
                                        17 wxEvtHandler::SearchDynamicEventTable(wxEvent&) + 86 (in libwx_macu-2.8.0.dylib) [0x82d766]
                                          17 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) + 131 (in libwx_macu-2.8.0.dylib) [0x82d6a3]
                                            17 NativeParser::OnParserEnd(wxCommandEvent&) + 187 (in libcodecompletion.so) [0x17f6293b]
                                              17 NativeParser::UpdateClassBrowser() + 344 (in libcodecompletion.so) [0x17f5f6b8]
                                                17 ClassBrowser::UpdateView(bool) + 840 (in libcodecompletion.so) [0x17f1c958]
                                                  17 ClassBrowser::BuildTree() + 128 (in libcodecompletion.so) [0x17f1be80]
                                                    17 ClassBrowserBuilderThread::Init(NativeParser*, CBTreeCtrl*, CBTreeCtrl*, wxString const&, void*, BrowserOptions const&, TokensTree*, bool) + 57 (in libcodecompletion.so) [0x17f264e9]
                                                      17 wxMutexInternal::Lock() + 17 (in libwx_macu-2.8.0.dylib) [0x824431]
                                                        17 semaphore_wait_trap + 10 (in libSystem.B.dylib) [0x919d8b36]
  Kernel stack:
    17 semaphore_wait_continue + 0 [0x22a88f]

  Thread d1b0       DispatchQueue 1634545000
  User stack:
    17 start_wqthread + 30 (in libSystem.B.dylib) [0x919fe5c6]
      17 _pthread_wqthread + 390 (in libSystem.B.dylib) [0x919fe781]
        17 _dispatch_worker_thread2 + 240 (in libSystem.B.dylib) [0x919fecfe]
          17 _dispatch_queue_invoke + 163 (in libSystem.B.dylib) [0x919fef59]
            17 kevent + 10 (in libSystem.B.dylib) [0x919ff382]
  Kernel stack:
    17 kevent + 97 [0x47a699]

  Thread d1b3     
  User stack:
    17 thread_start + 34 (in libSystem.B.dylib) [0x91a060de]
      17 _pthread_start + 345 (in libSystem.B.dylib) [0x91a06259]
        17 select$DARWIN_EXTSN + 10 (in libSystem.B.dylib) [0x919f7ac6]
  Kernel stack:
    17 sleep + 52 [0x49115a]

  Thread d1b8     
  User stack:
    17 thread_start + 34 (in libSystem.B.dylib) [0x91a060de]
      17 _pthread_start + 345 (in libSystem.B.dylib) [0x91a06259]
        17 PrivateMPEntryPoint + 68 (in CarbonCore) [0x960c954a]
          17 wxThreadInternal::MacThreadStart(void*) + 96 (in libwx_macu-2.8.0.dylib) [0x825130]
            17 BackgroundThread::Entry() + 30 (in libcodeblocks.0.dylib) [0x19bece]
              17 wxSemaphore::Wait() + 36 (in libwx_macu-2.8.0.dylib) [0x824194]
                17 wxSemaphoreInternal::WaitTimeout(unsigned long) + 27 (in libwx_macu-2.8.0.dylib) [0x8240db]
                  17 semaphore_timedwait_trap + 10 (in libSystem.B.dylib) [0x919d8b4e]
  Kernel stack:
    17 semaphore_wait_continue + 0 [0x22a88f]

  Thread d1b9     
  User stack:
    17 thread_start + 34 (in libSystem.B.dylib) [0x91a060de]
      17 _pthread_start + 345 (in libSystem.B.dylib) [0x91a06259]
        17 PrivateMPEntryPoint + 68 (in CarbonCore) [0x960c954a]
          17 wxThreadInternal::MacThreadStart(void*) + 96 (in libwx_macu-2.8.0.dylib) [0x825130]
            17 BackgroundThread::Entry() + 30 (in libcodeblocks.0.dylib) [0x19bece]
              17 wxSemaphore::Wait() + 36 (in libwx_macu-2.8.0.dylib) [0x824194]
                17 wxSemaphoreInternal::WaitTimeout(unsigned long) + 27 (in libwx_macu-2.8.0.dylib) [0x8240db]
                  17 semaphore_timedwait_trap + 10 (in libSystem.B.dylib) [0x919d8b4e]
  Kernel stack:
    17 semaphore_wait_continue + 0 [0x22a88f]

  Thread d1ba     
  User stack:
    17 thread_start + 34 (in libSystem.B.dylib) [0x91a060de]
      17 _pthread_start + 345 (in libSystem.B.dylib) [0x91a06259]
        17 PrivateMPEntryPoint + 68 (in CarbonCore) [0x960c954a]
          17 wxThreadInternal::MacThreadStart(void*) + 96 (in libwx_macu-2.8.0.dylib) [0x825130]
            17 BackgroundThread::Entry() + 30 (in libcodeblocks.0.dylib) [0x19bece]
              17 wxSemaphore::Wait() + 36 (in libwx_macu-2.8.0.dylib) [0x824194]
                17 wxSemaphoreInternal::WaitTimeout(unsigned long) + 27 (in libwx_macu-2.8.0.dylib) [0x8240db]
                  17 semaphore_timedwait_trap + 10 (in libSystem.B.dylib) [0x919d8b4e]
  Kernel stack:
    17 semaphore_wait_continue + 0 [0x22a88f]

  Thread d1bb     
  User stack:
    17 thread_start + 34 (in libSystem.B.dylib) [0x91a060de]
      17 _pthread_start + 345 (in libSystem.B.dylib) [0x91a06259]
        17 PrivateMPEntryPoint + 68 (in CarbonCore) [0x960c954a]
          17 wxThreadInternal::MacThreadStart(void*) + 96 (in libwx_macu-2.8.0.dylib) [0x825130]
            17 BackgroundThread::Entry() + 30 (in libcodeblocks.0.dylib) [0x19bece]
              17 wxSemaphore::Wait() + 36 (in libwx_macu-2.8.0.dylib) [0x824194]
                17 wxSemaphoreInternal::WaitTimeout(unsigned long) + 27 (in libwx_macu-2.8.0.dylib) [0x8240db]
                  17 semaphore_timedwait_trap + 10 (in libSystem.B.dylib) [0x919d8b4e]
  Kernel stack:
    17 semaphore_wait_continue + 0 [0x22a88f]

  Thread d1c3     
  User stack:
    17 thread_start + 34 (in libSystem.B.dylib) [0x91a060de]
      17 _pthread_start + 345 (in libSystem.B.dylib) [0x91a06259]
        17 PrivateMPEntryPoint + 68 (in CarbonCore) [0x960c954a]
          17 wxThreadInternal::MacThreadStart(void*) + 96 (in libwx_macu-2.8.0.dylib) [0x825130]
            17 ClassBrowserBuilderThread::Entry() + 65 (in libcodecompletion.so) [0x17f258d1]
              17 ClassBrowserBuilderThread::BuildTree() + 862 (in libcodecompletion.so) [0x17f256ce]
                17 ClassBrowserBuilderThread::CollapseItem(wxTreeItemId) + 92 (in libcodecompletion.so) [0x17f21bbc]
                  17 wxGenericTreeCtrl::CollapseAndReset(wxTreeItemId const&) + 33 (in libwx_macu-2.8.0.dylib) [0x99a8e1]
                    17 wxGenericTreeCtrl::Collapse(wxTreeItemId const&) + 128 (in libwx_macu-2.8.0.dylib) [0x9a1ab0]
                      17 wxEvtHandler::ProcessEvent(wxEvent&) + 121 (in libwx_macu-2.8.0.dylib) [0x82ee79]
                        17 wxWindowBase::TryParent(wxEvent&) + 88 (in libwx_macu-2.8.0.dylib) [0x969348]
                          17 wxEvtHandler::ProcessEvent(wxEvent&) + 121 (in libwx_macu-2.8.0.dylib) [0x82ee79]
                            17 wxWindowBase::TryParent(wxEvent&) + 88 (in libwx_macu-2.8.0.dylib) [0x969348]
                              17 wxEvtHandler::ProcessEvent(wxEvent&) + 121 (in libwx_macu-2.8.0.dylib) [0x82ee79]
                                17 wxWindowBase::TryParent(wxEvent&) + 88 (in libwx_macu-2.8.0.dylib) [0x969348]
                                  17 wxEvtHandler::ProcessEvent(wxEvent&) + 207 (in libwx_macu-2.8.0.dylib) [0x82eecf]
                                    17 wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) + 113 (in libwx_macu-2.8.0.dylib) [0x82e9b1]
                                      17 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) + 131 (in libwx_macu-2.8.0.dylib) [0x82d6a3]
                                        17 ClassBrowser::OnTreeItemCollapsing(wxTreeEvent&) + 41 (in libcodecompletion.so) [0x17f1c069]
                                          17 ClassBrowserBuilderThread::CollapseItem(wxTreeItemId) + 71 (in libcodecompletion.so) [0x17f21ba7]
                                            17 wxMutexInternal::Lock() + 17 (in libwx_macu-2.8.0.dylib) [0x824431]
                                              17 semaphore_wait_signal_trap + 10 (in libSystem.B.dylib) [0x919d8b42]
 Kernel stack:
    17 semaphore_wait_continue + 0 [0x22a88f]

  Thread d23f     
  User stack:
    17 thread_start + 34 (in libSystem.B.dylib) [0x91a060de]
      17 _pthread_start + 345 (in libSystem.B.dylib) [0x91a06259]
        17 PrivateMPEntryPoint + 68 (in CarbonCore) [0x960c954a]
          17 wxThreadInternal::MacThreadStart(void*) + 96 (in libwx_macu-2.8.0.dylib) [0x825130]
            17 cbThreadPool::cbWorkerThread::Entry() + 122 (in libcodeblocks.0.dylib) [0x12478a]
              17 wxSemaphore::Wait() + 36 (in libwx_macu-2.8.0.dylib) [0x824194]
                17 wxSemaphoreInternal::WaitTimeout(unsigned long) + 27 (in libwx_macu-2.8.0.dylib) [0x8240db]
                  17 semaphore_timedwait_trap + 10 (in libSystem.B.dylib) [0x919d8b4e]
  Kernel stack:
    17 semaphore_wait_continue + 0 [0x22a88f]
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Calexus on September 20, 2011, 08:24:43 pm
@oBFusCATed: As you recommended disabling Symbols browser works. CB loads projects without problem if it's disabled.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: ollydbg on September 21, 2011, 02:03:19 am
Loaden: why are you building the tree in a non-gui thread?
This behaviour was done several years ago. (before loaden became a developer).
The developer did that try to avoid the main UI hang when the symbol tree is building.
Can we have a better method? Building a symbol tree sometimes use a lot of CPU resources.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: oBFusCATed on September 21, 2011, 08:15:00 am
Don't know.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: fubo on September 21, 2011, 02:36:38 pm
fubo: is it possible for you to build C::B from svn sources and bisect the revision where it was broken?

Eventually done!!!! The bug was introduced from 7306 to 7307 SVN build, after changes to cbproject.cpp!!!
Title: Re: The 17 September 2011 build (7452) is out.
Post by: fubo on September 21, 2011, 03:14:29 pm
BTW, it was already reported here (http://forums.codeblocks.org/index.php/topic,15023.msg101286.html#msg101286)
Title: Re: The 17 September 2011 build (7452) is out.
Post by: fubo on September 21, 2011, 04:06:11 pm
I confirm that building HEAD using revision 7031 of cbproject.cpp solves the issue.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Jenna on September 21, 2011, 04:57:43 pm
I don't think, that it is really an issue.
At the moment the projects toplevel-path is the path where the projectfile is.

And from this point of view, it's absolutely correct as it is displayed, if I understand right.

One way to change this behaviour, would be to make the toplevel-path configurable, independant of the path, the projectfile is stored in.
The other way would be to right-click your project in the management-pane, uncheck  "Project tree -> Display folders as on disk" and check "Project tree -> Hide folder name".
The second way can lead to problems to chose files in the tree, if two or more have the same name.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: fubo on September 22, 2011, 09:56:06 am
I read that the cbproject.cpp was changed to address an issue in Linux. Could the code be conditionally built for Linux or Win32?
Meanwhile, I need to have head + cbproject.cpp ver 7031.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Jenna on September 22, 2011, 10:16:20 am
I read that the cbproject.cpp was changed to address an issue in Linux. Could the code be conditionally built for Linux or Win32?
Meanwhile, I need to have head + cbproject.cpp ver 7031.
The issue has lead to problems on linux or more exactly to problems wth cmake-generated projects on linux, but as far as I understand the behaviour was incorrect on all platforms.

At the moment the projects toplevel-path is the path where the projectfile is.

And from this point of view, it's absolutely correct as it is displayed, if I understand right.

Is that not correct for you ?
Does C::B use an incorrect path as top-level path ?
If yes, can you please attach a small sample project, where this happens ?

Or did the behaviour change and shows your project in a different (but maybe correct) way, than before ?

One way to change this behaviour, would be to make the toplevel-path configurable, independant of the path, the projectfile is stored in.
The other way would be to right-click your project in the management-pane, uncheck  "Project tree -> Display folders as on disk" and check "Project tree -> Hide folder name".
The second way can lead to problems to chose files in the tree, if two or more have the same name.

Would one of these possibilities be a solution for you ?


EDIT:

Okay, my error.

I looked into the sources again, and you are right of course.
We talk about the common toplevel path and not the basepath of the project, sorry for the noise.
I will look into it.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Jenna on September 22, 2011, 01:06:22 pm
I read that the cbproject.cpp was changed to address an issue in Linux. Could the code be conditionally built for Linux or Win32?
Meanwhile, I need to have head + cbproject.cpp ver 7031.
I will look into it.

Could you please test, whether commit 7460 fixes the issue for you ?
Title: Re: The 17 September 2011 build (7452) is out.
Post by: fubo on September 22, 2011, 02:14:07 pm
Quote
Could you please test, whether commit 7460 fixes the issue for you ?
That's it! Fixed!  :D :D
Title: Re: The 17 September 2011 build (7452) is out.
Post by: danselmi on September 22, 2011, 03:47:58 pm
I'm experiencing a crash on the debuggers nightly branch but I guess it's not related to the debugger so I'm posting it here as advised. Maybe someone can test it on this nightly.
1-Launch cb.
2-Plugins->manage plugins and choose spellchecker plugin.
3-Disable, enable, disable crashes cb.

OS: Win7 SP1

I will look into it in october (after my holidays 8)).
Title: Re: The 17 September 2011 build (7452) is out.
Post by: ollydbg on September 23, 2011, 07:59:57 am
My English isn't so good too :)
I'll try to explain.

1. Open the file
2. Select some function in the combobox:
(http://img844.imageshack.us/img844/8830/inc1.png)

3. The editor should display this function. I see this almost always:
(http://img59.imageshack.us/img59/6738/inc2.png)
Function name appears at the lowest editor line.

But I want to see the body of this function, I try to scroll it up and... As the combobox is still focused it selects another function.
A bit late reply. :D
I have the same behavior as you said. so what's your expect behavior.
After the step 2, do we need to switch the editor focus to editor control??
Or, we can always set the function name in the middle of the editor view. (By default, the jump to some line of an editor takes the smallest view change method, which means if the target line is in the current view, scintilla do not scroll the view. but we can force the target to show in the middle of the view)
Any comments?
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Kaïwann on September 23, 2011, 11:04:30 am
Hi,

Nice update.

However, I have a question : do you plan to add the prototype and the comment of function when hovering cursor over the box of code completion ?
Less important : highlight the choice under the cursor in the box ?

Thanks.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: ollydbg on September 23, 2011, 11:06:44 am
However, I have a question : do you plan to add the prototype and the comment of function when hovering cursor over the box of code completion ?
I have see such feature request several times, but currently it seems no one was brave enough to implement it.  :D
Title: Re: The 17 September 2011 build (7452) is out.
Post by: oBFusCATed on September 23, 2011, 11:08:56 am
A bit late reply. :D
I have the same behavior as you said. so what's your expect behavior.
After the step 2, do we need to switch the editor focus to editor control??
Or, we can always set the function name in the middle of the editor view. (By default, the jump to some line of an editor takes the smallest view change method, which means if the target line is in the current view, scintilla do not scroll the view. but we can force the target to show in the middle of the view)
Any comments?
I guess both of these two. :)

Title: Re: The 17 September 2011 build (7452) is out.
Post by: daniloz on September 23, 2011, 11:26:11 am
Agreed, focus the editor and function in the middle of the view would be cool!  8)
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Jenna on September 23, 2011, 01:23:17 pm
Agreed, focus the editor and function in the middle of the view would be cool!  8)

Why in the middle, and not at the top ?
If we want to see the body of the function, this would be the natural position.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Micool121 on September 23, 2011, 01:30:52 pm
yes, please  return back to the editor and function focus (like done before)

Any place of the function between middle and top will make me pleased !
Title: Re: The 17 September 2011 build (7452) is out.
Post by: daniloz on September 23, 2011, 02:13:26 pm
Agreed, focus the editor and function in the middle of the view would be cool!  8)

Why in the middle, and not at the top ?
If we want to see the body of the function, this would be the natural position.
Top is fine with me as well, but sometimes it's good to see some context, so middle make sense for me...
Title: Re: The 17 September 2011 build (7452) is out.
Post by: ollydbg on September 23, 2011, 02:46:54 pm
In cbEditor.h, see a function prototype:
Code
        /** Move the caret at the specified line.
          * @param line Line to move caret to.
          * @param centerOnScreen If true (default), tries to bring the specified line to the centre of the editor.*/
        void GotoLine(int line, bool centerOnScreen = true);

So, it should be quite easy to implement this feature.

About the other feature, put the focus on the editor window, probably it is easy too.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: ollydbg on September 23, 2011, 03:35:36 pm
A simple patch to implement both features:
Code
Index: E:/code/cb/cb_trunk/src/plugins/codecompletion/codecompletion.cpp
===================================================================
--- E:/code/cb/cb_trunk/src/plugins/codecompletion/codecompletion.cpp (revision 7460)
+++ E:/code/cb/cb_trunk/src/plugins/codecompletion/codecompletion.cpp (working copy)
@@ -416,7 +416,9 @@
     if (line > control->GetLineCount())
         return false;
 
-    control->GotoLine(line);
+    //control->GotoLine(line);
+    editor->GotoLine(line,true);
+    editor->SetFocus();
     const int startPos = control->GetCurrentPos();
     const int endPos = startPos + control->LineLength(line);
     if (endPos <= startPos)
Title: Re: The 17 September 2011 build (7452) is out.
Post by: daniloz on September 23, 2011, 04:12:06 pm
Just a hint, the Serach/Goto Function... does exactly this, i.e. sets the function name at the top of the editor...
But, I'm supposing that your patch does the same, right?
Title: Re: The 17 September 2011 build (7452) is out.
Post by: k1mgy on September 24, 2011, 06:37:00 pm
Installed just a few days ago.. it has been a while (about 6 months) since I've updated from nightly!

Windows 7
CB: 7452

Every so often, perhaps every 2 minutes, CB will freeze during an editing session.  At this same time I notice that CB does not appear in the open program list when I ALT-TAB.

I turned off both code completion and symbols browser, as these in the past have caused delays.  However, the problem continues.

Any way someone can suggest to diagnose this?
Title: Re: The 17 September 2011 build (7452) is out.
Post by: stahta01 on September 24, 2011, 06:56:30 pm
@k1mgy:

Verify the problem still exists after turning off anti-virus software.

If it goes away, look for how to configure your AV right.

Tim S.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Jenna on September 24, 2011, 07:01:32 pm
@k1mgy:

Verify the problem still exists after turning off anti-virus software.

If it goes away, look for how to configure your AV right.

Tim S.
And make sure, that no libs from an older nightly remain in C::B's (sub-)folder(s).
Title: Re: The 17 September 2011 build (7452) is out.
Post by: k1mgy on September 24, 2011, 08:46:44 pm
@jens @tim
Thank you very much!

1. My anti-virus, Norton Internet Security 2012, had crashed (and I didn't know it).
2. Ran norton removal tool
3. Reinstalled anti virus
4. Applied update.
various reboots..

Now CB operates normally.
 
Perhaps it was Norton's check on program legitimacy that had failed and caused the delays?
Title: Re: The 17 September 2011 build (7452) is out.
Post by: imianz on October 05, 2011, 11:14:23 am
(I hope, finally, this I is the right section to post...)

Hi, first all, thanks for your work!

I try to explain you my problem (I signaled it in the forum but without replies).

I need to set compiler path as relative (to "portable/stand-alone" purpose).

Settings -> Compiler and debugger -> Global compiler -> GNU GCC Compiler -> Toolchain executables:
%MYCBPATH%\MinGW
or
$(CODEBLOCKS)\MinGW

In both cases (using CB embedded enviromental variable or my own) compiler works fine but not the editor. Autocompletion features does not works anymore and I'm not able anymore to open #include files from the MinGW/include directory. Only #include files within project directory.

For eg. (using right mouse button over an #include statement) I can open the file
#include "version.h" 
but not
#include <windows.h>

I have not found this problem using the official 10.05 release or the 8.02 svn6088+.
Thanks in advance.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: ollydbg on October 05, 2011, 11:25:45 am
@imianz
I have just replied you, see: Re: Codeblocks portable (http://forums.codeblocks.org/index.php/topic,13440.msg102921/topicseen.html#msg102921)
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Alpha on October 08, 2011, 12:58:46 am
I do not know if it first occurred in this version, but should not the linker option -enable-auto-import in the Windows NassiShneiderman plugin be -Wl,-enable-auto-import instead?

Code
Index: src/plugins/contrib/NassiShneiderman/NassiShneiderman.cbp
===================================================================
--- src/plugins/contrib/NassiShneiderman/NassiShneiderman.cbp (revision 7479)
+++ src/plugins/contrib/NassiShneiderman/NassiShneiderman.cbp (working copy)
@@ -37,7 +37,7 @@
  <Add directory="$(#boost)" />
  </Compiler>
  <Linker>
- <Add option="-enable-auto-import" />
+ <Add option="-Wl,-enable-auto-import" />
  <Add library="codeblocks" />
  <Add library="wxmsw$(WX_VERSION)$(WX_SUFFIX)" />
  <Add directory="..\..\..\devel" />

Title: Re: The 17 September 2011 build (7452) is out.
Post by: ham on October 13, 2011, 06:15:51 pm
hi,

i have 2 big problems with the editor, i run CB svn7470 on linuxmint 11 x64 gnome desktop

1. Codeblocks often freeze, with no rescue when opening a project much often (2 of 3 opens)

i only activated plugins:

Cccc
Code Completion
Compiler
Foreign Projects Importer
Scripted Wizard



2. the screen update of the main-code-editor-window is somehow broken.

it displays grey lines when scrolling down,

when scrolling up the window updates properly

thx
Title: Re: The 17 September 2011 build (7452) is out.
Post by: oBFusCATed on October 13, 2011, 07:39:23 pm
1. update to a newer revision or disable CC plugin
2. update your ubuntu
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Jenna on October 13, 2011, 08:47:29 pm
2. update your ubuntu

He uses mint, which is based on ubuntu (or directly on debian ?, not sure at the moment), but nevertheless updating might help, see this post: http://forums.codeblocks.org/index.php/topic,15342.msg102985.html#msg102985 (http://forums.codeblocks.org/index.php/topic,15342.msg102985.html#msg102985)

By the way: please search the forum for a solution, before asking questions, that might have been answered before.
Not searching violates our forum rules.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: coppolo on October 14, 2011, 12:09:31 pm
I hope this is the right place for it... sorry if it is not.

Maybe it's a known issue (I could not find something like that in previous posts), but "Find declaration" and "Find implementation" does not work correctly with this code (you can try it in a new project):

Code
int foo()
{
  return 0;
}

void bar(void)
{
  foo();        // declaration and implementation are found correctly
  switch(0)
  {
    case 0:
      return foo();  // IT DOES NOT WORK while searching foo() declaration or implementation
  }
}

OS: Win Vista
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Alpha on October 14, 2011, 11:02:59 pm
Code
[...]
void bar(void)
{
  [...]
      return foo();  // IT DOES NOT WORK while searching foo() declaration or implementation
}
A void function cannot return anything (this may or may not be the reason for the problem though - I have yet to test).
Title: Re: The 17 September 2011 build (7452) is out.
Post by: coppolo on October 17, 2011, 10:13:44 am
The problem occurs regardless of the function return type (I made a mistake by writing void instead of int, but the result does not change).
Title: Re: The 17 September 2011 build (7452) is out.
Post by: eckard_klotz on October 18, 2011, 08:15:50 am
Hello Everybody.

I can confirm the effect described by coppolo. I have implemented the functions foo() and bar() in a c-file and decleard them in an h-file.

Best regards,
                  Eckard.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: stefanos_ on October 20, 2011, 11:35:45 am
People, something partially on-topic.

Will Code::Blocks going to use the new Subversion 1.7.0? Current projects need upgrade and that would break backward compatibility.

I haven't tried anything with Code::Blocks yet, just finished the upgrade procedure and I will try to test it myself.

Has anyone tried it already?
Title: Re: The 17 September 2011 build (7452) is out.
Post by: oBFusCATed on October 20, 2011, 11:45:13 am
Will Code::Blocks going to use the new Subversion 1.7.0? Current projects need upgrade and that would break backward compatibility.
What backwards compatibility?
Svn 1.7.x changes the disk format for the working copy, but this has nothing to do with the server hosting the repo.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: stefanos_ on October 20, 2011, 04:41:47 pm
when I installed the latest tortoiseSVN I couldn't see any red exclamation mark for my Code::Blocks local repository, and I right-clicked on it and told me to upgrade it to the new SVN subversion but doing so would break the backwards compatibility.

Can you provide your feedback if you are under Windows oBFusCATed?
Title: Re: The 17 September 2011 build (7452) is out.
Post by: oBFusCATed on October 20, 2011, 05:24:12 pm
Yes, you won't be able to use svn < 1.7, but so what, if you have to use svn 1.6.xx just make a new check out?
But what is the connection with the C::B project (us)?

p.s. Mostly linux, sometimes I run windows to play games or test new C::B features. At work I've migrated to linux, too.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: ollydbg on October 21, 2011, 07:58:23 am
I hope this is the right place for it... sorry if it is not.

Maybe it's a known issue (I could not find something like that in previous posts), but "Find declaration" and "Find implementation" does not work correctly with this code (you can try it in a new project):

Code
int foo()
{
  return 0;
}

void bar(void)
{
  foo();        // declaration and implementation are found correctly
  switch(0)
  {
    case 0:
      return foo();  // IT DOES NOT WORK while searching foo() declaration or implementation
  }
}

OS: Win Vista

I can confirm this, see the image below.
It looks like a cc's parser error on parsing the switch case statement.
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2011-10-21134930.png)
I think it is not hard to fix this bug  :D
Title: Re: The 17 September 2011 build (7452) is out.
Post by: ollydbg on October 21, 2011, 08:27:24 am
This patch should fix the parser problem:
Code
Index: F:/cb/codeblocks_trunk/src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- F:/cb/codeblocks_trunk/src/plugins/codecompletion/parser/parserthread.cpp (revision 7496)
+++ F:/cb/codeblocks_trunk/src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -131,6 +131,7 @@
     const wxString kw_else         (_T("else"));
     const wxString kw_enum         (_T("enum"));
     const wxString kw_elif         (_T("elif"));
+    const wxString kw_case         (_T("case"));
     // length: 5
     const wxString kw__CPP_        (_T("\"C++\""));
     const wxString kw___asm        (_T("__asm"));
@@ -688,6 +689,11 @@
                 else
                     SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
             }
+            else if (token == ParserConsts::kw_case)
+            {
+                m_Str.Clear();
+                SkipToOneOfChars(ParserConsts::colon, true);
+            }
             else
                 switchHandled = false;
             break;

I just put it in my pending patches lists (http://wiki.codeblocks.org/index.php?title=User:Ollydbg).
Title: Re: The 17 September 2011 build (7452) is out.
Post by: stefanos_ on October 21, 2011, 09:12:27 am
Yes, you won't be able to use svn < 1.7, but so what, if you have to use svn 1.6.xx just make a new check out?
But what is the connection with the C::B project (us)?

p.s. Mostly linux, sometimes I run windows to play games or test new C::B features. At work I've migrated to linux, too.

Yeah you are right. I feel silly already :D I thought for some reason svn 1.7.0 would break current local repository but is not the case. Currently installing the latest revision.

Btw, what about all these "variable not used" warnings? If those variables are not used, should they be declared? And if yes, why not get initialized with a default value?
Title: Re: The 17 September 2011 build (7452) is out.
Post by: ham on October 24, 2011, 12:43:32 am
thx

updating linux worked for all problems.

except some bug at opening projects CB is now a complete working, very nice IDE for me :-)

h.a.n.d.
Title: Re: The 17 September 2011 build (7452) is out.
Post by: Micool121 on October 26, 2011, 06:06:12 pm
Any target for a new nightly build ?

The only thing I miss is the patch for this awfull editor function focus we reported ;)

thx !
Title: Re: The 17 September 2011 build (7452) is out.
Post by: oBFusCATed on October 26, 2011, 06:33:25 pm
Killberbot can answer the question, but maybe it is time for another monthly build :)
Title: Re: The 17 September 2011 build (7452) is out.
Post by: killerbot on October 27, 2011, 12:20:28 am
I already prepared one last weekend, but in the end it didn't make it out of the door. This weekend it sure will :-)