Author Topic: The 21 July 2012 build (8150) is out.  (Read 74925 times)

stefanos_

  • Guest
Re: The 21 July 2012 build (8150) is out.
« Reply #30 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.

Offline dot-borg

  • Single posting newcomer
  • *
  • Posts: 3
Re: The 21 July 2012 build (8150) is out.
« Reply #31 on: August 06, 2012, 06:51:19 am »
I get the following link errors building codeblocks on Ubuntu 12.04:

Code: [Select]
/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.
« Last Edit: August 06, 2012, 06:57:10 am by dot-borg »

Offline nenin

  • Multiple posting newcomer
  • *
  • Posts: 96
Re: The 21 July 2012 build (8150) is out.
« Reply #32 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: [Select]
[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". 
   

Offline tgucm

  • Multiple posting newcomer
  • *
  • Posts: 13
  • JSC++
Re: The 21 July 2012 build (8150) is out.
« Reply #33 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) )

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 ?
--
C++ novice as of 2011... C++ 'intermediate' as of 2012... please be kind O:-)

Offline tgucm

  • Multiple posting newcomer
  • *
  • Posts: 13
  • JSC++
Re: The 21 July 2012 build (8150) is out.
« Reply #34 on: August 08, 2012, 11:28:50 am »
I just got this warning from my antivirus program:

--
C++ novice as of 2011... C++ 'intermediate' as of 2012... please be kind O:-)

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: The 21 July 2012 build (8150) is out.
« Reply #35 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.

Offline tgucm

  • Multiple posting newcomer
  • *
  • Posts: 13
  • JSC++
Re: The 21 July 2012 build (8150) is out.
« Reply #36 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 )
--
C++ novice as of 2011... C++ 'intermediate' as of 2012... please be kind O:-)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12224
    • Travis build status
Re: The 21 July 2012 build (8150) is out.
« Reply #37 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

chevydevil

  • Guest
Re: The 21 July 2012 build (8150) is out.
« Reply #38 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.

esci

  • Guest
Re: The 21 July 2012 build (8150) is out.
« Reply #39 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.)

Offline Freem

  • Almost regular
  • **
  • Posts: 219
Re: The 21 July 2012 build (8150) is out.
« Reply #40 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.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: The 21 July 2012 build (8150) is out.
« Reply #41 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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12224
    • Travis build status
Re: The 21 July 2012 build (8150) is out.
« Reply #42 on: August 16, 2012, 06:52:13 pm »
Hm, strange... ???
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9528
Re: The 21 July 2012 build (8150) is out.
« Reply #43 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...)?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: The 21 July 2012 build (8150) is out.
« Reply #44 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.