Steema Issues Database

Note: This database is for bugs and wishes only. For technical support help, if you are a customer please visit our online forums;
otherwise you can use StackOverflow.
Before using this bug-tracker we recommend a look at this document, Steema Bug Fixing Policy.



Bug 1465

Summary: Access Violation at address 000000022C6B7A46 in module 'TeeChart201564.ocx'`
Product: ActiveX TeeChart Reporter: fredj9988
Component: Visual C++Assignee: Steema Issue Manager <issuemanager>
Status: RESOLVED DUPLICATE    
Severity: blocker CC: marc
Priority: ---    
Version: TeeChart Pro Activex Control v2015 v2015.0.0.3 Release   
Target Milestone: ---   
Hardware: PC   
OS: Windows   
Chart Series: --- Delphi / C++ Builder RAD IDE Version:
Attachments: Error Snapshot
New Screenshots

Description fredj9988 2016-03-10 12:27:10 EST
Created attachment 565 [details]
Error Snapshot

Following issue is causing problem with man of our customers. Our chart control version is 2015.0.0.3.

Whenever the chart control is being instantiated, it fails with "Access Violation at address 000000022C6B7A46 in module 'TeeChart201564.ocx'".

Do we have any know issues related to this? Can you help us debugging this issue by providing debug Tee Chart, Tracing or any other means. 

Please note that this issue is being observed by many of our customers in many different scenarios. It is a showstopper for us. 

Please provide some assistance. 

Thanks
Comment 1 marc meumann 2016-03-10 17:56:42 EST
Greetings,

We are not aware of any similar issue at this time.

- Did the problem appear with TeeChart AX v2015.0.0.3? (assuming you were using an earlier version of TeeChart before)
- Are you able to reproduce the error on demand or is it intermittent?
- If you are able to describe any common machine setup between the installations in which problems occurred, or any application description/steps taken or sample project that might help us reproduce the problem it would be appreciated.
- Does the sample project included with issue: http://bugs.teechart.net/show_bug.cgi?id=1459 show the problem under any circumstances?

With thanks,
Marc Meumann
Comment 2 fredj9988 2016-04-08 10:21:27 EDT
Created attachment 584 [details]
New Screenshots
Comment 3 fredj9988 2016-04-08 10:22:52 EDT
Comment on attachment 584 [details]
New Screenshots

It contains the screenshots of the error.
Comment 4 fredj9988 2016-04-08 10:34:54 EDT
Hi,

We do not know exactly whether the problem lies on our side or TeeChart side.
The application is a multi-threaded and when multiple threads are created, then the issue is reproducible. Unfortunately it is not reproducible in a sample application.


Here is the scenario:
1. Our application creates some threads and these threads do some processing. After a while when an attempt is made to create the OCX (via a call to CoCreateInstance() API) in the main thread, the error comes up. Once the error comes up, then all the subsequent attempts to create the OCX fail with the same error.
2. Now this is something weird; if the chart is created before the threads are created, then the problem never happens i.e., the error is not reproducible as described in the above scenario.


Here are some clues:
1. If you refer to the "Error" attachment, the title of the error is "DAX Error". "DAX Error" seems to be a generic error as there are lots of discussions available in the internet.
2. The problem is not reproducible with the chart version 2012.0.0.8.

This is a road-blocker issue for us. Any help would be highly appreciated.
If you can give us symbols, that will definitely be of great help.

Please refer to the new attachment (New Screenshots) and ignore the previous one.
Screenshot details:
1. Error.png:        The error that comes up.
2. CallStack1.png:   Shows the "Call Stack" when the error comes up.
3. CallStack2.png:   Shows the "Call Stack" in greater details The breakpoint shows the line where it crashes (RAX register is NULL).
4. ProcHack: Shows the "Call Stack" from the "Process Hacker" tool. The address shown in this might be different as it belonged to a different session.


Thanks!
Comment 5 fredj9988 2016-04-08 10:36:31 EDT
The error described is reproducible in 2015.0.0.3.
Comment 6 fredj9988 2016-04-12 06:02:21 EDT

*** This bug has been marked as a duplicate of bug 1505 ***