 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / CodeWarrior / May 2004Debugging using GDB
G'day all, Running 10.3.0 on a DP 1.8GHz G5 With the Developer tools that gives an XCode version 1.1 installed. Using Codewarrior 9.2 targeting Carbon CFM creating an application bundle. I am having significant problems debugging Carbon CFM apps using Codewarrior. Often when Codewarrior hits a brake point Codewarrior will lock up, or if a debug session is ended by the application finishing Codewarrior will always lock up. If I do a "top" in the terminal I can see that /usr/libexec/gdb/gdb-powerpc-apple-darwin -n is using around 100% cpu time. If I wait long enough it occasionally seems to sort itself out. Logging out and back in doesn't help. Shutting down and restarting also doesn't help. Rebuilding the project and all sub projects from the start also doesn't help. I also seem to have some problems with the stack trace, usually when it is quite deep. I have also posted this to Apple's carbon development mailing list. Thoughts, ideas or any help would be more than appreciated. Kevin >G'day all, > [quoted text clipped - 25 lines] > >Kevin go to terminal and type gdb in and see what version you are using. I don't know of any problems such as you describe other than using an older version of GDB . Can you also verify that this happens on example projects as well as your own? Thanks, Ron  SignatureMetrowerks, one of the world¹s top 100 companies and influencers in the software development industry. - SD Times May 2004 http://www.sdtimes.com/2004sdt100.htm Metrowerks, maker of CodeWarrior Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com > go to terminal and type gdb in and see what version you are using. I > don't know of any problems such as you describe other than using an > older version of GDB . Can you also verify that this happens on > example projects as well as your own? 10.3.0 is a pretty lame version. You might want to upgrade to 10.3.3. That might be your problem. Woolie dans l'article 939cc6ed.0405200105.f7af522@posting.google.com, Kevin Meaney à kevin@softpress.com a écrit le 20/05/04 11:05 : > G'day all, > [quoted text clipped - 23 lines] > > Thoughts, ideas or any help would be more than appreciated. I've been through this problem too when quitting the debugged app. It seems to happen when there are memory leaks, or memory cleanup errors. Once I solved those problems in my code, it went back to normal. Eric Kevin, I posted a SIMILAR problem I was having with 10.3.3, CW 9.2 targeting Carbon CFM, and a DP 1.8GHz G5. Like your problem, NOTHING helped. Seems to come and go, but sometimes the debugger is fine UNTIL I try to open and view a class's data members in the "Variables:All" list. (for example, an LView*). I was just able to reproduce it, so this bug hasn't gone away. In my case, I could hear the G5 fans kick into high gear, and I could see that 100% of the CPU was being used by the debugger. Also, I saw that memory was being allocated continually. I usually have to FORCE QUIT the environment. I hope you figure it out -- if you do, please post what you find here. I will, too. Best Regards, Stephen Greenfield Write Brothers, Inc. "Kevin Meaney" <kevin@softpress.com> wrote in message: > Running 10.3.0 on a DP 1.8GHz G5 > [quoted text clipped - 17 lines] > I also seem to have some problems with the stack trace, usually when > it is quite deep. Can you submit this as a bug report to support@metrowerks.com and copy me when you do and I'll try to follow up on it there. Ron >I posted a SIMILAR problem I was having with 10.3.3, CW 9.2 targeting Carbon >CFM, and a DP 1.8GHz G5. [quoted text clipped - 41 lines] >> I also seem to have some problems with the stack trace, usually when >> it is quite deep. SignatureMetrowerks, one of the world¹s top 100 companies and influencers in the software development industry. - SD Times May 2004 http://www.sdtimes.com/2004sdt100.htm Metrowerks, maker of CodeWarrior Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com >I posted a SIMILAR problem I was having with 10.3.3, CW 9.2 targeting Carbon >CFM, and a DP 1.8GHz G5. [quoted text clipped - 12 lines] >I hope you figure it out -- if you do, please post what you find here. I >will, too. Thanks for submitting this. It triggered a response from engineering. I knew it too, but I had just forgotten and not associated the problem and the reason. If this isn't the problem we'll look some more into it. Ron SignatureMetrowerks, one of the world¹s top 100 companies and influencers in the software development industry. - SD Times May 2004 http://www.sdtimes.com/2004sdt100.htm Metrowerks, maker of CodeWarrior Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com > G'day all, > [quoted text clipped - 3 lines] > Using Codewarrior 9.2 targeting Carbon CFM creating an application > bundle. [...] > Thoughts, ideas or any help would be more than appreciated. Try the following: Go to terminal.app, do an Œps -xŒ to find the PID of gdb, then Œsudo kill {GDB-PID}Œ At least with Jaguar / CW 8.3 this helped pretty often. Feedback appreciated. HTH, Tom_E SignatureThis address is valid in its unmodified form but expires soon. > Go to terminal.app, do an Œps -xŒ to find the PID of gdb, then Œsudo > kill {GDB-PID}Œ FWIW, "killall gdb" is a simpler way to kill all instances of gdb. meeroh SignatureIf this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist> > > Go to terminal.app, do an Œps -xŒ to find the PID of gdb, then Œsudo > > kill {GDB-PID}Œ > > FWIW, "killall gdb" is a simpler way to kill all instances of gdb. It normally would be, but gdb's process name is actually "gdb-powerpc-apple-darwin" rather than "gdb". :) -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://rescomp.stanford.edu/~ejalbert/ > > FWIW, "killall gdb" is a simpler way to kill all instances of gdb. > > It normally would be, but gdb's process name is actually > "gdb-powerpc-apple-darwin" rather than "gdb". :) killall -m gdb, then meeroh SignatureIf this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist> > Try the following: > Go to terminal.app, do an ps -x to find the PID of gdb, then sudo > kill {GDB-PID} > At least with Jaguar / CW 8.3 this helped pretty often. Feedback > appreciated. I thought I'd try this in my case, but gdb wasn't even a running process... Stephen > > Try the following: > > Go to terminal.app, do an ps -x to find the PID of gdb, then sudo [quoted text clipped - 3 lines] > > I thought I'd try this in my case, but gdb wasn't even a running process... Sure? Without launching GDB, CW will not debug any OS X executable, so it must be running under the hood. Two things give you the SBOD, either CW does not realize GDB is quit (then you are right, GDB is not running - any more - ) or there is an communiction problem between the IDE's debugger plugin and GDB (so the debugger plugin waits indefinite for something GDB will not send or vice versa). Regards, Tom_E SignatureThis address is valid in its unmodified form but expires soon. >G'day all, > [quoted text clipped - 23 lines] > >Thoughts, ideas or any help would be more than appreciated. We think we figured this out... It is our bug... If you have Break On C++ Exception turned on, and anytime you set/clear a breakpoint, stop/start a debugging session, the IDE tries to find one of the runtime library source files. Since they are kept in a shielded folder, it wants to search for it every time because it didn't find it previously. The two options to get around this for now are to either keep that setting off, or to add an access path to {Compiler}MacOS X Support/Libraries/Runtime/(Source). Ron SignatureMetrowerks, one of the world¹s top 100 companies and influencers in the software development industry. - SD Times May 2004 http://www.sdtimes.com/2004sdt100.htm Metrowerks, maker of CodeWarrior Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com > We think we figured this out... It is our bug... If you have Break On > C++ Exception turned on, and anytime you set/clear a breakpoint, [quoted text clipped - 5 lines] > either keep that setting off, or to add an access path to > {Compiler}MacOS X Support/Libraries/Runtime/(Source). Thanks Ron, but I don't have "Break on C++ Exception" turned on, and if you look at the snapshot of my Access Paths, I already have {compiler}MacOS Support in the System Paths. Doesn't the little folder picture or checkmark mean that the folder will be searched recursively? Stephen >Thanks Ron, but I don't have "Break on C++ Exception" turned on, and if you >look at the snapshot of my Access Paths, I already have {compiler}MacOS >Support in the System Paths. Doesn't the little folder picture or >checkmark mean that the folder will be searched recursively? yes but the parenthesis around a folder hide it from the search Ron SignatureMetrowerks, one of the world¹s top 100 companies and influencers in the software development industry. - SD Times May 2004 http://www.sdtimes.com/2004sdt100.htm Metrowerks, maker of CodeWarrior Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.