Author Topic: The 17 May 2012 build (7966) is out.  (Read 87076 times)

Offline hooluupog

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: The 17 May 2012 build (7966) is out.
« Reply #45 on: May 30, 2012, 08:42:08 am »
Hi, Hooluupog. I do not think so.

Codeblocks just serves as a front end of gdb, so the most situation is: gdb freeze cause codeblocks freeze.

I believe you can give use the log of both gdb (under Windows Shell) and the gdb log (under Codeblocks Debugger panel), then we can see whether you are true. :)
It just freezed,the debugger stopped working,and showed none gdb log output. Meanwhile cpu usage was keeping 50%(i3 quard Core cpu).You can see my screenshot.

[attachment deleted by admin]
« Last Edit: May 30, 2012, 08:54:05 am by hooluupog »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 17 May 2012 build (7966) is out.
« Reply #46 on: May 30, 2012, 09:02:33 am »
Don't use "set print elements 0" if you use it and you have large data structures it will be slow - end of discussion.
(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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 17 May 2012 build (7966) is out.
« Reply #47 on: May 30, 2012, 09:07:52 am »
Hi, Hooluupog. I do not think so.

Codeblocks just serves as a front end of gdb, so the most situation is: gdb freeze cause codeblocks freeze.

I believe you can give use the log of both gdb (under Windows Shell) and the gdb log (under Codeblocks Debugger panel), then we can see whether you are true. :)
It just freezed,the debugger stopped working,and showed none gdb log output. Meanwhile cpu usage was keeping 50%(i3 quard Core cpu).You can see my screenshot.
OK, if you debug your program in GDB (Windows shell), the gdb should be freeze too.  :)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline hooluupog

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: The 17 May 2012 build (7966) is out.
« Reply #48 on: May 30, 2012, 09:17:44 am »
Hi, Hooluupog. I do not think so.

Codeblocks just serves as a front end of gdb, so the most situation is: gdb freeze cause codeblocks freeze.

I believe you can give use the log of both gdb (under Windows Shell) and the gdb log (under Codeblocks Debugger panel), then we can see whether you are true. :)
It just freezed,the debugger stopped working,and showed none gdb log output. Meanwhile cpu usage was keeping 50%(i3 quard Core cpu).You can see my screenshot.
OK, if you debug your program in GDB (Windows shell), the gdb should be freeze too.  :)
No,I have tried many times. In gdb command environment  it is very fast to print the elements but slow within codeblocks(nearly 5 mins or so to show the result,feels like it freezed).
« Last Edit: May 30, 2012, 09:19:16 am by hooluupog »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 17 May 2012 build (7966) is out.
« Reply #49 on: May 30, 2012, 09:19:58 am »
Yes, it is known issue...
(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: 9694
Re: The 17 May 2012 build (7966) is out.
« Reply #50 on: May 30, 2012, 10:37:01 am »
Yes, it is known issue...
Yes, I noticed that, too. We should try to find a solution for that. IMHO its related to the PipedProcess class but this is hard to track and (as we found out many times) a sensitive component. My suggestion would be to introduce an own "PipedProcess" class better suited for the debugger not affecting any other components.
@oBFusCATed would that be a "good thing to do" [tm]?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 17 May 2012 build (7966) is out.
« Reply #51 on: May 30, 2012, 12:02:19 pm »
The general slowness comes from the fact that every line of output generates a wx event, which is quite slow.
The previous attempt failed rather miserably, so I'm not sure I want to invest time in improving the situation.
I have very little free time at the moment, because I've started to write my Bachelor's thesis (or whatever is the name in English), so the next two-three mouths will be quite busy.

The GDB/MI plugin doesn't have this problem, because there are less lines of output. Every result from a command is a single line. But unfortunately it is not ready. :)
(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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 17 May 2012 build (7966) is out.
« Reply #52 on: May 30, 2012, 01:48:35 pm »
The general slowness comes from the fact that every line of output generates a wx event, which is quite slow.
The previous attempt failed rather miserably, so I'm not sure I want to invest time in improving the situation.
I have very little free time at the moment, because I've started to write my Bachelor's thesis (or whatever is the name in English), so the next two-three mouths will be quite busy.
Congratulation!
It looks like you are much younger than me. :)

Quote
The GDB/MI plugin doesn't have this problem, because there are less lines of output. Every result from a command is a single line. But unfortunately it is not ready. :)
What has left in GDB/MI?

@hooluupog
Can you post the steps in both GDB command line and Codeblocks log, also the source code. I'm going to test the lag. Thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 17 May 2012 build (7966) is out.
« Reply #53 on: May 30, 2012, 02:10:28 pm »
Congratulation!
It looks like you are much younger than me. :)
Not that young, I've used the whole available period of 5 years for postponing it :)

What has left in GDB/MI?
Polishing...

@hooluupog
Can you post the steps in both GDB command line and Codeblocks log, also the source code. I'm going to test the lag. Thanks.
Create an array with 10000 elements and try to watch it, should trigger the bug.
If it doesn't trigger it, try array with 10000 wxstring or std::string elements :)

Another way to test it to add 10-20 big classes (many members in them) in the watch window.
(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 hooluupog

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: The 17 May 2012 build (7966) is out.
« Reply #54 on: May 30, 2012, 06:12:07 pm »
]
@hooluupog
Can you post the steps in both GDB command line and Codeblocks log, also the source code. I'm going to test the lag. Thanks.
The source code and codeblock's log are in attachment.
The steps of GDB command line:
(gdb)file main.exe
(gdb)set print elements 0
(gdb) source c:/minGW32/bin/.gdbinit
(gdb) b 8
(gdb)b 15
(gdb)r
(gdb)c
(gdb)p s
(gdb)p in

[attachment deleted by admin]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 17 May 2012 build (7966) is out.
« Reply #55 on: May 31, 2012, 03:04:23 am »
@hooluupog
Can you post the steps in both GDB command line and Codeblocks log, also the source code. I'm going to test the lag. Thanks.
The source code and codeblock's log are in attachment.
The steps of GDB command line:
(gdb)file main.exe
(gdb)set print elements 0
(gdb) source c:/minGW32/bin/.gdbinit
(gdb) b 8
(gdb)b 15
(gdb)r
(gdb)c
(gdb)p s
(gdb)p in
Ok, I just test your example code: (I try to print the s when after breakpoint in line 15 hits)
1, CB gdb plugin, CB hangs for more than one minute, and I just close it from Windows Task manager.
2, CB gdb-mi plugin, CB hangs about half a minute, and all the contents was shown in the debuggers log:
Quote
...
[65200]",exp="[65200]",numchild="0",value="1",type="int",thread-id="1"},child={name="var1.[65201]",exp="[65201]",numchild="0",value="3",type="int",thread-id="1"},child={name="var1.[65202]",exp="[65202]",numchild="0",value="7",type="int",thread-id="1"}],has_more="0"
3, in gdb Windows Shell (Windows Console window), gdb print the whole value quickly, about 5-6 seconds.

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline cacb

  • Lives here!
  • ****
  • Posts: 536
Re: The 17 May 2012 build (7966) is out.
« Reply #56 on: June 02, 2012, 10:18:21 pm »
I have reported this before, but it seems to me that the last few months, something has happened to the C::B nightly builds on Windows that cause my projects to build significantly slower than before. My setup is Windows XP SP3, on HP xw4600 Workstation Intel(R) Core(TM)2 Duo CPU E7200@2.53GHz, C::B is set to use 2 processes for parallell builds in the Global Compiler Settings (build options). The compiler is MS Visual C++ 2010 express. I have downloaded pre-built nightlies from this forum only, I never build C::B from source code myself.

I just did an experiment, compiling my own source code using the above, but 2 different nightly builds of C::B. Observe that the only difference is the C::B IDE version, everything else is the same. The source code, project files and build targets are all the same.

I compiled my code 6 times (always complete Rebuild Workspace) in the following sequence

Nightly build CB 7452:                                0 errors, 0 warnings (1 minutes, 35 seconds)
Nightly build CB 7966:  === Build finished: 0 errors, 1 warnings (3 minutes, 39 seconds) ===
Nightly build CB 7452:                                0 errors, 0 warnings (1 minutes, 36 seconds)
Nightly build CB 7966:  === Build finished: 0 errors, 1 warnings (2 minutes, 57 seconds) ===
Nightly build CB 7452:                                0 errors, 0 warnings (1 minutes, 40 seconds)
Nightly build CB 7966:  === Build finished: 0 errors, 1 warnings (3 minutes, 2 seconds) ===

When looking at the "Performance" tab in the XP Task Manager, it is apparent that compilation is pausing a lot when running under CB 7966. This does not happen with CB 7452, and apparently that makes all the difference. After all the compiler and linker is exactly the same.

Have anyone here seen anything like this? Obviously it is an annoying problem, preventing me from using the newest nightlies.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 17 May 2012 build (7966) is out.
« Reply #57 on: June 02, 2012, 10:26:30 pm »
cacb:
Enable the full build log and compare the logs for the two nighlies.
If the commands are the same the errors and warning numbers must be the same, but they aren't.
(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 cacb

  • Lives here!
  • ****
  • Posts: 536
Re: The 17 May 2012 build (7966) is out.
« Reply #58 on: June 02, 2012, 11:50:34 pm »
I agree the difference in warning was an oddity, and I am not able to reproduce it now. When I run using both nightlies now, I get no warnings either way. I think the warning was about an object file exporting no symbols, btw.

HOWEVER, I have now re-run the experiment using the different nightlies (getting 0 errors, 0 warnings in both), with logs. The time difference and other behaviour I explained remains as before, big difference. I have studied the logs and find no difference whatsoever in the compiler options. The format of the logs are not exactly the same, however, when running with the 7966 nightly, the name of the compiler is reported for every project build target. With the 7452 nightly, the compiler name is not reported.

e.g.

for 7452
-------------- Build: W32_Debug in FlexTime ---------------

for 7966
-------------- Build: W32_Debug in FlexTime (compiler: MSVC)---------------

I can also see that the compile order is sometimes not exactly the same, it seems 7966 compiles project files in alphabetical sort order, while 7452 uses "some other order". Perhaps it is random, due to multiple CPUs, I don't know. But the sorting differences are such that a full compare using KDIFF3 is not practical. So instead I have looked at various samples manually.

It is clear that for the same files
- the compiler options are exactly the same
- the include paths are exactly the same, both referring to VC2010 Express installation
- the linker commands are exactly the same
- resource builds are the exactly same

Still the build times are very different, 7966 takes almost twice as long.

I tend to believe the differences have nothing to do with the build system as such. The 7966 Nightly generally appears more sluggish on my computer, and the 7452 is more responsive, for example during start-up or shut-down of the IDE (no build going on). I am just guessing here, but if 7966 is accessing the configuration (windows registry) more aggressively than 7452, it could have a big impact. Or it could be due to something entirely different.

What I am saying is that I cannot find any indication that the build time difference has anything to do with the parameters or options provided to the compiler/linker, and I have positively confirmed that the compiler/linker tools are the exactlty same in the two cases.

Still, the difference remains.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 17 May 2012 build (7966) is out.
« Reply #59 on: June 03, 2012, 12:05:30 am »
If you where on unix you can have used the sort utility to sort both files :)
Is there a chance to try to bisect the nightly which is causing the slowness.
We have several nightlies in between 7452 and 7966.
(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!]