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,
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