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

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 21 July 2012 build (8150) is out.
« Reply #45 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.
(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 21 July 2012 build (8150) is out.
« Reply #46 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.
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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 21 July 2012 build (8150) is out.
« Reply #47 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.
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 Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 21 July 2012 build (8150) is out.
« Reply #48 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).

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: The 21 July 2012 build (8150) is out.
« Reply #49 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.
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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 21 July 2012 build (8150) is out.
« Reply #50 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).
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 nenin

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

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 21 July 2012 build (8150) is out.
« Reply #52 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.
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 nenin

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

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 21 July 2012 build (8150) is out.
« Reply #54 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.
« Last Edit: August 19, 2012, 03:07:35 pm by ollydbg »
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 nenin

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

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 21 July 2012 build (8150) is out.
« Reply #56 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.
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 nenin

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

Offline xunxun

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

Offline nenin

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