I've been using IAR embedded workbench for quite some time but there is still one thing I'm unable to wrap my head around. And that's the inconsistency of the breakpoint operation.
I have a quite big project which runs an RTOS (might this affect the problem?) and when I place a breakpoint there is no guarantee the debugger will stop at this breakpoint. Sometimes it does, sometimes it doesn't.
A workaround I found is manually stopping the processor and placing the breakpoint while the processor is paused. But even this has not a 100% success rate.
I'm generating debug information and I'm running in debug mode
Anyone had similar issues or anyone with some ideas?
Try to reduce number of breakpoints that you use (possibly just keep this one that causes problem), also you could use a “Log” breakpoint in order to print a message in the Debug Log window instead of stopping at that point (you may also want to try a different point in the same section of the code). If they don't help, I could say with a high degree of certainty that the debugger does not stop at the breakpoint because it simply does not hit it, and you do not enter that block of code. Consider that in an embedded project (especially when using an RTOS) some conditions are met only at the beginning or upon certain requests in certain conditions so you might want to figure out when the breakpoint is actually hit what conditions were met and what is the new state now.
Related
We are using Progress OpenEdge 10.2A for years and for the last 4 months we begin to receive unknown error messages from our customers.
We call our .w files using lines as follows:
RUN VALUE(myPath + "myProgram.r") PERSISTENT SET myPrograms[i].
Normally the same program calls work without any problem, but on rare occasions, the program window seems to get unresponsive, but in fact when we look at the windows taskbar, there is another entry in the taskbar which is a prowin32.exe window having title "Error". But when selected, there seems to have no visible window attached to it.
When we close it from the taskbar using Close Window option, it appears again in the taskbar 6-7 times again and then whole prowin32 session restarts.
We could not identify the error since it does not show any message or any error number.
If you encounter such a problem, I'd like to know how you solved it.
If not, it would be appreciated if you direct me to the way to solve the problem.
Edit 1:
After adding -errorstack -debugalert -clientlog myLogFile.log to my startup parameters, myLogFile.log is generated. The below part is written when the error occured.
**Unable to realise TEXT myText. (4025)
** ABL Debug-Alert Stack Trace **
--> enable_UI c:\myFolder\myFile1.r (c:\myFolder\myFile1.r) at line 21014
c:\myFolder\myFile1.r (c:\myFolder\myFile1.r) at line 14858
USER-INTERFACE-TRIGGER c:\myFolder\myFile2.r (c:\myFolder\myFile2.r) at line 2905
0) OpenEdge 10.2a is ancient, obsolete and unsupported. You should have moved to a modern release 10 years ago. At the very minimum you should be on 10.2b08. Do you also refuse to update Windows? OpenEdge 12 is the current release. It is possible, perhaps even likely, that unanticipated changes in Windows or other aspects of the environment are causing your problem. Progress is never going to update 10.2a to accommodate that sort of thing. You are just prolonging the agony by staying on an obsolete release.
1) What changed in your code or your environment 4 months ago?
2) You can get a stack trace for the extra prowin32 session by running proGetStack. That should help to explain what was launched, what the error is and why another 6-7 start after you kill it. Open a "proenv" window as "Administrator" and run proGetStack (you can get the process id from taskmgr).
proenv> proGetStack 123456
The stack trace will appear in the working directory of the target process. That is usually the same directory that proenv is in but it is possible that the application changes it so you might have to go hunting for it. (Administrator proenv windows sometimes do not start in %wrkdir%, you may also need to cd /d %wrkdir%)
3) If they are not already present you should add -debugalert and -errorstack to your client startup parameters. -clientlog logfileName.log would probably also be helpful.
4) Examine your code base for bits that invoke prowin32 sub-processes. There are many ways to do this such as OS-COMMAND, INPUT THROUGH or via Windows DLL calls. Directly invoking prowin32 can be found by searching for that string but it might also be indirect invocations via a BAT file or other technique.
5) if you have a repeatable way to produce the error then you could also add the 4GLTrace log entry type either at startup or in the code when you get to the proper point: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dpspr/log-entry-types-(-logentrytypes).html
Im using VoiceOver during development to test accessibility changes.
Many times VoiceOver detects changes properly, starts reading them, but is interrupted with new information. So the information that is important is essentially cancelled when additional changes present themselves.
In my case I have an alert that's very important, but ancestor changes seem to get read instead.
If I could see a log of everything VoiceOver is saying I can at least be confident the text is being read and figure out a way to mitigate the problem (possibly by delaying it)
Is there anyway to get a Voiceover log?
I don't believe there is any way to print out a log, but you can save the output to an audio file by pressing ctrl-option-shift-Z. If the audio is running too quickly you could try slowing it down or using some commands to repeat the output. Some of the commands listed here might be helpful:
http://lab.dotjay.co.uk/notes/voiceover-commands/
I have added a reference to a DLL from another project (contained in the bin folder) and I have set Copy local to true. When I step through the code; the debugger jumps all over the place. I believe this is because the code is optimised. I have two questions:
Is this because the code is optimised
If (1) is true then why can I step through the code in the first place i.e. without Reflector.
My guess is the jumping is due to the PDB (symbols) being out of sync with the compiled DLL, thus the symbols tell VS to go to a line number that does not actually match up with what the code is actually doing; optimization may also play a part as well, because of in-lining functions.
Other things that influence the debugging experience are:
Just My Code setting
Methods explicitly marked with DebuggerNonUserCode attribute
Debugging optimized code may "jump around", as some functions become inlined. The most telling thing is that local variables usually get optimized away, giving a message to that effect when trying to read them.
If the jumping seems to make very little sense, though, then it's more likely you have the wrong PDB (which maps to line numbers) or source (which has the line numbers).
I am trying to use the debugger in a thread but the values of the watched variables dont get updated in them unless i remove the break point, make it run for a while then put break point back. They also get refreshed if a messageBox appears. Why is this?
There could be a number of reasons. My best guess is that you're putting break points in decompiled code, where as the compiled code may not occur in that order (as the compiler will move things around). You should consider setting your compiler to a lower level of optimization.
See code below, for some reason it only works when I put a breakpoint on line 2 (*) is there some delay? Is it starting the next line before it finishes the 2nd one?
dp.SSLCertStoreType = nsoftware.IBizPayPal.DirectpaymentSSLCertStoreTypes.sstPEMKey
*dp.SSLCertStore = My.Computer.FileSystem.ReadAllText(Server.MapPath("\cert_key_pem.txt"))
dp.SSLCertSubject = "*"
Note: The error is thrown on the 3rd line only when the breakpoint is set on the 2nd line, after releasing the break the program executes my paypal purchase via credit card.
I will post the error again I am replicating it now...
System error: Could not acquire security credentials: error 8009030E.
There it is, while it should say "Order Confirmed!" type message if working correctly.
Almost certainly a threading issue, but nobody is going to be able to answer definitively unless they're familiar with nsoftware.IBizPayPal
Sometimes you can find that breaking can mutate an object's state, due to the locals window evaluating object properties. If they have a side-effect, then all bets are off, unfortunately :( No idea whether this is happening in your case.
I have no knowledge of ASP, so just wondering aloud: Could this be due to multithreading? You know when you put a break point you sort of freeze execution of all threads, but not so in the real execution.