Compiling the current gladman AES library, I'm getting warnings in aes_modes.c, all saying "warning C4731: ... frame pointer register 'ebx' modified by inline assembly code"
This sounds pretty worrying, I don't want my app to crash with a stack corruption, but I can barely read x86 assembler. Can anyone advise if these warnings can be safely ignored?
This is safe to ignore if its saved and restored. For eg.
push ebx
;use the ebx to do something else
pop ebx
See this MSDN page, which explains what that error means.
If its not done in the code, you can add that and test it.
It seems it is NOT safe to ignore this warning.
The code had been working fine on XP, but when tested on Windows 7 it crashes within the aes_decrypt assembler routine. I am going to move over to a pure C version.
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
In writing a Qt4 app, I clumsily wrote:
QObject::connect(spinbox, SIGNAL(vlaueChanged(int)), ....
and it compiled, and it ran, but of course the spinbox didn't have any effect.
Such misspellings should be caught. I always assumed that valueChanged() was declared in some header file, but apparently not. Any arbitrary garbage can be given to SIGNAL() or SLOT(), and it'll compile. My toy program is small. For a huge app with dynamically created controls connected on the fly, an error like this could be very hard to track down.
Is there some way to do error checking for this kind of typo? Is it possible for the compiler (gcc) to do this, or is some other tool appropriate?
This has been changed for Qt5. You can read about it here.
SIGNAL and SLOT macros turn their arguments into strings, and they are not checked in compile time (because... they are string actually). In case of wrong signal/slot name Qt writes warning (qWarn) in runtime. They say, in Qt5 something changed there.
In my experience, sometimes you really can do such a mistake (though rarely, autocompletion helps a lot), but it can be easily tracked down and fixed.
I'm doing development for Blackberry 10 using Cascades, which includes QT and QML. I find that I sometimes make mistakes in my QML file, but they don't get picked up at compilation time. How can I check whether I've made a syntax error, or mis-named a function call, or other typical errors?
QML is a dynamic language that is evaluated at Runtime. There is no compilation step and due to the nature of javascript and the dynamic nature of the global context there is no way for it to tell if what you are writing is correct/incorrect until it is evaluated. QtCreator can help with some of the QML errors you will find, but there is unfortunately no good way to get syntax errors about your javascript until it is evaluated and it explodes.
Personally, I have found good usage of the debugger to be the key to making these sort of fixes easy.
tldr; Keep your javascript clean and to a minimum there is no compile time checking.
open terminal in IDE connect your device or emulator using blackberry-SSH after connecting enter slog2info it show syntax and all typical error JavaScript with description and line NO.
If there are any mistakes it will show those lines in RED marks. It is dynamically checks there is no need to worry about compile.
If you done wrong you will not see the DESIGN CONSOLE correctly.
How do I suppress a MessageBox from showing that comes from a reference to an assembly that I do not own (nor have the code for)?
For example, my application (MyApplication.exe) is referencing an assembly coded by someone else (SomeoneElsesAssembly.dll). Inside of this assembly I'm calling a static method, which does what it's supposes to, but also is firing a MessageBox that I want to suppress.
I thought there was a way to reference an assembly in Non-Interactive mode or something along these lines.
Thank you for your help.
-Jessy Houle
This article may be able to help
What you are asking is basically "How can I modify the behavior of code in a third-party assembly".
Short of disassembling/reassembling, the answer is "You can't".
There are some icky options;
With managed code you always have the source in some form. If the function is somewhat self-contained you could use Reflector to copy it into your own code
You could have a 2nd thread that waits till the message box appears and then automatically closes it.
I thought there was a way to reference an assembly in Non-Interactive mode or something along these lines.
I believe it's possible to run a process in a non-interactive mode (such as Windows Services, for example), but assemblies are loaded into the process and are subject to the same interaction levels as other assemblies in the process, afaik.
So, either disassemble-reassemble or send windows messages directly to the box to automatically close it.
Basically you're asking if you can reference an assembly which calls MessageBox() and have the code not actually show a message box. The answer is unfortunately no.
You're best bet is to use screen scraping to close the message box once it shows up. This post has some example code of how to close an InProc message box. http://www.codeproject.com/KB/dialog/AutoCloseMessageBox.aspx
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.