Will, Yes, you are right, but as Spock would say, it's illogical. If the VOC pointer points to the cataloged object, Why would the cataloged object, need to point to itself?
The problem occurs on a system that doesn't have source. The application was created, and cataloged on another system, the source stripped out and the object code stripped. The application was moved to another system and we fixed the paths in the VOC and everything worked just fine, until Mr. Unassigned Variable showed up, and the debugger ate his lunch . Or anytime a DEBUG statement occurs before or after a cataloged subroutine that has an invalid path on the last line in the .O object directory. I just want to keep the DEBUGger from stepping on it's tail. (literally) Any ideas or thoughts would be cheerfully accepted. Lee Bacall http://www.binarystar.com Phone: +1 (954) 791-8575 Cell: +1 (954) 655-6581 ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 16, 2004 6:14 PM Subject: Re: [U2] Universe Debugger - compile from different path with run-timeissue > Lee stop try to confuse us. You are not stumped at all, you know exactly what the problem is. You're just trying to get around it. > > Universe puts the complete path into the object code. It's been this way since at least 198.... wait I'm not really that old dammit. > > Ok anyway, you have to DECATALOG to remove the code then recompile it. You're right that trying to byte-fix the line in the code is a bad bad idea :) IMHO! > > Will Johnson > Fast Forward > > > > > "Group- > I'm stumped, > System: Universe 10.1+ on Windows 2000 server. > Pick flavor > > Here's the problem > We're running code that was originally compiled and cataloged with the path > in UV.ACCOUNT showing: > c:\binarystar\dist\NUCLEUS > > The catalog pointer in the VOC originally pointed to > c:\binarystar\dist\NUCLEUS/SBP/SBP/CHOOSEWINDOW: > (as expected) > It ran perfectly, no problem > > We moved the object code to another system where the path in UV.ACCOUNT > shows: > D:\UV\ACCOUNTS\binarystar\NUCLEUS > Pick flavor again > > We modified the paths of all catalog pointers to change the path (line 2 and > 9 of VOC entry) from > c:\binarystar\dist\NUCLEUS/SBP/SBP/CHOOSEWINDOW: > to what is shown in UV.ACCOUNT, and it resolves to: > D:\UV\ACCOUNTS\Binarystar\NUCLEUS/SBP/SBP/CHOOSEWINDOW: > > Run the program and it worked properly, no problem > > Putting a DEBUG statement in the code of a program PRIOR to a call to the > subroutine > or, if an unassigned variable or other issue occured, the application would > fall into the debugger, and an error routine would show a pointer back to: > c:\binarystar\dist\NUCLEUS/SBP/SBP.O/CHOOSEWINDOW: > > Same situation if a DEBUG statement is encountered after a call to a > subroutine that was ORIGINALLY compiled from another path. > > After some head scratching we find that the last line of the OBJECT pointer > in the .O section of the program source file (pointing to object code), > shows > c:\binarystar\dist\NUCLEUS/SBP/SBP/CHOOSEWINDOW: > ... which isn't where the source or the object now lives. > > It apparently gets the debugger confused. > > My questions, are: > Is there a way to fix the last line of the OBJECT code? > > I don't mind creating a utility to modify the last line of the object, but I > suspect that there is at least a CRC or byte count that might throw things > off. We tried to modify the last line in the .O code pointing to the > original path, using the editor, but that does bizarre things, like multiple > paths. > > or > > Is there some feature that can be turned on (or off) to prevent DEBUG from > attempting to read the object pointer shown in the last line of the .O > entry? > > Help would be MOST appreciated > > Thanks > > Lee Bacall" > ------- > u2-users mailing list > [EMAIL PROTECTED] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
