Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on July 21, 2012, 05:23:59 pm

Title: The 21 July 2012 build (8150) is out.
Post by: killerbot on July 21, 2012, 05:23:59 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 21 July 2012 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20120721_rev8150_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 21 July 2012 build (8150) is out.
Post by: Jenna on July 21, 2012, 05:30:17 pm
As usual:
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (http://apt.jenslody.de/).
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc15, fc16 and fc17) can be found in my rpm-repo (http://rpm.jenslody.de) .

Important note for debian (and ubuntu) users:
I changed the layout of my debian-repo, to fix the issue described in this thread:
http://forums.codeblocks.org/index.php/topic,16357.msg110806.html#msg110806 (http://forums.codeblocks.org/index.php/topic,16357.msg110806.html#msg110806)
Please (re)read the instructions on my website (http://apt.jenslody.de/), and fix your entries in /etc/apt/sources.list[.d] accordingly.

RedHat/CentOS 5 and 6 packages will follow.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: damorin on July 21, 2012, 08:47:54 pm
Hi.

the syntax highlighting for the C/C++ keyword was not using my selected foreground color (my setting is yellow on black background),  in the editor all keywords were dark blue (but all other setting were OK, including background).

When I clicked on the foreground to set again with the same yellow, the keywords were back to the correct color. This is looking like a default setting not updated correctly.

WinXP Build 8150.






Title: Re: The 21 July 2012 build (8150) is out.
Post by: savya on July 22, 2012, 01:38:02 am
I'm having trouble with syntax highlighting with this new build 8150 on Windows 7. On my system all the keywords appear black, braces & parenthesis appear highlighted and user keywords appear bold red. It seems it did not pick up my previous "syntax highlighting" settings correctly.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: MortenMacFly on July 22, 2012, 08:36:40 am
For those with the syntax highlighting issue: I don't understand what you mean. Screenshot? Steps to reproduce?
Title: Re: The 21 July 2012 build (8150) is out.
Post by: Jenna on July 22, 2012, 10:26:16 am
Nighly packages for RedHat/CentOS 5 and 6 are now available from my rpm-repo (http://rpm.jenslody.de) .
You need additional packages from other repos, see my site (http://rpm.jenslody.de) for details.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: savya on July 22, 2012, 08:43:34 pm
Screenshot from build 8150:  http://flic.kr/p/cBFsiC (http://flic.kr/p/cBFsiC)
Screenshot from build 8086:  http://flic.kr/p/cBFsmC (http://flic.kr/p/cBFsmC)

I have included herewith the screen shots of the "syntax highlighting" issue with the latest build (8150) on Win7. I experienced this problem from the moment I installed the latest nightly build and began using it. I have also included a screen shot from the previous build (8086) for comparison. I hope this helps. Please let me know if you need more information.

P.S.- I am thankful to the C::B team for producing this simple, elegant and "free" IDE. I have been using it for a long time and I'm in love with it. Since this has been the first time that I have involved myself in the C::B forums, I wanted to express my gratitude to the developers. Keep up the good work.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: cacb on July 22, 2012, 11:14:48 pm
The Windows version of 8150 has a significant issue in that all the wxSmith RAD editor images are missing. This makes wxSmith unusable since all the standard button images are replaced by text which is much wider and thus hidden by a scrollbar. See attached.

Linux *.deb variant of 8150 from Jens is OK in this regard.

On Windows I was able to fix the wxSmith problem locally, by copying the wxSmith image folder (missing in 8150) from Nightly Build 8086. Observe that there appears to be other images subfolders missing also, see attached screenshot.

Title: Re: The 21 July 2012 build (8150) is out.
Post by: MortenMacFly on July 23, 2012, 06:32:33 am
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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: savya on July 23, 2012, 07:18:04 am
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.


I have attached a 7z file containing the editor color scheme.

Title: Re: The 21 July 2012 build (8150) is out.
Post by: Vuki on July 23, 2012, 09:28:25 am
This change in lexer_cpp.xml:
Code
                <Style name="Comment (normal)"
                        index="1,23"
                        fg="160,160,160"/>

is causing problems. When i changed it back to the previous form:
Code
                <Style name="Comment (normal)"
                        index="1"
                        fg="160,160,160"/>
the highlighter works correctly. The added ",23" part borks the highlighter and causes it to select colors from wrong entries.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: carra on July 23, 2012, 09:40:59 am
Apart from what Vuki said, it might have something to do with the update to the new Scintilla 3.2.1.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: trivia21 on July 23, 2012, 01:15:47 pm
I'm using svn 8162 under linux and have a problem with syntax highlighting as well.
The "Keyword" option changes the color of numbers, while I need to use "User keyword" to change the color of keywords (int, char etc.). I can't remember if there was a "Numbers" menu item, but there isn't one right now.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: MortenMacFly on July 23, 2012, 01:47:32 pm
This change in lexer_cpp.xml:
Code
                <Style name="Comment (normal)"
                        index="1,23"
                        fg="160,160,160"/>
This is actually correct - style 23 refers to "wxSTC_C_PREPROCESSORCOMMENT", which shall be coloured like a normal comment therefore.

I wonder why I don't see this...?! Could it be that you simply didn't define this style?
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ptDev on July 23, 2012, 03:03:50 pm
The unofficial installer for Windows has also been updated to match the same revision as the nightly build. Note that it is slightly unstable in comparison and includes a number of low-risk patches (meant for early testing by more users).

See a list of differences between the two here (http://forums.codeblocks.org/index.php/topic,13234.msg88948.html#msg88948).
Title: Re: The 21 July 2012 build (8150) is out.
Post by: stefanos_ on July 24, 2012, 04:28:13 pm
WIth svn-8163, Windows XP (SP3), TDM's GCC 4.6.1 [32-bit], a few issues remain the same.

Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on July 24, 2012, 05:14:25 pm
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.

The code base of wxSmith is quite complex for me :). It was not maintained for a long time.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: Alpha on July 24, 2012, 06:06:01 pm
  • 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?
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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: stefanos_ on July 24, 2012, 08:16:14 pm
Quote
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.

Indeed I have seen some C::B code myself and got lost. Also the generated code needs clean up...a lot.

For example, the generated code for 2.9.x should be totally different than the 2.8.x. e.g. wxT() / _T() is unnecessary if you don't care about backward compatibility; it has got replaced with actual double quotes which is very cool i would say. Also, wxNewId() got deprecated in favor of wxID_ANY to avoid conflicts with user define IDs.

That's all i can remember right now. If i find anything else, i will update my message here.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: oBFusCATed on July 24, 2012, 09:16:23 pm
stefanos_:
1. 2.9 is not released yet, so they can change their mind :)
2. we don't support it in wxsmith officially as far as I know
Title: Re: The 21 July 2012 build (8150) is out.
Post by: stefanos_ on July 25, 2012, 07:58:14 am
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)
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ptDev on July 25, 2012, 09:14:50 am
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)

It looks like the intention was to define PLUGIN_EXPORT as dllexport if either of EXPORT_LIB or BUILDING_PLUGIN is defined.
PLUGIN_EXPORT was a poor choice of macro name (something like CB_PLUGIN_API would have been better imho).
That arrowhead certainly could be simplified.

Title: Re: The 21 July 2012 build (8150) is out.
Post by: MortenMacFly on July 25, 2012, 09:34:50 pm
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:
__declspec (dllexport)
and
__declspec (dllimport)
We want to have one macro to achieve both: exporting and importing. If it would have two different names this would not work.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: chice on July 26, 2012, 03:25:03 pm
in rev8150 windows version, many resources (eg: icons) are broken and can not be displayed correctly.

rev8086 is ok.

Title: Re: The 21 July 2012 build (8150) is out.
Post by: Alpha on July 26, 2012, 06:10:58 pm
This change in lexer_cpp.xml:
Code
                <Style name="Comment (normal)"
                        index="1,23"
                        fg="160,160,160"/>

is causing problems. When i changed it back to the previous form:
Code
                <Style name="Comment (normal)"
                        index="1"
                        fg="160,160,160"/>
the highlighter works correctly. The added ",23" part borks the highlighter and causes it to select colors from wrong entries.
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).

A possible solution would be for the affected users to manually search default.conf for the lexer related entries, modifying what seems appropriate,
or deleting/moving default.conf, and recreating the preferred color scheme.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: elettronica67 on July 28, 2012, 07:26:50 am
Hi, I still have problems with syntax highlight.
I have noted that in Settings->Editor->Syntax highlighting from the choice "Number" (included) in ahead everything is shifted by one position.
Hope that this will help you, For now I solved the problem by installing the previous nightly version.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: stefanos_ on July 30, 2012, 11:17:30 am
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?

Specs:

OS: Windows XP SP3
Compiler: TDM's GCC 4.5.2 (GCC 4.6.1)
wxWidgets: 2.8.10 / 2.9.4
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on July 30, 2012, 11:28:29 am
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?

Specs:

OS: Windows XP SP3
Compiler: TDM's GCC 4.5.2 (GCC 4.6.1)
wxWidgets: 2.8.10 / 2.9.4
Addr2line.exe is mainly distributed in your MinGW, it is mostly located under MinGW/bin folder.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: stefanos_ on July 30, 2012, 11:30:38 am
Yeah...of course...I knew it :P NOT! :D hahahah thanks a lot ollydbg for letting me know ;)
Title: Re: The 21 July 2012 build (8150) is out.
Post by: stefanos_ on August 01, 2012, 05:48:48 pm
The tooltip issue http://forums.codeblocks.org/index.php/topic,16560.msg112659.html#msg112659 remains the same on Debian wheezy too. Also tab button does not work on Properties when I use .wxs files.

UPDATE: I opened two projects, opened their wxSmith files to compare them and upon closing one of the two, it crashed but the generated report located in /tmp/ directory got immediately deleted. How silly is that?! How am I supposed to let you know if it does not keep the report file somewhere? Is this behavior normal?
Title: Re: The 21 July 2012 build (8150) is out.
Post by: stefanos_ on August 05, 2012, 03:24:23 pm
On my Debian wheezy [32-bit] svn-8175, crashed (again) upon closing a project. This time i could save the generated report; I compile Code::Blocks with GCC compiler 4.6.3.

Below you can find report as an attachment.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: dot-borg on August 06, 2012, 06:51:19 am
I get the following link errors building codeblocks on Ubuntu 12.04:

Code
/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'

Any ideas?

[edit] Never mind. Uninstalling binutils-gold seems to have fixed the issue.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: nenin on August 07, 2012, 01:23:15 pm
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:
Code
[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.
After this message C::B typically lost connection with gdb.
It appears typically if line contains function call.
It not appears if I jumps between breakpoints or make "Run to cursor". 
   
Title: Re: The 21 July 2012 build (8150) is out.
Post by: tgucm on August 08, 2012, 11:20:11 am
I just installed C::B version 8150 and so far it's working great for me on Win7 64-bit :)

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 by insttructions on the page:

http://forums.codeblocks.org/index.php/topic,3232.0.html ( Topic: How to use a nightly build  (Read 225233 times) ) (http://forums.codeblocks.org/index.php/topic,3232.0.html)

Could the problems others are having be from trying to upgrade an existing install of C::B ?  I havent ever done that yet but is there a walk thru I could review for when i go to the next version of C::B myself down the line ?
Title: Re: The 21 July 2012 build (8150) is out.
Post by: tgucm on August 08, 2012, 11:28:50 am
I just got this warning from my antivirus program:

Title: Re: The 21 July 2012 build (8150) is out.
Post by: Jenna on August 08, 2012, 12:09:51 pm
I just got this warning from my antivirus program:

Searching the web for PDM.RootShell shows, that this is one of the most false positives of kaspersky.

You should add an exception for Code::Blocks, to get rid of the warning.
It might also help to install it in a different place or use different folders for your projects, so you are sure to use only user-folders to write in.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: tgucm on August 08, 2012, 12:34:48 pm
Done, thanks Jens  :)

Edit: btw, does your linux builds of C::B work on non-debian releases? ( im still new to linux )
Title: Re: The 21 July 2012 build (8150) is out.
Post by: oBFusCATed on August 08, 2012, 01:20:05 pm
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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: chevydevil on August 14, 2012, 07:45:51 pm
I don't know if this is the right place but I have an issue with a relatively large c project: Everything is really slow, clicking randomly in the code makes the whole gui freeze sometimes for nearly a second. I thought it is the code completion but disabling all plugins does not change anything. The issue is not restricted to the current version though.
I am working under Ubuntu 12.04 with an 8-Core CPU, 8 GB Ram and a ssd.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: esci on August 15, 2012, 07:51:57 pm
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.)
Title: Re: The 21 July 2012 build (8150) is out.
Post by: Freem on August 16, 2012, 12:54:34 pm
Code statistics seem to freeze C::B on whole workspace when it is summoned while CC is still parsing (at least, on Debian).

Steps to reproduce:
_ on a slow computer (a netbook in my case, did not try with a desktop PC)
_ open a workspace with enough projects and files so it will take time to CC to parse everything
_ use code statistics and select "entire workspace"
_ C::B will freeze, maybe when CC and code stat try to parse the same file. I have no more clue.

Apart from that, it is a great idea to allow to parse entire workspace. If I may suggest something, it could be useful also for refactoring: currently, there are only "opened files" and "project files" buttons. But when it is a library used by other projects, it is needed to use the replace function.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: Jenna on August 16, 2012, 01:37:18 pm
Code statistics seem to freeze C::B on whole workspace when it is summoned while CC is still parsing (at least, on Debian).

I can confirm this, but it happens not always.

I don't see a real cause, why this can happen, because the two plugins do not depend on each other.
Probably it is related to wxEVT_IDLE, which is used to parse the entire workspace.

I will try to dig into it deeper this evening.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: oBFusCATed on August 16, 2012, 06:52:13 pm
Hm, strange... ???
Title: Re: The 21 July 2012 build (8150) is out.
Post by: MortenMacFly on August 16, 2012, 08:46:20 pm
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.

Maybe I should provide a patch here for testing... (I need to clean it up a bit hough...)?!
Title: Re: The 21 July 2012 build (8150) is out.
Post by: Jenna on August 16, 2012, 10:13:26 pm
I will try to dig into it deeper this evening.
I'm afraid this won't be too easy.

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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: oBFusCATed on August 16, 2012, 10:20:47 pm
I've seen the wxExecute problem and I thought this is a wxExecute bug, because this function is notorious for being thread unsave one, through out the years.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on August 17, 2012, 05:04:42 am
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:
Code
[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.
After this message C::B typically lost connection with gdb.
It appears typically if line contains function call.
It not appears if I jumps between breakpoints or make "Run to cursor". 
   

Hi, you need to tell us:
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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on August 17, 2012, 05:55:32 am

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.

I looked at the attachment file, and I see that the bt looks like:
Code
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
.......

So, does it only happens when CodeStatExecDlg::Execute is executed? I just browse CodeStat plugin source, I don't see it call wxExecute there, so wxExecute is only executed in the CC's timer handler.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: Jenna on August 17, 2012, 06:39:24 am
This issue only happens, when CodeStats-plugin is executed and runs for a longer time, while parsing a workspace.
And it seems to intersect only with the timer-driven function of cc and only when wxExecute is run from ExpandBackticks.
But the last one might be wrong. I don't know how many parser-functions call wxExecute, so it might be the only one or it might be a fluke.

I will test whether I can reproduce what happens, if a large project is parsed.
It might be related to project switching of CC.
We have another bug related to this (missing search-dirs while parsing of a workspace by CC).
Title: Re: The 21 July 2012 build (8150) is out.
Post by: MortenMacFly on August 17, 2012, 06:49:16 am
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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on August 17, 2012, 07:18:16 am
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 agree, "timer-foo" design has some flaws. Also the lockers in CC is another kind of flaws. :)

Quote
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:
Quote
We have another bug related to this (missing search-dirs while parsing of a workspace by CC).
Title: Re: The 21 July 2012 build (8150) is out.
Post by: nenin on August 17, 2012, 02:29:44 pm
Hi, you need to tell us:
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.
OK, I`ll try to create sample project. It not appears on simple codes.
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:
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on August 17, 2012, 03:13:58 pm
Hi, you need to tell us:
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.
OK, I`ll try to create sample project. It not appears on simple codes.
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'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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: nenin on August 19, 2012, 11:45:42 am
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.  :)
Quote
I'm also on WinXP, if possible, please post your test code, thanks.
I`m trying to generate simple project, but it not help.
Quote
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.   
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on August 19, 2012, 03:03:47 pm
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.  :)
Quote
I'm also on WinXP, if possible, please post your test code, thanks.
I`m trying to generate simple project, but it not help.
Quote
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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: nenin on August 21, 2012, 11:22:23 am
I uploaded new gdb/patch in http://code.google.com/p/qp-gcc/, you can have a try.
Unexpected result:
Code
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
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on August 21, 2012, 11:39:45 am
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?

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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: nenin on August 21, 2012, 11:49:32 am
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()
Quote
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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: xunxun on August 21, 2012, 04:05:25 pm
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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: nenin on August 22, 2012, 10:36:17 am
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.   :(
Title: Re: The 21 July 2012 build (8150) is out.
Post by: Agetian on August 25, 2012, 06:41:33 am
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:

1) This works fine (no throw specifier) - code completion fires OK for "m"
Code
std::string MyClass::TestCase()
{
    std::string m;
    m.  
}

2) This doesn't work (throw specifier added) - code completion does not fire for "m"
Code
std::string MyClass::TestCase() throw(std::exception)
{
    std::string m;
    m.
}

Code::Blocks SVN 8150
Windows Vista 32bit
GNU GCC v4.7.1 (Mingw)
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on August 25, 2012, 05:35:24 pm
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:

1) This works fine (no throw specifier) - code completion fires OK for "m"
Code
std::string MyClass::TestCase()
{
    std::string m;
    m.  
}

2) This doesn't work (throw specifier added) - code completion does not fire for "m"
Code
std::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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: Agetian on August 25, 2012, 06:15:30 pm

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.


Done and done. :) Thanks!
Title: Re: The 21 July 2012 build (8150) is out.
Post by: p2rkw on August 25, 2012, 09:19:24 pm
By the way: parser also doesn't recognize: const, volatile, final and override.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: nenin on August 26, 2012, 04:20:12 pm
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.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on August 26, 2012, 04:21:25 pm
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.

Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on August 26, 2012, 04:28:59 pm
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. :)
Title: Re: The 21 July 2012 build (8150) is out.
Post by: p2rkw on August 26, 2012, 04:53:16 pm
@ollydbg:
Code
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;
};
Parser doesn't see 'argument' inside those bodies.
Title: Re: The 21 July 2012 build (8150) is out.
Post by: ollydbg on August 26, 2012, 05:18:11 pm
@ollydbg:
Code
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;
};
Parser doesn't see 'argument' inside those bodies.
Ok, thanks, this should be another kind of bug, can you fire another bug report in BerliOS?
I just read the parser's source code in: plugins\codecompletion\parser\parserthread.cpp, maybe you can have a try to run the cc_test.cbp project to see how the logic goes in the parser. Believe me, it is quite simple, our parser does not do very complex analysis.  :)
Title: Re: The 21 July 2012 build (8150) is out.
Post by: nenin on August 26, 2012, 05:34:56 pm
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. :)
Thank you for support. But really good is that problem was not problem of gdb or mingw or C::B.  :)