I hope this helps. Please let me know if you need more information.Can you export your colour scheme using cb_share_config an provide it here, please?
I hope this helps. Please let me know if you need more information.Can you export your colour scheme using cb_share_config an provide it here, please?
To be honest: I have no glue what should have cause this. IMHO we were not doing any changes in that field.
<Style name="Comment (normal)"
index="1,23"
fg="160,160,160"/>
<Style name="Comment (normal)"
index="1"
fg="160,160,160"/>
This change in lexer_cpp.xml:This is actually correct - style 23 refers to "wxSTC_C_PREPROCESSORCOMMENT", which shall be coloured like a normal comment therefore.Code<Style name="Comment (normal)"
index="1,23"
fg="160,160,160"/>
Another thing that does not seem right, is when you have two wxSmith files and you want to move elements from one to the other; it does not support DnD, very annoying and counter productive![/li][/list]wxSmith even does not support multiply selected feature. E.g. drag the mouse to select some items.
That was an added feature (with the idea that code generated by wxSmith should normally not be edited, so coloring it can be a reminder). It can be turned off through Settings->Editor...->C/C++ Editor options (tab)->Highlight wxSmith sections differently.
- The entire generated code became dark blue italic and it's very confusing to work with it. Is it the same issue people have with syntax highlighting maybe?
wxSmith even does not support multiply selected feature. E.g. drag the mouse to select some items.
The code base of wxSmith is quite complex for me :). It was not maintained for a long time.
#ifdef __WXMSW__
#ifndef PLUGIN_EXPORT
#ifdef EXPORT_LIB
#define PLUGIN_EXPORT __declspec (dllexport)
#else // !EXPORT_LIB
#ifdef BUILDING_PLUGIN
#define PLUGIN_EXPORT __declspec (dllexport)
#else // !BUILDING_PLUGIN
#define PLUGIN_EXPORT __declspec (dllimport)
#endif // BUILDING_PLUGIN
#endif // EXPORT_LIB
#endif // PLUGIN_EXPORT
#else
#define PLUGIN_EXPORT
#endif
Guys, can someone tell me if line 29 from include\cbplugin.h is correct? Should not be named PLUGIN_IMPORT?
As it is right now makes no sense to me I'm afraid...Code#ifdef __WXMSW__
#ifndef PLUGIN_EXPORT
#ifdef EXPORT_LIB
#define PLUGIN_EXPORT __declspec (dllexport)
#else // !EXPORT_LIB
#ifdef BUILDING_PLUGIN
#define PLUGIN_EXPORT __declspec (dllexport)
#else // !BUILDING_PLUGIN
#define PLUGIN_EXPORT __declspec (dllimport)
#endif // BUILDING_PLUGIN
#endif // EXPORT_LIB
#endif // PLUGIN_EXPORT
#else
#define PLUGIN_EXPORT
#endif
Also, this link clear things up a bit about what is dllimport and what is dllexport. http://msdn.microsoft.com/en-us/library/81h27t8c(v=vs.80).aspx (http://msdn.microsoft.com/en-us/library/81h27t8c(v=vs.80).aspx)
Guys, can someone tell me if line 29 from include\cbplugin.h is correct? Should not be named PLUGIN_IMPORT?It is correct. You control basically if the plugin (or declared methods) export their signature. Notice the difference in both lines:
This change in lexer_cpp.xml:I think that this is probably the cause of the issue that some users are experiencing (the new wxSmith generated code highlighting is the only other lexer related change, and it can be disabled). My guess is that even though the new index is correct (for the most recent Scintilla update), Code::Blocks cannot correctly load previously saved user customized color schemes (likely because of the added index).Codeis causing problems. When i changed it back to the previous form:<Style name="Comment (normal)"
index="1,23"
fg="160,160,160"/>Codethe highlighter works correctly. The added ",23" part borks the highlighter and causes it to select colors from wrong entries.<Style name="Comment (normal)"
index="1"
fg="160,160,160"/>
Wow...I have compiled the latest svn revision and I just noticed this new application named Addr2LineUI.exe. I have tried to use it but it depends on addr2line.exe. Should not be available as part of Code::Blocks since we are offering it's UI or should I install it separately?Addr2line.exe is mainly distributed in your MinGW, it is mostly located under MinGW/bin folder.
Specs:
OS: Windows XP SP3
Compiler: TDM's GCC 4.5.2 (GCC 4.6.1)
wxWidgets: 2.8.10 / 2.9.4
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XGrabServer'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XFlush'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XUngrabServer'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XSync'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XChangeProperty'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XFree'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XInternAtom'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XGetWindowProperty'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XGetSelectionOwner'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XSendEvent'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XSelectInput'
/usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-2.8.so: error: undefined reference to 'XScreenNumberOfScreen'
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]Warning:
[debug]Cannot insert breakpoint -60.
[debug]Error accessing memory address 0x7816cd30: Input/output error.
[debug]>>>>>>cb_gdb:
Error accessing memory address 0x7816cd30: Input/output error.
I just got this warning from my antivirus program:
Edit: btw, does your linux builds of C::B work on non-debian releases? ( im still new to linux )No, but he provides redhat/centos/fedora releases, too.
I don't see the missing-icon problem nor the syntax highlighting problems reported by others but i did do a completely from scratch install.I had the missing icons even after a from-scratch install. Then I compared the new share folder with the old one and found the new one was missing share/CodeBlocks/images/codesnippets, share/CodeBlocks/images/DoxyBlocks, share/CodeBlocks/images/ThreadSearch, and share/CodeBlocks/images/wxsmith. So I copied these folders from the previous version and now the icons appear correctly for Thread Search. (I don't use the other things, so I'm not sure about those being fixed or even broken to begin with.)
Code statistics seem to freeze C::B on whole workspace when it is summoned while CC is still parsing (at least, on Debian).
I will try to dig into it deeper this evening.I'm afraid this won't be too easy. I am experiencing hangs very seldom, too in combination with files being opeend on project load. It might be it was a "hick-up" of CC causing to access std::maps in a wrong way, but I am not sure. I've already prepared a patch for CC that should "robustify" access to the internal maps accordingly - since that time it seems gone for me... but as I said: It is very rare and not reproducible.
I will try to dig into it deeper this evening.I'm afraid this won't be too easy.
I found odd debugging buggs with at least two last nightly builds of C::B. When I try perform "Next line", "Step Into" or "Step Out", I got something like that:Hi, you need to tell us:CodeAfter this message C::B typically lost connection with gdb.[debug]>>>>>>cb_gdb:
[debug]> next
[debug]Warning:
[debug]Cannot insert breakpoint -60.
[debug]Error accessing memory address 0x7816cd30: Input/output error.
[debug]>>>>>>cb_gdb:
Error accessing memory address 0x7816cd30: Input/output error.
It appears typically if line contains function call.
It not appears if I jumps between breakpoints or make "Run to cursor".
I looked at the attachment file, and I see that the bt looks like:
I run C::B in a debugger-session and if it hangs, I can pause the program.
I have several therads (between 22 and 35).
All threads are in wait-state (pthread_cond_wait), except for thread one (the main thread), which hangs in wxExecute, called from ExpandBackticks.
The process called by wxExecute is already finished, but stays in memory as zombie-process.
I attach a file, that contains a thread-list and two backtraces, that show that the hang always happens in the same function.
It happens in the timer event of cc's parser and it waits for the "answer" of wxExecute in ExpandBackticks.
All hangs that I was able to reproduce happened at the same function, but I did it only 6 or 7 times, so it might not be the only place.
crash
....
#5 0x00007ffff79aef41 in CompilerCommandGenerator::ExpandBackticks (this=0x2b84770, str=...) at /home/jens/codeblocks-build/codeblocks.git/src/sdk/compilercommandgenerator.cpp:1070
.....
#41 0x000000344643cefb in wxDialog::ShowModal() () from /lib64/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#42 0x00007ffff7af068c in wxScrollingDialog::ShowModal (this=0x2c0fa20) at /home/jens/codeblocks-build/codeblocks.git/src/sdk/scrollingdialog.cpp:450
No locals.
#43 0x00007fffde952dd3 in CodeStatExecDlg::Execute (this=0x2c0fa20, languages=0x7fffffffc480, numLanguages=7) at /home/jens/codeblocks-build/codeblocks.git/src/plugins/contrib/codestat/codestatexec.cpp:114
.......
And it seems to intersect only with the timer-driven function of cc and only when wxExecute is run from ExpandBackticks.Well this "timer-foo" is something I had in mind to re-factor. I believe the best way would be to have a state machine and all the tasks are encapsulated in cbThreadedTasks and then run serialised or in parallel if possible. The state-machine then executes the next steps when i get signals from tasks being ready. This would avoid a lot such trouble and timing problems. IN adition we are missing an interface to query project / target options without the need to switch a project / target. This is bad design in the SDK. Unfortunately for now, I don't have much time to work on that.
I agree, "timer-foo" design has some flaws. Also the lockers in CC is another kind of flaws. :)And it seems to intersect only with the timer-driven function of cc and only when wxExecute is run from ExpandBackticks.Well this "timer-foo" is something I had in mind to re-factor.
IN adition we are missing an interface to query project / target options without the need to switch a project / target. This is bad design in the SDK.This is used to handle the problem as jens said:
We have another bug related to this (missing search-dirs while parsing of a workspace by CC).
Hi, you need to tell us:OK, I`ll try to create sample project. It not appears on simple codes.
1, OS
2, C::B version
3, gdb version
4, gcc version
5, you sample test code
6, the steps to reproduce this bug
With above info, we can help to test it.
The gdb in http://code.google.com/p/qp-gcc/ was created by me, and I'm currently use gcc 4.6.x, and I don't have such issue. I'm also on WinXP, if possible, please post your test code, thanks. I think this is mostly a gdb or gcc issue. If you could try, I can upload the latest gdb which is 2012-08-17cvs build by myself.Hi, you need to tell us:OK, I`ll try to create sample project. It not appears on simple codes.
1, OS
2, C::B version
3, gdb version
4, gcc version
5, you sample test code
6, the steps to reproduce this bug
With above info, we can help to test it.
Concerning other stuff:
1 OS- WinXP SP3 Rus
2 S::B : nightly build 8150 and 8086
3. gdb: gdb2012-05-22 form http://code.google.com/p/qp-gcc/ and gdb from nixmann mingw, both with python scripting
4. gcc 4.7.1 nixmann mingw http://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.1/release/
mingw placed on drive d:, and C::B- on drive c:
The gdb in http://code.google.com/p/qp-gcc/ was created by me, and I'm currently use gcc 4.6.x, and I don't have such issue.I know, thank you. :)
I'm also on WinXP, if possible, please post your test code, thanks.I`m trying to generate simple project, but it not help.
I think this is mostly a gdb or gcc issue. If you could try, I can upload the latest gdb which is 2012-08-17cvs build by myself.Yes, I can. I can not generate appropriate simple example. But I have strong suspicion that issue is originated form placing of mingw on drive d: I can not move it on c: even suspicion by some reasons.
I uploaded new gdb/patch in http://code.google.com/p/qp-gcc/, you can have a try.The gdb in http://code.google.com/p/qp-gcc/ was created by me, and I'm currently use gcc 4.6.x, and I don't have such issue.I know, thank you. :)QuoteI'm also on WinXP, if possible, please post your test code, thanks.I`m trying to generate simple project, but it not help.QuoteI think this is mostly a gdb or gcc issue. If you could try, I can upload the latest gdb which is 2012-08-17cvs build by myself.Yes, I can. I can not generate appropriate simple example. But I have strong suspicion that issue is originated form placing of mingw on drive d: I can not move it on c: even suspicion by some reasons.
I uploaded new gdb/patch in http://code.google.com/p/qp-gcc/, you can have a try.Unexpected result:
Building to ensure sources are up-to-date
Selecting target:
debug
Adding source dir: d:\mingw\run\prj1\prj1a\
Adding source dir: d:\mingw\run\prj1\prj1a\
Adding file: d:\mingw\run\prj1\prj1a\gui_nlsq3_db.exe
Changing directory to: d:/mingw/run/prj1/prj1a/.
[debug]PATH=.;d:\mingw\user\lib;d:\mingw\user\lib\gsl;d:\mingw\bin;d:\mingw;C:\Program Files\NVIDIA Corporation\PhysX\Common;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;C:\Program Files\Common Files\GTK\2.0\bin;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Program Files\QuickTime\QTSystem;
[debug]Command-line: d:\MinGW\bin\gdb.exe -nx -fullname -quiet -args d:/mingw/run/ptx_LaSrFeO4/pt_rf6_LaSrFeO4_03/gui_nlsq3_db.exe
[debug]Working dir : d:\mingw\run\prj1\prj1a
Starting debugger: d:\MinGW\bin\gdb.exe -nx -fullname -quiet -args d:/mingw/run/prj1/prj1a/gui_nlsq3_db.exe
done
[debug]> set prompt >>>>>>cb_gdb:
[debug]Skip initializing the scripting!
Setting breakpoints
[debug]Reading symbols from d:\mingw\run\prj1\prj1a\gui_nlsq3_db.exe...
[debug]done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.5.50.20120817-cvs
[debug]Copyright (C) 2012 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law. Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off
Debugger name and version: GNU gdb (GDB) 7.5.50.20120817-cvs
[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Function "__cxa_throw" not defined.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source d:\MinGW\bin\stl.gdb
source d:\MinGW\bin\wx.gdb
set print elements 100
[debug]>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:
[debug]> directory d:/mingw/run/prj1/prj1a/
[debug]Source directories searched: d:/mingw/run/prj1/prj1a;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> break "d:/mingw/run/prj1/prj1a/ld_csv/ld_xls_data.cpp:29"
[debug]No source file named d:/mingw/run/prj1/prj1a/ld_csv/ld_xls_data.cpp.
[debug]Breakpoint 2 ("d:/mingw/run/prj1/prj1a/ld_csv/ld_xls_data.cpp:29") pending.
[debug]>>>>>>cb_gdb:
[debug]> break "d:/mingw/run/prj1/prj1a/main.cpp:217"
[debug]No source file named d:/mingw/run/prj1/prj1a/main.cpp.
[debug]Breakpoint 3 ("d:/mingw/run/prj1/prj1a/main.cpp:217") pending.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: d:\mingw\run\prj1\prj1a\gui_nlsq3_db.exe
Child process PID: 3024
[debug][New Thread 3024.0x924]
[debug][Inferior 1 (process 3024) exited normally]
[debug]>>>>>>cb_gdb:
[Inferior 1 (process 3024) exited normally]
[debug]> quit
Debugger finished with status 0
What do you mean by "unexpected", did you mean that the breakpoint should be hit when the app runs?I uploaded new gdb/patch in http://code.google.com/p/qp-gcc/, you can have a try.Unexpected result:
What do you mean by "unexpected", did you mean that the breakpoint should be hit when the app runs?GDB missed breakpoint in the first line of the main()
BTW: can you try to build your app with mingw gcc 4.6.x, I build the gdb with 4.6.3, and I don't have the issue you reported. I found you were using the mingw gcc 4.7.X.I`m afraid I have to migrate back. Problem is that I just move to 4.7, everything looks fine and than I found the situation with debugging.
Unexpected result:I guess this is because niXman build lack some mingw target relocate patch, which is from TDM, but I am not quite sure.
His own gdb has this issue also. :(Unexpected result:I guess this is because niXman build lack some mingw target relocate patch, which is from TDM, but I am not quite sure.
std::string MyClass::TestCase()
{
std::string m;
m.
}
std::string MyClass::TestCase() throw(std::exception)
{
std::string m;
m.
}
For some reason, code completion won't fire (in C++) if I try to define a variable inside a function that has a "throw" specifier in its definition. For instance:This should be a bug, can you report the the official site: http://developer.berlios.de/bugs/?group_id=5358 , so this does not get lost in the forum.
1) This works fine (no throw specifier) - code completion fires OK for "m"Codestd::string MyClass::TestCase()
{
std::string m;
m.
}
2) This doesn't work (throw specifier added) - code completion does not fire for "m"Codestd::string MyClass::TestCase() throw(std::exception)
{
std::string m;
m.
}
Code::Blocks SVN 8150
Windows Vista 32bit
GNU GCC v4.7.1 (Mingw)
This should be a bug, can you report the the official site: http://developer.berlios.de/bugs/?group_id=5358 , so this does not get lost in the forum.
I think the CC's parser does not handle the "throw(std::exception)" correctly, so it does not recognize those code as a function body.
Thanks.
By the way: parser also doesn't recognize: const, volatile, final and override.Hi, I'm not sure what the exact problem you have, can you give a simple example? Or, you can fire a bug report in BerliOS too, thanks.
Dear ollydbg and xunxun, looks like I found source of the problems with gdb. Subjected PC has installed software with hardcore copyright protection (kind of system driver). And looks like any debugging acts which may touch external calls (function from dlls) leads to troubles for gdb. I had similar issue few year ago, but in previous case gdb can not work at all.Good to hear you solve the problem. :)
struct B
{
virtual void c( int argument ) = 0;
virtual void d( int argument ) = 0;
};
struct A : B
{
void a( int argument ) const
{
}
void b( int argument ) volatile
{
}
void c( int argument ) override
{
}
void d( int argument ) final
{
}
int member;
};
@ollydbg:Ok, thanks, this should be another kind of bug, can you fire another bug report in BerliOS?CodeParser doesn't see 'argument' inside those bodies.struct B
{
virtual void c( int argument ) = 0;
virtual void d( int argument ) = 0;
};
struct A : B
{
void a( int argument ) const
{
}
void b( int argument ) volatile
{
}
void c( int argument ) override
{
}
void d( int argument ) final
{
}
int member;
};
Thank you for support. But really good is that problem was not problem of gdb or mingw or C::B. :)Dear ollydbg and xunxun, looks like I found source of the problems with gdb. Subjected PC has installed software with hardcore copyright protection (kind of system driver). And looks like any debugging acts which may touch external calls (function from dlls) leads to troubles for gdb. I had similar issue few year ago, but in previous case gdb can not work at all.Good to hear you solve the problem. :)