The 19 June 2015 build (10341) is out.

[stahta01]

D /trunk/src/wxsmith/GenericSingleChoiceList.wxs

Code

r10270 | jenslody | 2015-05-15 06:57:08 -0400 (Fri, 15 May 2015) | 1 line
Changed paths:
   M /trunk/src/plugins/scriptedwizard/buildtargetpanel.cpp
   M /trunk/src/plugins/scriptedwizard/buildtargetpanel.h
   M /trunk/src/plugins/scriptedwizard/compilerpanel.cpp
   M /trunk/src/plugins/scriptedwizard/compilerpanel.h
   M /trunk/src/plugins/scriptedwizard/filepathpanel.cpp
   M /trunk/src/plugins/scriptedwizard/filepathpanel.h
   M /trunk/src/plugins/scriptedwizard/genericselectpath.cpp
   M /trunk/src/plugins/scriptedwizard/genericselectpath.h
   M /trunk/src/plugins/scriptedwizard/genericsinglechoicelist.cpp
   M /trunk/src/plugins/scriptedwizard/genericsinglechoicelist.h
   M /trunk/src/plugins/scriptedwizard/infopanel.cpp
   M /trunk/src/plugins/scriptedwizard/infopanel.h
   M /trunk/src/plugins/scriptedwizard/projectpathpanel.cpp
   M /trunk/src/plugins/scriptedwizard/projectpathpanel.h
   M /trunk/src/plugins/scriptedwizard/resources/avr/wizard.xrc
   M /trunk/src/plugins/scriptedwizard/resources/lf/wizard.xrc
   M /trunk/src/plugins/scriptedwizard/resources/matlab_csf/wizard.xrc
   M /trunk/src/plugins/scriptedwizard/resources/mcs51/wizard.xrc
   M /trunk/src/plugins/scriptedwizard/resources/plugins/wizard.xrc
   M /trunk/src/plugins/scriptedwizard/resources/tricore/wizard.xrc
   M /trunk/src/plugins/scriptedwizard/resources/wxwidgets/wizard.xrc
   M /trunk/src/wxsmith/BuildTargetPanel.wxs
   M /trunk/src/wxsmith/CompilerPanel.wxs
   M /trunk/src/wxsmith/FilePathPanel.wxs
   M /trunk/src/wxsmith/GenericSelectPath.wxs
   D /trunk/src/wxsmith/GenericSingleChoiceList.wxs
   M /trunk/src/wxsmith/InfoPanel.wxs
   M /trunk/src/wxsmith/ProjectPathPanel.wxs

My guess it was deleted in error and needs restored and likely edited.

Edit2: How I found out when it was deleted; learned something new about SVN

Code

stahta01@TIMWIN7-32 /c/SourceCode/OpenSourceCode/Apps/IDE/Codeblocks/codeblocks-svn/src/wxsmith
$ svn log -v > log.txt

Tim S.

OK, from where to start...

I have attempted to search "m_ptr" term with ThreadSearch toolbar and got a rather awkward message about a /home/stefanos/SVN_REPOSITORIES/CodeBlocks/src/wxsmith/GenericSingleChoiceList.wxs does not exist whatever that behavior means.. yeah I know it's a wxSmith file.

No, it's not missing from my fork; it does not exist on SVN repository either: http://svn.code.sf.net/p/codeblocks/code/trunk/src/wxsmith/

[ToApolytoXaos]

Could it possibly be the reason with all these assert()s? That would be mindblowing 

Update: When do you think you can push the changes to repository so I can pull?

[stahta01]

Could it possibly be the reason with all these assert()s? That would be mindblowing 

Update: When do you think you can push the changes to repository so I can pull?

wx30 is the likely reason for the asserts.

I an NOT a CB Dev; just a long term poster to this site.

Tim S.

[Jenna]

I readded the wxs-file to trunk.
A missing wxs-file can not cause any issues, because it's only used to configure/generate the cpp/h-files it belongs to.
If it is part of a project it might lead to an error if you search in project-files with (e.g.) threadsearch.

The cashing at the end of wx3 is know and it's a hard to trackdown bug.
We already fixed several event-related issues a long time ago.
 On comandline I get a xxx threads not closed message when closing C::B all the time.

When running C::B through C::B in the debugger I get a (more or less random) crash deep in some system and/or wx-files when closing C::B.

It's the next I try to work on (if no other more urgent stuff will come).

[oBFusCATed]

The cashing at the end of wx3 is know and it's a hard to trackdown bug.
We already fixed several event-related issues a long time ago.

So you're able to reproduce it? I'm not. Interesting.

On comandline I get a xxx threads not closed message when closing C::B all the time.

These are caused by the file manager object. And the threads are not stopped deliberately, I don't know the reason and svn blame doesn't give much hints. I've tried to stop these threads, but I was getting crashes, so I've to investigate further.

[Jenna]

So you can try my repo with Code::Blocks nightlies for debian, build against wxWidgets 3.02 from the official repo.

Is everything alright jens? I can't fetch updates for some reason...

Code

W: Failed to fetch https://apt.jenslody.de/testing/dists/stretch/Release  Unable to find expected entry 'main/source/Sources' in Release file (Wrong sources.list entry or malformed file)

E: Some index files failed to download. They have been ignored, or old ones used instead.

Sources are not (yet) available.
[...]
For the moment you have to comment out the deb-src line for my repo.

Should work again.

[ToApolytoXaos]

Yep, I have tested it on my VirtualBox and works now.

By the way, I wanted to ask: what's the first line Code::Blocks is using to start? I haven't found any main() code inside any source file.

Where should I look?

[BlueHazzard]

it is nested in a wxApp Class and i think the main is behind this macro in app.c

Code

IMPLEMENT_APP(CodeBlocksApp) // TODO: This gives a "redundant declaration" warning, though I think it's false. Dig through macro and check.

[Jenna]

I possibly found the cause for the crash at shutdown (not related to the unfinished threads):
wx3 provides wxTreeListCtrl and wxContribItems does it too.
For testing purposes I removed it completely in autofoo-stuff and the wx30-project-files (only tested on linux).
It should be added to wxSmith, but the wxs*-files for it need a complete overhaul and have to be moved from wxSmithContribItems to wxSmith itself (for wx30).

So as written for testing purposes I removed it completetely.
Please test the attached patch and give feedback, if possible.

[eckard_klotz]

Hello Everybody.

Since this nightly ("CB_20150619_rev10341_win32") I have problems to add files to a project by the projects-browser:

• When I try to add files by the projects-browser the wait symbol (turning cycle) will be displayed  before the associated File-dialogue opens. CodeBlocks is doing nothing any more and I have to quit it with the task-manager.
  
• When I try to add files by the files-browser it works. When I try to add files recursively by the projects-browser the associated folder dialogue opens.
  
• I closed my workspace and tried it out with a complete new empty-project with the same result.
  
• The effect occurs under  Win 8.1. with this nightly where I use the content of all provided 7z files.
  
• As far as I remember I tried it out on Win 7 also and there it worked.  I try to reproduce it tomorrow if i have a Win 7 computer available again if you wish.
  
• I have tested it out with the nightly before  ("CB_20150604_rev10320_win32") and there it works.
  
• Please ask me for some more details if my description is not helpful ...
  

After some trials I found out the real reason. When I waited longer I've got a message from my virus-scanner that codeblocks.exe seems to act in a suspicious way and he asked me to remove it. Since I already know a similar problem with CbLauncher.exe I checked it directly with my virus-scanner and after he approved that he found no problem inside codeblocks.exe, I put it on his white-list. After that I was able to add files to a project by the projects-browser again.

We had such an discussion last year ()http://forums.codeblocks.org/index.php/topic,19596.msg134069.html#msg134069 and I since I know now how to deal with this I don't want to start it again. How ever it may be helpful for others to add in http://forums.codeblocks.org/index.php/topic,3232.0.html a small workaround.

Best regards,
                      Eckard Klotz.


 

Best regards,
                      Eckard Klotz

[grf]

Hello,

at least since 10341 and also with the latest 10356 I get the following assertion when I mark a variable and try to use following item of the context menu (right mouse click): Find occurences of: 'name':

Code

ASSERT INFO:
../src/generic/listctrl.cpp(4091): assert "index >= 0 && (size_t)index < GetItemCount()" failed in EnsureVisible(): invalid index in EnsureVisible

BACKTRACE:
[1] wxGenericListCtrl::EnsureVisible(long)
[2] ThreadSearchLoggerList::OnThreadSearchEvent(ThreadSearchEvent const&)
[3] ThreadSearchView::OnTmrListCtrlUpdate(wxTimerEvent&)
[4] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[5] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[6] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[7] wxEvtHandler::TryHereOnly(wxEvent&)
[8] wxEvtHandler::ProcessEventLocally(wxEvent&)
[9] wxEvtHandler::ProcessEvent(wxEvent&)
[10] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[11] wxTimerImpl::SendEvent()
[12] g_main_context_dispatch
[13] g_main_loop_run
[14] gtk_main
[15] wxGUIEventLoop::DoRun()
[16] wxEventLoopBase::Run()
[17] wxAppConsoleBase::MainLoop()
[18] CodeBlocksApp::OnRun() /home/msk/test/codeblocks/trunk/src/src/app.cpp:850
[19] wxEntry(int&, wchar_t**)
[20] main /home/msk/test/codeblocks/trunk/src/src/app.cpp:317
[21] __libc_start_main
[22] _start /home/abuild/rpmbuild/BUILD/glibc-2.19/csu/../sysdeps/x86_64/start.S:125

I used the latest trunk with wxWidgets 3.0.2 (compiled by my own) on my OpenSuse 13.2.

[Hans Henrik]

I haven't used codeblocks (nor c++) for a long time, but recently installed the nightly (via jens lody) on a debian 8, and i am getting crashes all over the place..

the dev-cpp project importer is bugged and will make paths like "..\..\foo.cpp" even on linux where ..\ is invalid and should be ../../ ~

every time i try to delete a Build Target, i get an (seemingly) unlimited loop of assertion errors like this:

and it always seem to segfault after 2-10 minutes of use.. 

Code

ASSERT INFO:
./projectfile.h(234): assert "iIndex != (-1)" failed in Remove(): removing inexistent element in wxArray::Remove

BACKTRACE:
[1] ProjectFile::RemoveBuildTarget(wxString const&)
[2] cbProject::RemoveBuildTarget(int)
[3] std::vector<ProjectFile*, std::allocator<ProjectFile*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<ProjectFile**, std::vector<ProjectFile*, std::allocator<ProjectFile*> > >, ProjectFile* const&)
[4] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[5] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[6] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[7] wxEvtHandler::TryHereOnly(wxEvent&)
[8] wxEvtHandler::ProcessEventLocally(wxEvent&)
[9] wxEvtHandler::ProcessEvent(wxEvent&)
[10] wxWindowBase::TryAfter(wxEvent&)
[11] wxWindowBase::TryAfter(wxEvent&)
[12] wxWindowBase::TryAfter(wxEvent&)
[13] wxWindowBase::TryAfter(wxEvent&)
[14] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[15] g_signal_emit_valist
[16] g_signal_emit
[17] g_signal_emit_valist
[18] g_signal_emit
[19] g_closure_invoke
[20] g_signal_emit_valist
[21] g_signal_emit
[22] gtk_propagate_event
[23] gtk_main_do_event
[24] g_main_context_dispatch
[25] g_main_loop_run
[26] gtk_main
[27] wxGUIEventLoop::DoRun()
[28] wxEventLoopBase::Run()
[29] wxDialog::ShowModal()
[30] wxDC::~wxDC()
[31] wxDC::~wxDC()
[32] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[33] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[34] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[35] wxEvtHandler::TryHereOnly(wxEvent&)
[36] wxEvtHandler::DoTryChain(wxEvent&)
[37] wxEvtHandler::ProcessEvent(wxEvent&)
[38] wxWindowBase::TryAfter(wxEvent&)
[39] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[40] wxMenuBase::SendEvent(int, int)
[41] g_closure_invoke
[42] g_signal_emit_valist
[43] g_signal_emit
[44] gtk_widget_activate
[45] gtk_menu_shell_activate_item
[46] g_closure_invoke
[47] g_signal_emit_valist
[48] g_signal_emit
[49] gtk_propagate_event
[50] gtk_main_do_event
[51] g_main_context_dispatch
[52] g_main_loop_run
[53] gtk_main
[54] wxGUIEventLoop::DoRun()
[55] wxEventLoopBase::Run()
[56] wxAppConsoleBase::MainLoop()
[57] wxEntry(int&, wchar_t**)
[58] __libc_start_main

[oBFusCATed]

To ignore the message just untick the 'show this dialog the next time' and click continue.

[ollydbg]

When using this nightly build release, I notice that the new project wizard's dialog can't be resized(thus it is a bit small), see image below:


The other dialogs don't have this issue, see the about dialog, I can resize it by drag on the corner, see image below:


Can you confirm this?

[BlueHazzard]

i can confirm this...
i noticed it a few revisions before but thought it is a feature for small screens