Using CodeWarrior 8.3 to debug a plug-in fails

Using CodeWarrior 8.3 to debug a plug-in fails

Post by Carl Hayni » Fri, 03 Jan 2003 11:15:19



I'm a newbie to CW trying to debug an Adobe FrameMaker plug-in I wrote.  I
am probably missing something basic.  I have v5.1.1 (v8.3) of the CW IDE
installed running under Mac OS 9.2.2.  FrameMaker is the executable and my
API client (plug-in) resides in the Modules folder.

I am having very little luck getting CW to honor breakpoints I set in my
plug-in code.  At best, it does seem to hit a breakpoint but there appears
to be some disconnect between what shows in the disassembly/source pane and
where the program actually is stopped.  At worst, it simply runs thru my
plug-in logic without breaking.  I can see my symbol and source code data
fine in CW's Symbol Window and see my breakpoints, etc.

Steps taken:

1) Select source code files in project window, bring up Project Inspector,
Enable Debug Info for all files in Attributes tab, Save.
2) Edit project settings: goto PPC Linker page to enable Generate SYM file,
PPC Disassembler page to enable Show SYM Info, Save.
3) Build the plug-in, move the API module to the Modules folder.
4) Double-click the <project>.xSym file.  At the "Where is the executable
for <project>.xSYM" prompt, I locate the FrameMaker executable and click
Open.  (Should you choose the API client here instead??)
5) Symbolics Window comes up showing FrameMaker 7.0 exe in top left pane, my
source code files in middle pane, and my routines in the right pane.  I then
set a breakpoint in a routine of mine, at a point I know the code goes
through.
6) Hit the Go button in the top left corner of the Symbolics Window.
7) FrameMaker starts up and either one of two things happen:
(a) Program runs past all breakpoints
(b) Program breaks early but the source code view / stepping does not jive
with reality.

--
Carl Haynie

 
 
 

Using CodeWarrior 8.3 to debug a plug-in fails

Post by Nigel Redmo » Sat, 04 Jan 2003 09:48:46


It's not you, if that makes you feel any better. (See my thread "CW
8.2 problems debugging plug-ins"--same story in 8.3.)
Quote:> I'm a newbie to CW trying to debug an Adobe FrameMaker plug-in I wrote.  I
> am probably missing something basic.  I have v5.1.1 (v8.3) of the CW IDE
> installed running under Mac OS 9.2.2.  FrameMaker is the executable and my
> API client (plug-in) resides in the Modules folder.

> I am having very little luck getting CW to honor breakpoints I set in my
> plug-in code.  At best, it does seem to hit a breakpoint but there appears
> to be some disconnect between what shows in the disassembly/source pane and
> where the program actually is stopped.  At worst, it simply runs thru my
> plug-in logic without breaking.  I can see my symbol and source code data
> fine in CW's Symbol Window and see my breakpoints, etc.

> Steps taken:

> 1) Select source code files in project window, bring up Project Inspector,
> Enable Debug Info for all files in Attributes tab, Save.
> 2) Edit project settings: goto PPC Linker page to enable Generate SYM file,
> PPC Disassembler page to enable Show SYM Info, Save.
> 3) Build the plug-in, move the API module to the Modules folder.
> 4) Double-click the <project>.xSym file.  At the "Where is the executable
> for <project>.xSYM" prompt, I locate the FrameMaker executable and click
> Open.  (Should you choose the API client here instead??)
> 5) Symbolics Window comes up showing FrameMaker 7.0 exe in top left pane, my
> source code files in middle pane, and my routines in the right pane.  I then
> set a breakpoint in a routine of mine, at a point I know the code goes
> through.
> 6) Hit the Go button in the top left corner of the Symbolics Window.
> 7) FrameMaker starts up and either one of two things happen:
> (a) Program runs past all breakpoints
> (b) Program breaks early but the source code view / stepping does not jive
> with reality.

> --
> Carl Haynie


 
 
 

Using CodeWarrior 8.3 to debug a plug-in fails

Post by MW Ro » Sat, 04 Jan 2003 13:02:55




This looks like you have inlining on or optimization  

While there is also a limit to the number of debug symbols you can have.  
It shouldn't be a factor in a plugin.

Are you sure you are using the right runtime library and such.    Do you
have any example projects?

Ron

Quote:>I'm a newbie to CW trying to debug an Adobe FrameMaker plug-in I wrote.  I
>am probably missing something basic.  I have v5.1.1 (v8.3) of the CW IDE
>installed running under Mac OS 9.2.2.  FrameMaker is the executable and my
>API client (plug-in) resides in the Modules folder.

>I am having very little luck getting CW to honor breakpoints I set in my
>plug-in code.  At best, it does seem to hit a breakpoint but there appears
>to be some disconnect between what shows in the disassembly/source pane and
>where the program actually is stopped.  At worst, it simply runs thru my
>plug-in logic without breaking.  I can see my symbol and source code data
>fine in CW's Symbol Window and see my breakpoints, etc.

>Steps taken:

>1) Select source code files in project window, bring up Project Inspector,
>Enable Debug Info for all files in Attributes tab, Save.
>2) Edit project settings: goto PPC Linker page to enable Generate SYM file,
>PPC Disassembler page to enable Show SYM Info, Save.
>3) Build the plug-in, move the API module to the Modules folder.
>4) Double-click the <project>.xSym file.  At the "Where is the executable
>for <project>.xSYM" prompt, I locate the FrameMaker executable and click
>Open.  (Should you choose the API client here instead??)
>5) Symbolics Window comes up showing FrameMaker 7.0 exe in top left pane, my
>source code files in middle pane, and my routines in the right pane.  I then
>set a breakpoint in a routine of mine, at a point I know the code goes
>through.
>6) Hit the Go button in the top left corner of the Symbolics Window.
>7) FrameMaker starts up and either one of two things happen:
>(a) Program runs past all breakpoints
>(b) Program breaks early but the source code view / stepping does not jive
>with reality.

>--
>Carl Haynie

--
     Free Programming Courses at CodeWarrior U
          <http://www.codewarrioru.com>

 Metrowerks, maker of CodeWarrior  -  "Software Starts Here"  

 
 
 

Using CodeWarrior 8.3 to debug a plug-in fails

Post by MW Ro » Sat, 04 Jan 2003 13:03:33




Quote:>It's not you, if that makes you feel any better. (See my thread "CW
>8.2 problems debugging plug-ins"--same story in 8.3.)

Send me more information on this,  I don't see your thread, was it in
this newsgroup?

Ron

--
     Free Programming Courses at CodeWarrior U
          <http://www.codewarrioru.com>

 Metrowerks, maker of CodeWarrior  -  "Software Starts Here"  

 
 
 

Using CodeWarrior 8.3 to debug a plug-in fails

Post by Nigel Redmo » Sat, 04 Jan 2003 18:03:43


Yes, you responded to it. The correct thread title has "problem" (no
"problems").


Quote:>> It's not you, if that makes you feel any better. (See my thread "CW
>>8.2 problems debugging plug-ins"--same story in 8.3.)

> Send me more information on this,  I don't see your thread, was it in
> this newsgroup?

> Ron

 
 
 

Using CodeWarrior 8.3 to debug a plug-in fails

Post by Thomas Engelmeie » Sat, 04 Jan 2003 22:08:04




Quote:> It's not you, if that makes you feel any better. (See my thread "CW
> 8.2 problems debugging plug-ins"--same story in 8.3.)

> > I'm a newbie to CW trying to debug an Adobe FrameMaker plug-in I wrote.  I
> > am probably missing something basic.  I have v5.1.1 (v8.3) of the CW IDE
> > installed running under Mac OS 9.2.2.  FrameMaker is the executable and my
> > API client (plug-in) resides in the Modules folder.

I couldn't get reliable debugging on my machine for Shared Libraries
since Pro1.
Debugging problems might correlate with coding habits.
At work, a colleague had close to no problems ever to debug his Quark
XTensions. With my XTensions, OTOH, the de* nearly always failed to
do its work.
IIRC, I tried my XTension on his setup (failing) and one of his
XTensions on my machine (working).

One of the differences was I used the C++ Standard Lib and C++
excessive, his XTensions were mostly C.

If my memory serves me right,
- for me it worked more reliable if the IDE was fresh started
- after some time something went Havoc when I was debugging and my
XTension crashed hard in locations where there wasn't even an codepath
to.
- When something went wrong, the de* often didn't manage to
correlate the location in memory to the source file  
- There seemed to be no difference between setting the destination path
of the IDE to the XTension directory and manually copying the ShLib /
.xSym and opening it.

Regards,
       Tom_E

--
This address doesn't need demangling but will expire soon.

By sending unsolicited bulk mails (UBE, Spam) to this address you agree
to pay me not less than $200 processing fee for canceling your accounts

 
 
 

Using CodeWarrior 8.3 to debug a plug-in fails

Post by MW Ro » Sun, 05 Jan 2003 02:40:53




Quote:

>I couldn't get reliable debugging on my machine for Shared Libraries
>since Pro1.
>Debugging problems might correlate with coding habits.
>At work, a colleague had close to no problems ever to debug his Quark
>XTensions. With my XTensions, OTOH, the de* nearly always failed to
>do its work.
>IIRC, I tried my XTension on his setup (failing) and one of his
>XTensions on my machine (working).

Weird very weird

Quote:>One of the differences was I used the C++ Standard Lib and C++
>excessive, his XTensions were mostly C.

I can see where using the STL might be problematic.

Quote:>If my memory serves me right,
>- for me it worked more reliable if the IDE was fresh started
>- after some time something went Havoc when I was debugging and my
>XTension crashed hard in locations where there wasn't even an codepath
>to.
>- When something went wrong, the de* often didn't manage to
>correlate the location in memory to the source file  
>- There seemed to be no difference between setting the destination path
>of the IDE to the XTension directory and manually copying the ShLib /
>.xSym and opening it.

If they get out of sync in someway that would make sense.  I've seen it
use the wrong files even if they were trashed...

Ron

--
     Free Programming Courses at CodeWarrior U
          <http://www.veryComputer.com/>

 Metrowerks, maker of CodeWarrior  -  "Software Starts Here"  

 
 
 

Using CodeWarrior 8.3 to debug a plug-in fails

Post by MW Ro » Sun, 05 Jan 2003 02:45:47




Quote:>Yes, you responded to it. The correct thread title has "problem" (no
>"problems").

I found it yes.  Something occurred to me when answering Thomas,  
sometimes the de* will associate with the wrong file so the
breakpoints for that file and stuff aren't in the right location.  This
happens with backups sometimes on OS X (I think it really is an OS
error)  anyway I was wondering if that could be the problem.  Do you
have any other files with the same names on your Hard Drive  (even in
the trash).   Did you replace the file by renaming it and putting a new
file in instead, sometimes they will even stick with a new name.  

Something to consider.  Finally OS X debugging is not the same as OS 9  
you have to use different techniques,  drag the shared library xsym and
open it etc  and have your settings right, but I'd suspect you have them
right as it debugs sometimes just doesn't hit the breakpoints.

Ron

--
     Free Programming Courses at CodeWarrior U
          <http://www.veryComputer.com/>

 Metrowerks, maker of CodeWarrior  -  "Software Starts Here"  

 
 
 

Using CodeWarrior 8.3 to debug a plug-in fails

Post by Thomas Engelmeie » Sun, 05 Jan 2003 06:37:36


Quote:> If they get out of sync in someway that would make sense.  I've seen it
> use the wrong files even if they were trashed...

There is one de* related file caching issue lurking:
If you open an project, debug it, kill the app to be debugged during
debugging and back in non-debug mode close the project, some files of
the project remain opened. The attempt to reopen the project will give
an error message.

This is an IDE on another volume with no more file open, after an killed
debug run:

[mac:~] user% fstat -p 550 | grep /Development
user      LaunchCFMA   550   25   158372 -rw-r--r--   158976 rw  
/Volumes/Development
user      LaunchCFMA   550   38   179424 -rw-r--r--     4666 rw  
/Volumes/Development
user      LaunchCFMA   550   41   179428 -rw-r--r--  6492943 rw  
/Volumes/Development

IIRC, one instance of the usage of an wrong file is easy to reproduce in
Pro8 on OS X, but has nothing to do with the de*:

- Open an project with one header in the wrong directory.
- Compile it (not sure if necessary)
- go to the Finder, place a new header with the same name in another
directory in the project search path.
- From the finder, move the wrong header to the trash.
- Compile in the IDE. the wrong header usually will be used instead of
the new header. If the trash is emptied, an empty file will be created
in the old headers location.

Regards,
        Tom_E

--
This address doesn't need demangling but will expire soon.

By sending unsolicited bulk mails (UBE, Spam) to this address you agree
to pay me not less than $200 processing fee for canceling your accounts

 
 
 

Using CodeWarrior 8.3 to debug a plug-in fails

Post by MW Ro » Sun, 05 Jan 2003 23:53:47




Quote:>> If they get out of sync in someway that would make sense.  I've seen it
>> use the wrong files even if they were trashed...

Thanks I'll pass these on to support and QA

Ron

Quote:>There is one de* related file caching issue lurking:
>If you open an project, debug it, kill the app to be debugged during
>debugging and back in non-debug mode close the project, some files of
>the project remain opened. The attempt to reopen the project will give
>an error message.

>This is an IDE on another volume with no more file open, after an killed
>debug run:

>[mac:~] user% fstat -p 550 | grep /Development
>user      LaunchCFMA   550   25   158372 -rw-r--r--   158976 rw  
>/Volumes/Development
>user      LaunchCFMA   550   38   179424 -rw-r--r--     4666 rw  
>/Volumes/Development
>user      LaunchCFMA   550   41   179428 -rw-r--r--  6492943 rw  
>/Volumes/Development

>IIRC, one instance of the usage of an wrong file is easy to reproduce in
>Pro8 on OS X, but has nothing to do with the de*:

>- Open an project with one header in the wrong directory.
>- Compile it (not sure if necessary)
>- go to the Finder, place a new header with the same name in another
>directory in the project search path.
>- From the finder, move the wrong header to the trash.
>- Compile in the IDE. the wrong header usually will be used instead of
>the new header. If the trash is emptied, an empty file will be created
>in the old headers location.

>Regards,
>        Tom_E

--
     Free Programming Courses at CodeWarrior U
          <http://www.veryComputer.com/>

 Metrowerks, maker of CodeWarrior  -  "Software Starts Here"  

 
 
 

Using CodeWarrior 8.3 to debug a plug-in fails

Post by Thomas Engelmeie » Mon, 06 Jan 2003 05:41:41






> >> If they get out of sync in someway that would make sense.  I've seen it
> >> use the wrong files even if they were trashed...

> Thanks I'll pass these on to support and QA

Fine. I didn't have the time to pin them down and write reports before
(and still have a bunch of Carbon related API issues to workaround /
investigate).

         Tom_E

--
This address doesn't need demangling but will expire soon.

By sending unsolicited bulk mails (UBE, Spam) to this address you agree
to pay me not less than $200 processing fee for canceling your accounts

 
 
 

1. Updating CodeWarrior 8.3 to compile for QuickTime 6

Hi,

I'm trying to update my CodeWarrior for Mac 8.3 install to compile against
QuickTime 6 for Carbon and PPC builds.  I've downloaded the latest Universal
Interfaces from Apple (3.4.2) (which claim to support QT6), and put these in
the right place, but still no luck.  What do I need to do?

Thanks in advance,

Dave.

2. Random generation of numbers

3. Codewarrior 8.3 unexpectedly quits

4. ACK flood during browsing

5. ProjectBuilder Prjcts to CodeWarrior 8.3 (?)

6. The Future

7. CodeWarrior v 8.3 update for Macintosh

8. CodeWarrior for Palm 8.3 Patch Available.

9. Codewarrior 8.3 patch

10. Codewarrior 8.3 unexpectedly quits

11. CodeWarrior for Palm OS 8.3 Update

12. OpenGL in Codewarrior 8.3 - outdated?