I've been using ESENT for my projects quite extensively and I really love how easy and fast it works. And stable too!!
But I have a HUGE problem with Windows 8!!! Regardless of how I link to the esent.dll (dynamically or statically) whenever I call something other than JetSetSystemParameter, the dll is crashing, takig my app down the cliff.
Unfortunately I still can't get it running. My code had no problem running with Windows 7 or older. But with Windows 8 I get esent.dll crashing when I try to create an instance (floating point invalid operation).
I tried all possible calling conventions. This is definitely NOT the problem. I tried some more and discovered this weird situation: 1. I created a demo application using VS 2012 and JetCreateInstance worked just fine. 2. Exactly the same code in Delphi XE3 will send esent.dll crashing. 3. I created a DLL using VS 2012, exporting the method that worked perfectly in the above demo app, thinking it's a Delphi bug. 4. And then I loaded the DLL in a demo Delphi project (tried with 6, XE2 and XE3). Called the method and BOOM. Same crash.
Now my assumption is that Microsoft won't allow?!? any other developer environment to work correctly with the esent.dll. Is this possible???
The error, a floating point invalid operation, makes the problem sound as though it is related to the floating point control word.
By default Delphi unmasks floating point exceptions. So when code asks the floating point unit to perform operations that result in errors, the FPU signals which is then converted to an exception.
But most other Windows development environments mask these exceptions on the FPU. Such code is written under the assumption that the execution environment has FPU exceptions masked. But if you call a DLL from Delphi, the execution environment will have unmasked FPU exceptions, breaking that assumption. I suspect that if you mask FPU exceptions then your problems will disappear.
To test if this is the problem, you can simply add this to your code, executed early in its life:
Set8087CW($027F);
This will mask all exceptions and set the FPU control word to the default Windows setting.
In the longer term you may wish to mask exceptions before each call to this DLL, and then restore the FPU control word when the call to the DLL returns.
That is a slightly dangerous game using the libraries that are supplied with Delphi since Set8087CW is not threadsafe due to its use of the global variable Default8087CW. If you wish to read more about that issue, I refer you to QC#107411.
Related
I got a problem recently that when I added a code to a lib, which is used by a dll, the dll cannot be loaded. I get an exception "Floating point invalid operation at xxx". When I comment out the code it works. The code added is just straight forward like creating a TADOQuery object, add the sql statment and the parameters, then do an open, check value etc. Nothing suspicious. Now when I uncomment the code and comment another chuck of code in the unit elsewhere, it starts to work. So obviously the newly added code was just tripping the issue caused elsewhere.
Now this error happens when LoadLibrary() call is invoked. There is no attach code. The DllMain, just has a return 1. When this happens the assembly code is always at FSTP tbyte ptr doing a System::Variant::Clear().
Anyone has come across such issues? Any tips on how to debug is also appreciated.
PS: It could also be Embarcadero's compiler issue. I recently figured out that the assembly generated for a combination of assignment and comparison is incorrect. The only suspicion here is the lib that the dll uses is large. When I do a clean and build of the lib, the total lines shows 5.7m. Maybe there is some setting for large libs?
IDE-XE4, c++ builder
OS-Win 7
Thanks,
Mathew Joy
C++Builder and Delphi have different default FPU settings than, say, MSVC and the DLLs written in it.
It probably goes like this: After DllMain, certain exceptions are masked to be hidden. But before the first floating point operation in C++Builder code occurs, that exception is unmasked and the exception occurs.
This is a known problem with C++Builder/Delphi floating point and DLLs.
I am running opencv 3.0's sample code hog.cpp (from the folder \samples\gpu\hog.cpp) for people detection, using the GPU. (the CPU part crashes for me). The code compiles, but when I run it, it crashes at the line:
gpu_hog->detectMultiScale(gpu_img, found);
Unhandled exception at 0x000007FEDE717A28 (opencv_core300.dll) in
Hog3StandAlone.exe: 0xC0000005: Access violation reading location
0x000002380000013C.
I am using visual studio 2012, Windows 7 Pro 64 bit.
There are quite a few things that can cause such a problem.
The code itself seems "fine".
What I suggest is that you compile the program in Debug mode. Then, run it from Visual Studio. The IDE's debug session should stop at the exact place in which the "access violation" happened. From there, you can have a more precise idea on the origin of the problem.
For example, I got similar problem at line #341
vc >> frame;
because the VideoCapture vc object returned corrupted frames.
Your problem might be similar (or completely different. That's why you should run a debug session in Visual Studio)
I've tried the same sample before and worked without any problems as far as I remember. On the other hand, this access violation is probably due to the fact that your input "gpu_img" is empty or corrupted. Make it sure that you read the frames correctly (you can use imshow function to visually examine) and also you upload it into gpu_img as well. I don't see any other possible explanation.
A very strange, presumably meant to be helpfull behaviour of Visual Studio 2012.
When I enter a double in vb.net like:
Dim myD as Double = 1.4
When I hit enter of move my focus another way, the formatting kicks in and changes the above to:
Dim myD as Double = 1.39999999999999998
or 1.6 as
Dim myD as Double = 1.6000000000000001
This behaviour does not appear to happen for all doubles. 1.3, 1.5, 1.7 and 1.8
See this youtube movie for the behaviour in action:
http://youtu.be/afw4jg58-aU
Why, and more important, how can I prevent this?
Edit:
Extensions installed are:
Second Edit
The behaviour seems to have gone away. I do not know what has caused this so for future reference this is useless to anyone, but for now, I'm happy that I don't have to go troubleshooting as suggested.
The exact same issue is also reported in this question. Which applied to VS2010, otherwise without a usable answer.
This is an environmental problem, code is getting loaded into Visual Studio that messes with the FPU control word on your machine. It is a processor register that determines how floating point operations work, it looks like this:
The Rounding Control bits are a good source of trouble like this, they determine how the internal 80-bits precision floating point value is truncated to 64-bits. Options are round-up, round-down and round-to-nearest. The Precision Control bits are also a good candidate, options are full 64-bit precision, 53 and 24 bits.
Both VS2012 and the .NET Framework rely on the operating system default, with the expectation that this will not change afterwards. Pretty hard to diagnose trouble arises when code actually does change it, your observation strongly fits the pattern. The most common troublemakers are:
code that uses DirectX without the D3DCREATE_FPU_PRESERVE option. DirectX reprograms the precision and rounding control bits to squeeze out a bit more perf.
code that was written in an older Borland language product. Its runtime library initializes the FPU control word in a non-standard way. Otherwise a generic problem with software that relies on old runtime library or an old legacy initialization that was carried through in later releases.
in general, any code that uses a media codec or media api. Such code tends to reprogram the FPU to squeeze out perf for the same reasons that DirectX does. Especially notorious in a product I worked on which uses such codecs heavily. The codebase was peppered with calls that reset the FPU control word after making a call into external code.
Finding and eliminating such code can be very difficult. DLLs get injected into another process by a large variety of well-intended malware. The SysInternals' Autoruns utility can be very useful, it shows all the possible ways code can be injected with an easy way to disable it. Be prepared to be shocked at what you see and readily disable stuff that doesn't carry a Microsoft copyright.
For dynamic injection, you'll need a debugger to see what is loaded into VS. Start VS again and use Tools + Attach to Process to attach to the first one, selecting the unmanaged debugger. Debug + Windows + Modules shows you what DLLs are loaded. Do beware that the DLL can be transient, a shell dialog like File + Open + File will dynamically load shell extensions into VS and unload them again afterwards. Good luck with it, you'll need it and sometimes the only fix is a rather drastic one.
I had the exact same issue with Visual Studio 2012.
The "solution" if it happens to you is:
write your number in your code
let VS screw it up, e.g. when you move to another line
CTRL-Z to revert VS mess
continue writing your code
I am debugging the live process (not dump) of PresentationHost.exe. It used to works fine, but suddenly few days ago I get the above error message. !Threads, !pe, virtually all SOS command doesn't work.
All I remember is that I installed Visual Studio 2010 and .NET framework 4.0 before I'm getting that error. Is it related?
UPDATE:
I myself can not reproduce the problem I was having. Probably I was debugging 32 bit process with 64 bit debugger, or .NET 4 process with .NET 2.0 SOS, or vice versa, or combination of both bitness and DLL version.
Apologize that this question may not valid.
When are you trying to issue the command?
This error is quite common when attempting to issue SOS commands before the CLR was fully loaded.
You could attempt to break right after the CLR had finished its initialization procedure. In order to break at that point, you could place a breakpoint in the following manner: bp clr!EEStartup "gu". This will cause the debugger to break on the EEStartup function, and continue execution until the function completes.
When the debugger breaks on that breakpoint, you should be able to issue your SOS commands.
I'm new to VB6 but i'm currently in charge of maintaining a horror of editor like tool with plenty of forms, classes, modules and 3rd party tools all chunk together like the skin faces on that guy in the texas chainsaw massacre...
What i don't understand is why i get different results when i run the app in debugging mode, vs when i compiled it and run it on my devevelopment pc vs when i installed it on a different pc.
Yes i know i'm dumb, so please direct me to where i can find out more about this. I'm hoping to find out something like different linking, registry related etc connection that i'm simply not getting right now, i.e. something like wax on, wax off :P
The main pain in the neck is when i'm trying to debug some errors from my QA and i need to find a spare pc to test this on plus i can't directly debug because i don't know where the code is if i do it that manner.
Thanks.
i run the app in debugging mode vs when i compiled it and run it on my
devevelopment pc
When you compile you have the option of compiling to native code or pcode. The debugger runs using pcode only. Under rare circumstances when you compile to native code there will be a change in behavior. This particular is really rare. I used VB6 since it's release and I may get it once or twice a year. My application is a complex CAD/CAM creating shapes and running metal cutting machine and has two dozen DLLs. Not a typical situation. At home with my hobby software I never ran into this problem.
There are another class of errors that result from event sequencing problems. While VB6 isn't truly multi-tasking it has the ability to jump out of the current code block to process a event. If it re-enters the same block for the new event interesting things (to say the least) can result. I think this is the likely source of your problems as you software is an editor which is a highly interactive type of software.
In general the problem is fixed by reordering the effected areas. You find the effected area by inserting MsgBox or write to a text file to log where you are. I recommend logging to a text file as MsgBox tend to alter behavior that are timing or multi-tasking related.
Remember if a event fire while VB6 in the middle of a code block and there a DoEvents floating around then it will leave the code block process the event and return to the original code block. If it re-enters the same code block and you didn't mean for this to happen then you will have problems. And you will have different problems on different computers as the timing will be different for each.
The easiest way to deal with this type of issues is create some flag variables. In multi-tasking parlance they are known as semaphores or mutexes. WHen you enter a critical section of code, you set it true. When you leave the routine you set it to false. If it is already true when you enter that section of code you don't execute it.
when i installed it on a different pc.
These are usually the result of the wrong DLL installed. Most likely you have an older version while the target has a newer version. I would download the free Virtual PC and create a clean Window XP install to double check this.
If your problem is event timing this too can be different on different computers. This is found by logging (not MsgBox) suspect regions.
If you can display a screen shot or the text of your specific errors then I can help better.
The first thing to check would be the versions of all the dlls that your app depends on - including the service pack version of the VB6 dll.
Have you any more specific details about what's behaving differently?