News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

Problems discovered in branches/wxpropgrid_debugger SVN7712

Started by mmccarty12, January 24, 2012, 12:50:06 AM

Previous topic - Next topic

oBFusCATed

Quote from: mmccarty12 on February 17, 2012, 05:05:07 PM
After upgrading to CB7713, gdb-7.1:
I was no longer able to insert break points while the program was running.  The Debug window would display the message:
QuoteCode::Blocks is trying to interrupt process with pid: 21664; child pid: 0 gdb pid: 21664
And here is the real reason for your problem. As I've said the warning is harmless.
The problem is that child pid detection has failed and your gdb doesn't interrupt the debuggee, when it receives SIGINT signal.

And I'm repeating myself!

Can you try to use the native gcc (4.1.2)?

p.s. I'm running gdb-7.4 and there are no problems with it.
(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!]

mmccarty12

QuoteCan you try to use the native gcc (4.1.2)?
I am now really confused.  I am talking about my problems with the gdb-7.x debugger.  Why are you asking me to use gcc-4.1.2?
What does the compiler version have to do with the debugger version?

Also, the problems I encountered went away when I downgraded back to gdb-6.8. I am not the only person who has encountered the console window connection problem.
https://www.google.com/#sclient=psy-ab&hl=en&source=hp&q=warning:+GDB%3A+Failed+to+set+controlling+terminal%3A+Operation+not+permitted&pbx=1&oq=warning:+GDB%3A+Failed+to+set+controlling+terminal%3A+Operation+not+permitted&aq=f&aqi=g2g-v1g-j1&aql=&gs_sm=12&gs_upl=495l495l0l2912l1l1l0l0l0l0l118l118l0.1l1l0&bav=on.2,or.r_gc.r_pw.,cf.osb&fp=ae73f10212a66505&biw=1218&bih=829

oBFusCATed

#17
OK, I quit :)

Edit: To prove that I'm right please paste the line

Code::Blocks is trying to interrupt process with pid: 21664; child pid: 0 gdb pid: 21664

When using gdb 6.8, you'll see that the 0 in the middle is not zero.
(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!]

mmccarty12

Obfuscated,

I appreciate you taking the time to try to help.  I am not trying to be an ass, nor am I stupid.  From my point of view, what you are telling me is not making any sense.  I responded as I did above because I believed you misunderstood my situation.  Just saying "Do this." without saying why does not make any sense and is not normally like you.  I have dealt with you here in the past and in #codeblocks in chat.  Normally you give an explanation as to why something is happening, and why your suggestion can/will work.  Here, it seems that you have not made yourself clear, from my perspective, so I ask you to explain.  

QuoteCode::Blocks is trying to interrupt process with pid: 21664; child pid: 0 gdb pid: 21664
has no meaning, except that it seems to be causing me to not be able to do what I was able to do before the upgrade.  

QuoteThe problem is that child pid detection has failed and your gdb doesn't interrupt the debuggee, when it receives SIGINT signal.
Why is child pid detection failing with gdb-7.x and not gdb-6.8?
Why will changing the compiler fix everything?

oBFusCATed

About the compiler: Because you're using some self compiled compiler or compiler compiled by someone else. And I wanted to remove one uncertainty.

About the message:
It has great meaning if you know how to read it :)
It is a debug message, telling you/me what C::B is doing. In this case it is telling to which process C::B is sending SIGINT. SIGINT is the same as Ctrl+C in terminal.
And in order to insert a new breakpoint, C::B has to stop the execution of the debuggee and then it can insert breakpoints then it will resume it.
Unfortunately this is not very reliable, because there are many different ways to do it, depending on the version of gdb and os.

Newer gdb's are supposed to interrupt the process, when they receive the SIGINT, older ones work only when the debuggee receives the SIGINT signal.
Unfortunately for some programs newer gdbs don't print the pid information during startup and we don't know the debuggee's PID, thus C::B falls back to sending signal directly to GDB.

And for some unknown reason, you newer gdb's fail to interrupt the debuggee, when they receive the SIGINT.
I guess you can try to ask the gdb devs in #gdb.

Do you have SELinux enabled? If you have, can you try without it?

p.s. please post the line from gdb-6.8!
(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!]

mmccarty12

Quote from: oBFusCATed on February 17, 2012, 06:03:00 PM
About the compiler: Because you're using some self compiled compiler or compiler compiled by someone else. And I wanted to remove one uncertainty.
I am using the rpm of gcc-4.4.

Quote
About the message:
It has great meaning if you know how to read it :)
It is a debug message, telling you/me what C::B is doing. In this case it is telling to which process C::B is sending SIGINT. SIGINT is the same as Ctrl+C in terminal.
And in order to insert a new breakpoint, C::B has to stop the execution of the debuggee and then it can insert breakpoints then it will resume it.
Unfortunately this is not very reliable, because there are many different ways to do it, depending on the version of gdb and os.

Newer gdb's are supposed to interrupt the process, when they receive the SIGINT, older ones work only when the debuggee receives the SIGINT signal.
Unfortunately for some programs newer gdbs don't print the pid information during startup and we don't know the debuggee's PID, thus C::B falls back to sending signal directly to GDB.

And for some unknown reason, you newer gdb's fail to interrupt the debuggee, when they receive the SIGINT.
I guess you can try to ask the gdb devs in #gdb.

So given this line:
Code::Blocks is trying to interrupt process with pid: 21664; child pid: 0 gdb pid: 21664
CB is sending a SIGINT to gdb(pid 21664) to interrupt child(pid 0)[that does not exist] and is failing?

Why then would your gdb-7.4/7.3/7.1 work and mine does not?  I really cannot expect you to answer this question, but if you know it would help.

Quote
Do you have SELinux enabled? If you have, can you try without it?
No clue.

Quote
p.s. please post the line from gdb-6.8!
Assuming you want the gdb start-up message when running gdb-6.8, here it is:
in Debugger tab

Building to ensure sources are up-to-date
Build succeeded
Selecting target:
Debug
Adding source dir: /scratch/mccarty/Dem3D/Dem3dPre/
Adding source dir: /
Adding file: bin/Debug/Dem3dPreDebug-2012-02-17
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.8
Child process PID: 29653


As an added measure, here is what is displayed in Debugger tab when using gdb-7.4 for me.

Building to ensure sources are up-to-date
Build succeeded
Selecting target:
Debug
Adding source dir: /scratch/mccarty/Dem3D/Dem3dPre/
Adding source dir: /
Adding file: bin/Debug/Dem3dPreDebug-2012-02-17
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.4


In Debugger[debug] tab

LD_LIBRARY_PATH=.:/usr/lib:/scratch/mccarty/boost_1_35_0/libs:/opt/intel/Compiler/11.0/081/lib/intel64:/opt/intel/Compiler/11.0/081/mkl/lib/em64t:.:/philo/filesystems/maxwell/release/passage_flow/bin/LINUX/mpi/lib:/usr/lib:/usr/bin:/usr/lib/pkgconfig:/lib:/usr/local/lib/wx:/usr/local/lib:/scratch/mccarty/boost/build/lib:/usr/local/cuda/lib64
Command-line: /scratch/mccarty/gdb-6.8/build/bin/gdb -nx -fullname  -quiet -args ../debug/demppDbg
Working dir : /scratch/mccarty/dempp/trunk/
> set prompt >>>>>>cb_gdb:
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set disassembly-flavor intel
>>>>>>cb_gdb:
> source /scratch/mccarty/codeblocksSVN/trunk/build/share/codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> set backtrace limit 0

>>>>>>cb_gdb:>>>>>>cb_gdb:
> cd ../debug
>>>>>>cb_gdb:
> directory /scratch/mccarty/dempp/trunk/
>>>>>>cb_gdb:
> directory /
>>>>>>cb_gdb:
> run


And here is what is displayed in Debugger(debug) tab using gdb-7.4

LD_LIBRARY_PATH=.:/opt/intel/Compiler/11.0/081/lib/intel64:/opt/intel/Compiler/11.0/081/mkl/lib/em64t:.:/philo/filesystems/maxwell/release/passage_flow/bin/LINUX/mpi/lib:/usr/lib:/usr/bin:/usr/lib/pkgconfig:/lib:/usr/local/lib/wx:/usr/local/lib:/scratch/mccarty/boost/build/lib:/usr/local/cuda/lib64
Command-line: /scratch/mccarty/gdb-7.4/build/bin/gdb -nx -fullname  -quiet -args bin/Debug/Dem3dPreDebug-2012-02-17
Working dir : /scratch/mccarty/Dem3D/Dem3dPre/
> set prompt >>>>>>cb_gdb:
Reading symbols from /scratch/mccarty/Dem3D/Dem3dPre/bin/Debug/Dem3dPreDebug-2012-02-17...
done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set disassembly-flavor intel
>>>>>>cb_gdb:
> source /scratch/mccarty/codeblocksSVN/trunk/build/share/codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> set backtrace limit 0

>>>>>>cb_gdb:>>>>>>cb_gdb:
> directory /scratch/mccarty/Dem3D/Dem3dPre/
>>>>>>cb_gdb:
> directory /
>>>>>>cb_gdb:
> break "/scratch/mccarty/Dem3D/Dem3dPre/code/objects/model/PreprocessorModelClass.cpp:253"
Breakpoint 1 at 0x46c4a5: file /scratch/mccarty/Dem3D/Dem3dPre/code/objects/model/PreprocessorModelClass.cpp, line 253.
>>>>>>cb_gdb:
> run
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

oBFusCATed

OK, your logs are not complete, but yes I'm correct at thinking that child pid detection fails with gdb 7+ and is working correctly with gdb 6.8.

About the sigint problem, only gdb devs can tell you.
(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!]