User forums > Nightly builds
The 21 July 2012 build (8150) is out.
oBFusCATed:
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.
ollydbg:
--- Quote from: 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.
--- End code ---
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".
--- End quote ---
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.
ollydbg:
--- Quote from: jens on August 16, 2012, 10:13:26 pm ---
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.
--- End quote ---
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
.......
--- End code ---
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.
Jenna:
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).
MortenMacFly:
--- Quote from: jens on August 17, 2012, 06:39:24 am ---And it seems to intersect only with the timer-driven function of cc and only when wxExecute is run from ExpandBackticks.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version