Hello,
Thank you very much for your e-mail.
With regards to article that you pointed out, this is one of reasons why Alloc() and Free() functions are provided
in the Site interface. If you call them, you are free from the problem because you are NOT using incompatible heaps.
If you use Alloc() and Free() you are using the same heap and same allocation as AB itself.
.NET developer is unfortunately not right person to consult. Look for someone that knows C, not C#.NET or VB.NET.
The difference between is like between neurosurgeon and GP.
As to the fact that your tests don't show the problem - you of course did not arrive to pretty obvious conclusions that your test is
not testing things deeply enough.
You of course did not write your tests to use multiple threads, did you?
Let us take for example Windows GDI. Windows developers are of course smart guys, yes ?
And they of course run unit tests that show that everything works OK and everything is stable, yes?
And thousands of applications use GDI and it works, don't you think so?
So everything in such well tested GDI must be perfect, yes?
Yet for many many years they did not test metafiles GDI in multiple threads and they had huge bug here
that went unnoticed and were still present in Windows XP (that is ridiculous because GDI was there without changes
since Windows 95 or earlier). The bug occurred ONLY if you tried to use metafile GDI from two or more threads
and not "immediatelly" but only under "heavy load".
I spent at least week analysing why on earth metafile GDI produces unstable behavior on Windows XP
and earlier when called from multiple threads with high frequency.
After week of trials, I found that this is genuine GDI bug.
Microsoft told developers it is "by design-issue" that is unlikely to be fixed.
Then Microsoft silently fixed their long GDI standing bug in Windows Vista.
http://microsoft.public.win32.programmer.gdi.narkive.com/CWlhQrnn/serious-gdi-multithreading-bug-while-printing-to-metafiles
And I ended up essentially rewriting Metafile GDI API to build my own, thread-safe Metafile-like API
to allow low level Gfx functions to work properly on Windows XP and earlier.
Another example of failed unit tests:
There is a runtime function strtod() / atof that converts string to floating point number.
Basic function you may say and sure they run unit tests on it and they all ran perfectly fine, yes?
Yes they did. But their tests were flawed. They only tested small buffers. Did not test on large buffer.
Their strtod/atof() function for a LONG time had strlen() embedded that caused HUGE performance penalty
(such as 1000x slow down on long strings).
http://computer-programming-forum.com/81-vc/597cb6e32fc43e90.htm
Again I had to rewrite C runtime strtod() NOT to be affected by this bug.
They fixed it recently in VC, though.
A lesson from Microsoft to learn for you: don't trust your unit tests.
Good for 1st year students and programmer's kindergarten.
They are fine for basic checking, but FAR from complete.
The only test that is more or less close to reality is if you release the software and
it is installed and run by 20000+ people and it works.
Best regards,
Tomasz Janeczko
amibroker.com
Tomasz, I'm not suspecting everyone around me. I am constructively trying to generate hypotheses and check them out. The facts are: output from the DLL is stable and accurate but output from AmiBroker is not, which indicates some kind of interaction from the DLL into AmiBroker. I can only think of two general kinds of ways this could happen,1) Heap corruption2) Configuration incompatibility
I'm open to others possibilities. To check heap corruption I removed all heap operations from the DLL. Since the problem persists, and I can't imagine AmiBroker is mismanaging its heap, I'm wondering about configuration issues partly because while researching the problem I ran across this in MSDN,
where it warns about a configuration incompatibility that could cause heap corruption in the application. I think I'm very reasonably asking whether I might inadvertently be impacting AmiBroker in this or similar sort of way.
FWIW, I have a neighbor who is a .NET developer. He's looked at the code and his advice was I should contact the application developer.
---In amibroker@yahoogroups.com, <nickhere@...> wrote :
Could the issue be running afl in multitasking mode.
I always had doubt with that returns
Nick
On 4/6/2016 5:36 AM, Tomasz Janeczko groups@... [amibroker] wrote:
Hello,
Thank you very much for your e-mail.
You are suspecting everyone around you (the compiler, #pragmas, AmiBroker), yet dozens of people created their DLLs
and they working fine and they all did that without any single problem. Isn't that interesting?
If you can't find errors in your code, hire some *experienced* programmer (locally so he can , not remote over internet) to find errors for you.
Best regards,
Tomasz Janeczko
amibroker.com
On 2016-04-06 08:01, rosenberggregg@... [amibroker] wrote:
Hi Tomasz,
I just made the code change and configured VS to use "precise" for float instead of "fast". These changes made no difference. The plugin function is just doing divide-by-zero protection and there is no other plugin code exposed to AmiBroker. The code changes I made were to immediately copy all float * values returned by AmiBroker functions to a class with an embedded compile-time array, and do all processing on that class before copying values back to AmiBroker. Other than copy-to and copy-from operations, the code never touches an AB float *. It is the only plugin code exposed to AmiBroker at all and a small enough code segment to easily watch.
It's weird the plugin is returning correct results but AmiBroker becomes flakey. What's more mysterious, the plugin passes unit tests -- it returns stable, correct results when called on its own, even in a loop. It is AmiBroker AFL which starts giving unstable results when I pass results around during more intense processing. Are you sure there can't be a compiler or pragma-type issue I need to address? It's so bizarre, if it's not a pointer issue, it makes me think something basic is incompatible between AmiBroker and the DLL.
BTW, I'm using the sample.dll files and haven't touched plugin.h, plugin.cpp, sample.h or sample.cpp. I have noticed VS is giving a bunch of "function definition not found" messages on a group of PLUGINAPI prototypes in the plugin.h file. I assume this is normal?
Just as an FYI, the code for my exposed function is below. There's a preceding two-argument function which just catches the call from AmiBroker and passes the arguments from the ArgsTable along to this function. It's just a safe division routine, which gives the user an option to specify the value to substitute for zero and a value to use if both numerator and denominator are zero. It's not rocket science. In fact, it's so simple I can do the whole thing as a series of constructor calls.
The first two float * arguments to it come from the ArgsTable passed by AmiBroker and are immediately copied to the class I mentioned, which wraps an embedded array. Similarly with the float * returned by calls to AlmostEqual and IIF. After it returns result, the receiving class copies its contents to an AmiVar and sends it off to AB. Those are all the operations with pointers being done.
ABArray SafeDiv(float *num, float *denom, float safeDenom, float numZero) {//// Exchange zeros for small number before dividing//ABArraynumm(num),denomm(denom),nZero(ab_AlmostEqual(numm,0.0f)),dZero(ab_AlmostEqual(denomm,0.0f)),dblZero(ab_And(nZero,dZero)),safeD(ab_IIF(dZero,safeDenom, denomm)),result(ab_IIF(dblZero,numZero, ab_Divide(numm, safeD)));
returnresult;
} // End SafeDiv
Posted by: Tomasz Janeczko <groups@amibroker.com>
| Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (14) |
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
EmoticonEmoticon