Debugger_Replacement (OpenInsight 32-Bit)
At 04 JUN 2009 03:27:07PM Jim Vaughan wrote:
I use a Debugger_Replacement (see code below). If the code is called using my development oengine.dll it works correctly. I tested by adding a debug line to code.
If run when using my run time oengine.dll; OI aborts with an out of memory message.
Using OI 9
Any ideas?
Function [/color]Debugger_Replacement(void) [/color]****************************************************************************** * * This program is proprietary and is provided as is, with no warranty given or implied * * Name : Test_Debugger * Description: This procedure implements shows an example of a way * to intercept the debugger, yet still report on errors. * See Also : RTI_Debug_Common * * History : (date, initials, notes) * 3-23-05 MTR Rolled In 7.1.1 * 5-12-05 mtr Updated SPStatCode * visim jrv 7-3-06 * customized for Tactic ****************************************************************************** [/color]Declare Function [/color]Msg, Pit, Get.Msgx, Dialog_Box, Start_Window, MessageBoxA, Get_Property [/color]Equ [/color]CRLF$ [/color]to [/color]\0D0A\ [/color] [/color]$Insert [/color]RTI_Debug_Common [/color]* common /rti_debug_common/ SPStatus@, SPStatCode@, Curr_Program@, CallDepth@, LineNo@, CallStack@ [/color] [/color]OSRead [/color]Error_txt [/color]from [/color]"Error.txt" [/color]Else [/color]Error.txt=[/color]"" [/color] [/color]Error_txt1][/color]= [/color]"___________________________________________________________" [/color]Error_txt1] [/color]= Pit(DATE()*[/color]1440 [/color]+ INT(TIME()/[/color]60[/color]),[/color]"PCDT"[/color]) Error_txt1][/color]= [/color]" " [/color]Error_txt1] [/color]= Curr_Program@:[/color]" line number "[/color]:LineNo@ Error_txt1][/color]= [/color]" " [/color]Error_txt1] [/color]= [/color]"Call Stack " [/color]CallStack=CallStack@ [/color] [/color]Swap @FM with [/color]CRLF$ [/color]in [/color]CallStack [/color]Swap @VM with [/color]" line number: " [/color]in [/color]CallStack Error_txt1] [/color]= CallStack Error_txt1][/color]= [/color]"___________________________________________________________" [/color] [/color]Swap @FM with [/color]CRLF$ [/color]in [/color]Error_txt [/color] [/color]OSWrite [/color]Error_txt [/color]to [/color]"Error.txt" [/color]OSClose [/color]Error_txt [/color]* visim jrv 7-16-07 [/color] [/color]TextMsg=[/color]"An error has occurred on line "[/color]:LineNo@:[/color]" in program "[/color]:Curr_Program@:[/color]"; the file 'Error.txt' in the install directory contains more information."[/color]:[/color]\00\ [/color]* display error outside of crash, wait for engine to be idle [/color]Call [/color]Set_Property([/color]"SYSTEM"[/color], [/color]"IDLEPROC"[/color], [/color]"REPORT_DBG_ERROR"[/color]:[/color]@FM[/color]:TextMsg) [/color] [/color]* end visim jrv 7-16-07 [/color]Return [/color]1[/color][/color][/size]
At 04 JUN 2009 03:28PM Jim Vaughan wrote:
The code got mangled somehow (this is the same code as pure text)
Function Debugger_Replacement(void)
* * This program is proprietary and is provided as is, with no warranty given or implied * * Name : Test_Debugger * Description: This procedure implements shows an example of a way * to intercept the debugger, yet still report on errors. * See Also : RTI_Debug_Common * * History : (date, initials, notes) * 3-23-05 MTR Rolled In 7.1.1 * 5-12-05 mtr Updated SPStatCode * visim jrv 7-3-06 * customized for Tactic
Declare Function Msg, Pit, Get.Msgx, Dialog_Box, Start_Window, MessageBoxA, Get_Property
Equ CRLF$ to \0D0A\
$Insert RTI_Debug_Common
* common /rti_debug_common/ SPStatus@, SPStatCode@, Curr_Program@, CallDepth@, LineNo@, CallStack@
OSRead Error_txt from "Error.txt" Else Error.txt="
Error_txt= "_" Error_txt=Pit(DATE()*1440 + INT(TIME()/60),"PCDT") Error_txt= " " Error_txt=Curr_Program@:" line number ":LineNo@ Error_txt= " " Error_txt=Call Stack " CallStack=CallStack@ Swap @FM with CRLF$ in CallStack Swap @VM with " line number: " in CallStack Error_txt=CallStack Error_txt= "_"
Swap @FM with CRLF$ in Error_txt
OSWrite Error_txt to "Error.txt"
OSClose Error_txt
* visim jrv 7-16-07
TextMsg=An error has occurred on line ":LineNo@:" in program ":Curr_Program@:"; the file 'Error.txt' in the install directory contains more information.":\00\
* display error outside of crash, wait for engine to be idle
Call Set_Property("SYSTEM", "IDLEPROC", "REPORT_DBG_ERROR":@FM:TextMsg)
* end visim jrv 7-16-07
Return 1
At 04 JUN 2009 03:48PM [email protected]'s Don Bakke wrote:
Jim,
The code in the original post looked fine to me.
What happens if you comment out the IDLEPROC property setting? That's the only thing that looks questionable to me. Perhaps it is something in the routine that it calls.
At 04 JUN 2009 03:52PM Jim Vaughan wrote:
If you look half way down the code that adds to Error_txt (see below) something is wrong with the pasted code. This was from your editor btw.
Error_txt= "___"
Error_txt=Pit(DATE()*1440 + INT(TIME()/60),"PCDT")
Error_txt= " "
Error_txt=Curr_Program@:" line number ":LineNo@
Error_txt= " "
Error_txt=Call Stack "
CallStack=CallStack@
At 04 JUN 2009 03:56PM Jim Vaughan wrote:
Same error still occurs if IDLEPROC setting is commented out.
At 04 JUN 2009 04:14PM [email protected]'s Don Bakke wrote:
Hmmm…well since the program isn't that long I would try commenting out everything and then start adding sections of code back in to see if you can isolate the offending code. I know you were hoping for a quick catch but I'm not seeing it.
At 04 JUN 2009 04:33PM Jim Vaughan wrote:
What is strange is
(a) This used to work
(b) It only fails when using the run time engine.
At 04 JUN 2009 04:38PM Jim Vaughan wrote:
If I insert a return at the beginning of the function, essentially commenting out all of the code.
It still fails in the same way when run with the run time engine.
Unless I am missing something, something is broken in OI (or my runtime engine).
At 04 JUN 2009 04:53PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Jim,
No idea if this is related to the problem but you shouldn't be OSClose'ing the file unless you actually opened it. OSRead, OSWrite and OSDelete all handle open and closing the file handle internally - you only need OSOpen and OSClose if you're going to be using OSBRead and OSBWrite (or unless you want to "lock" the OS file to stop another process playing with it).
Anything interesting happening in the Pit() function call? If OI reports an "Out Of Memory" error it could have gone recursive - is their any chance that running this under the runtime engine could force it into a debug situation again while in the debugger (there are safeguards against this but you never know…)
World leaders in all things RevSoft
At 04 JUN 2009 05:04PM Jim Vaughan wrote:
The error occurs if none of the code is run, I inserted a RETURN as the first line of the function and it still fails.
At 04 JUN 2009 05:07PM Jim Vaughan wrote:
In summary:
(1) Error only occurs when using run time engine
(2) Occurs when Debugger_Replacement is called (even if Debugger_Replacement is nothing more than a straight return)
(3) Can reproduce it at will by placing a debug statement in my applications code.
At 04 JUN 2009 05:38PM [email protected]'s Don Bakke wrote:
What happens if you force a runtime error to occur rather than placing a DEBUG statement in your code?
At 04 JUN 2009 05:44PM Jim Vaughan wrote:
Added following code to a portion of my software
If x=1 then
End
x is undefined.
Using the development Engine I get a pop up indicating an error has occurred. Which is what I want to happen.
Using the runtime Engine I get an out of memory error.
At 04 JUN 2009 05:50PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Jim,
So the *same* system with the Dev engine DLL works fine, but replace it with the Runtime engine DLL it dies?
Does OEProfile.log give you any clues as to what is happening? (e.g. where does it stop and can you see any recursion?)
If not I'd contact RTI direct to sort this one out - if your engine dies without calling any code then it's unlikely to be something you're doing wrong - I'd try and get a replacement engine file, as the only difference between the engine DLLs is the stamp. The internal engine C code is exactly the same.
World leaders in all things RevSoft
At 04 JUN 2009 06:03PM Jim Vaughan wrote:
]] So the *same* system with the Dev engine DLL works fine, but replace it with the Runtime engine DLL it dies? ] Does OEProfile.log give you any clues as to what is happening? «
The is log from the point that the error occurs:
RTP27 13822
GETOISTATE 13822GETOISTATE 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0REPOS_BFS 13822RTP57A 13822RTP57A 13822 0RTP90 13822RTP90 13822 0REPOS_BFS 13822 0RTP27 13822 0
DEBUGGER 13822
RTP27 13822GETOISTATE 13822GETOISTATE 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0REPOS_BFS 13822RTP57A 13822RTP57A 13822 0RTP90 13822RTP90 13822 0REPOS_BFS 13822 0RTP27 13822 0GETSESSIONCALLSTACK 13822GETSESSIONCALLSTACK 13822 0RTP27 13822GETOISTATE 13822GETOISTATE 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0REPOS_BFS 13822RTP57A 13822RTP57A 13822 0RTP90 13822RTP90 13822 0REPOS_BFS 13822 0RTP27 13822 0DEBUGGER_FETCH 13822RTP27 13822GETOISTATE 13822GETOISTATE 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0REPOS_BFS 13822RTP57A 13822RTP57A 13822 0RTP90 13822RTP90 13822 0REPOS_BFS 13822 0RTP27 13822 0GETBREAKFRAME 13822GETBREAKFRAME 13822 0RTP27 13822GETOISTATE 13822GETOISTATE 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0REPOS_BFS 13822RTP57A 13822RTP57A 13822 0RTP90 13822RTP90 13822 0REPOS_BFS 13822 0RTP27 13822 0REV_LOADREC 13822RTP9 13822RTP9 13822 0RTP57 13822RTP57A 13822RTP57A 13822 0RTP57 13822 0REV_LOADREC 13822 0DEBUGGER_FETCH 13838 16
At 04 JUN 2009 06:07PM [email protected]'s Don Bakke wrote:
Jim,
Can you send me both of your engines? I'd like to work with them in our lab.
At 04 JUN 2009 06:27PM Jim Vaughan wrote:
just emailed you a copy of both engines.
At 04 JUN 2009 06:28PM Jim Vaughan wrote:
If the DLLs are the same then why do mine look like this:
1/12/2009 17:50 376,832 OENGINE.dev
1/12/2009 17:50 278,528 OENGINE.run
Something isn't correct?
At 04 JUN 2009 06:56PM [email protected]'s Don Bakke wrote:
Jim,
That size implies that the runtime engine is still at version 8.0.x.
At 04 JUN 2009 07:11PM Jim Vaughan wrote:
The runtime is indeed a version 8.0 DLL; which is obviously the source of the problem. I was under the mistaken belief that upgrading OI updated both the OENGINE.DLL and the OENGINE.RUN.
So I need to upgrade the runtime engine, for this I need a code (from Revelation) correct?
In the future when I upgrade OI do I therefore need two codes each time one for the dev engine and then one for the runtime engine?
Why does the 8.0 engine even work, I would have thought that OI would not allow this to work at all.
How do I get a code to upgrade a run time? Same way as for other upgrades?
My runtime engine is also showing 6 users, I assume this is not correct.
What should I do next?
At 04 JUN 2009 08:14PM [email protected]'s Don Bakke wrote:
Jim,
I assume you already have my email response but for the sake of others reading this thread…
The runtime is indeed a version 8.0 DLL; which is obviously the source of the problem. I was under the mistaken belief that upgrading OI updated both the OENGINE.DLL and the OENGINE.RUN.
No, that doesn't happen. In fact, OENGINE.run hasn't been automatically upgraded since the authorization system was put in place.
So I need to upgrade the runtime engine, for this I need a code (from Revelation) correct?
Correct.
In the future when I upgrade OI do I therefore need two codes each time one for the dev engine and then one for the runtime engine?
Correct.
Why does the 8.0 engine even work, I would have thought that OI would not allow this to work at all.
I have never known OI to do a version check on the engine. In some cases different versions just happen to work fine…presumably the code base is the same or similar in those cases. Many times an upgrade to OpenInsight doesn't necessarily change anything in the oengine other than the version number.
How do I get a code to upgrade a run time? Same way as for other upgrades?
If you go into the Works Downloads section and go through any of the 8.0.2 or higher upgrade pages you'll be provided a link to a page where you can request an authorization code. There appears to be a different page for each version of OI, but I've found that they all work the same so I just bookmark one of them.
My runtime engine is also showing 6 users, I assume this is not correct.
It would appear that you accidentally replaced your 1-user runtime with a client's 6-user runtime.
What should I do next?
I know you already sent an email to Revelation for a new 1-user runtime so that's probably going to solve your problem first. Otherwise, I would suggest looking through some backup copies you might have.
At 04 JUN 2009 09:10PM Jim Vaughan wrote:
Don,
]] It would appear that you accidentally replaced your 1-user runtime with a client's 6-user runtime. «
Or in other words this whole process is so freaking confusing and time consuming that I appear to have fu#$ed it up again.
BTW I just did some searching through old emails, and you and I discovered this problem late last year. In the process of purchasing a 5 user SDP we found out that my OENGINE.DLL (runtime) was set to 6 users. The upgraded enegine ended up with 11 users. I managed to get that corrected for the customer (he has the correct number of users) and forgot about my runtime engine problem.
I have looked through old backups and do not seem to have a backup of the runtime OENGINE.DLL with the correct serial number and a single user (Revelation changed my serial number a while back). I have copies with older serial numbers and one user, all the new serial number ones have six users.
Will someone from Revelation please contact me so we can correct this? 310-944-3716 or my cell 310-951-3677.
Thanks for the help guys.
At 05 JUN 2009 09:17AM Jared Bratu wrote:
I will contact you regarding this Friday morning. Thank you.
At 05 JUN 2009 01:30PM Jim Vaughan wrote:
I just received from Revelation an oengine.dll version 9.0 single user with my serial number.
The problem with the debugger replacement no longer occurs.
Many thanks to Don and Sprezzatura for helping me track down the source of this problem.