User forums > Nightly builds
The 16 November 2013 build (9455) is out.
ToApolytoXaos:
With the latest build (svn9492) it works fine from both gdb and "Run". Previous problematic version was crashing from gdb as well; that's where I got the report and posted it here the first place.
BlueHazzard:
--- Quote from: ToApolytoXaos on December 19, 2013, 05:50:36 pm ---The steps are:
* Ctrl-F2 to open "run" window. Type "codeblocks" in it.
* Run it and as soon as you see the splash window, alt-tab to switch to another window so "Focus Window" event switch to that.
* While it loads and you are on the window I have mentioned before, just before the finishing of GUI drawing, alt-tab to switch window again and voila; you got it crashed.
--- End quote ---
i have the same issue. Latest svn version.
If i start c::b and alt tab to a other window, c::b will load till the end, but as soon i switch back, i get a crash report:
--- Code: ---<frame level="0"/><frame level="1" function="wxAppBase::SendIdleEvents(wxWindow*, wxIdleEvent&)" offset="0000007e"/><frame level="2" function="wxAppBase::ProcessIdle()" offset="00000074"/><frame level="3"/><frame level="4" function="g_main_context_dispatch" offset="00000135"/><frame level="5"/><frame level="6" function="g_main_loop_run" offset="0000006a"/><frame level="7" function="gtk_main" offset="000000a7"/><frame level="8" function="wxEventLoop::Run()" offset="00000048"/><frame level="9" function="wxAppBase::MainLoop()" offset="0000004c"/>
--- End code ---
from gdb:
--- Code: ---#0 0x00007ffff548ab18 in main_arena () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff6f782b4 in wxAppBase::SendIdleEvents(wxWindow*, wxIdleEvent&) ()
from /usr/local/lib/libwx_gtk2u-2.8.so.0
#2 0x00007ffff6f78764 in wxAppBase::ProcessIdle() ()
from /usr/local/lib/libwx_gtk2u-2.8.so.0
#3 0x00007ffff6efc92e in wxapp_idle_callback ()
from /usr/local/lib/libwx_gtk2u-2.8.so.0
#4 0x00007ffff30d8f05 in g_main_context_dispatch ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007ffff30d9248 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007ffff30d96ba in g_main_loop_run ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007ffff78d4fe7 in gtk_main ()
from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#8 0x00007ffff6f10278 in wxEventLoop::Run() ()
from /usr/local/lib/libwx_gtk2u-2.8.so.0
#9 0x00007ffff6f7850c in wxAppBase::MainLoop() ()
from /usr/local/lib/libwx_gtk2u-2.8.so.0
#10 0x000000000046459e in CodeBlocksApp::OnRun (this=0x84aee0)
at /codeblocks_sf/src/src/app.cpp:809
#11 0x00007ffff6e90045 in wxEntry(int&, wchar_t**) ()
from /usr/local/lib/libwx_gtk2u-2.8.so.0
#12 0x0000000000461b19 in main (argc=1, argv=0x7fffffffe448)
at /codeblocks_sf/src/src/app.cpp:276
--- End code ---
greetings
oBFusCATed:
BlueHazzard: Please specify your OS/distro and WindowManager or DesktopEnvironment.
BlueHazzard:
Linux Mint 15
cinnamon 1.8.8 64
raynebc:
I've been experiencing a problem for a while where when I try to open a particular source file in my project, it opens in CodeBlocks as if it is empty. Right clicking on it in the management window and selecting properties indicates it's recognized as having 0 lines of source code but being about 39KB in size (which is an accurate size for the file in question). The paths displayed for the file look fine and the fact that the file size is given means the IDE is seeing it. "Project>Reparse current project" doesn't resolve the issue and I can't find that any other files in my project are affected.
I tried reproducing this problem by opening the exact same CodeBlocks project file in several nightly builds I've used in the past year or so. In the 11-10-12 nightly (12.11 RC1), the source file opened properly. In the 11-23-12 nightly (12.11 RC2) it did not open it correctly. In the 12.11 stable release, it opened correctly. In the 4-12-13, 8-6-13 and 11-16-13 nightly builds, the source file once again does not open correctly.
I don't see how it could be a problem outside of CodeBlocks itself, there are no permissions or file encoding issues that I can discern, and the fact that some of the builds open it correctly should rule stuff like that out anyways and verify that the project file itself is not corrupted in some way. Anytime I want to view/edit the file I end up having to open it in another program like a text editor, and EditPad again confirms that the file is in the same encoding as other source files in the project. The project in question is here if anybody wanted to try to reproduce it:
http://code.google.com/p/editor-on-fire/source/checkout
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version