|
 ChartDirector DLL question |
| Posted by Cody Knight on May-19-2017 04:59 |
|
Hello Peter,
We are trying to figure out data race issues we are having with our program related to ChartDirector. Whenever the Intel Inspector runs there are a large number of races related to chartdirector.h and chrtdir60.dll.
Opening the details of one of these reports the page shown. What would cause chartdir60.dll!runMethod to be calling itself recursively like this?
There are a number of basecharts updating simultaneously, but there is only one basechart and chartviewer per thread.
Thanks,
Cody Knight
|
| Re: ChartDirector DLL question |
| Posted by Peter Kwan on May-19-2017 16:29 |
|
Hi Cody,
From my experience, the "Call Stack" is inaccurate for DLLs with no debug information, such as the "chartdir60.dll" (which is built in "Release Mode").
For a DLL like "chartdir60.dll", there are some public function names like "runMethod", "CBaseChart_makeChart2". These functions can be accessed by external code, such as your code. There are also internal function names, but they would not appear in "Release Mode" DLL.
When a debugger (such as the Intel tool) would try to unwind the "Call Stack" to get the memory address of the functions. It then tries to convert the memory address into function names. For internal functions in "Release Mode" DLLs, there are no names. The debugger may just display the address like "chartdir60.dll!0xb412". Sometimes, if the address is near to another address that has a function name, it will display the function name. So in the "Call Stack", "runMethod" just means a function with a memory address near to runMethod". It does not mean the function is "runMethod".
ChartDirector is frequently being used in heavily multi-threaded environment, such as in servers. As long as each chart object is accessed by one thread at a time, it should work fine. Multiple chart objects of course can be accessed from multiple threads.
For multi-threading GUI program, one common issue is for code trying to access the controls (eg. MFC or Qt controls) in another thread. The controls are constantly being called by the operating system to handle onPaint events, mouse events and numerous other OS events. These events occur in the thread that creates the control (typically the main thread). If some code uses the control in another thread, it may lead to race conditions with the operating system.
For charting code, you can put the charting code in any thread you like. But for the lines that use the MFC or Qt chart viewer controls, they should run in the thread that creates the control (typically the main thread).
Regards
Peter Kwan |
| Re: ChartDirector DLL question |
| Posted by Cody Knight on May-19-2017 21:57 |
|
| Thank you |
|
Forum Home
Search
Message List
Post Message
(Cody Knight)