Problem in calling a virtual function across Symbian DLLs.

Question

My IM application setup is like below:

• User Interface module (exe)
• Plugin module ( A polymorphic DLL that provides an abstract interface for different protocols to the UI module )
• Several Protocol DLLs ( Shared library DLLs that implement the respective protocols, like Jabber, ICQ etc )

Now, I was asked to implement contact list caching feature and that meant doing File I/O.

Since File I/O cannot be done in the protocol DLLs ( it cannot access the applications private folder ) I implemented a class deriving from an abstract class interface in the user interface module.

I then exposed the abstract interface to the Plugin module and protocol DLLs.

Let that abstract interface be named MFileService.

From the protocol DLL this is how I get an instance of MFileService derived class:

1. Protocol DLL calls a virtual function on plugin object to get a pointer to MFileService derived object

2. Plugin object calls a virtual function on the user interface module.

3. The user interface module creates an instance of MFileService dervied class and returns it to the caller ( The plugin object )

4. The plugin object inturn returns it to the protocol DLL.

The problem is my application is crashing with KERN-EXEC 3 at step 1 when its making a virtual function call to plugin object.

HINTS:

• All the virtual function calls made to the plugin object from the protocol DLL succeeds except the one I recently added.

• The virtual function I newly added to the plugin and user interface modules return a pointer to MFileService.

• I have not exported any of the virtual functions since all are pure virtual.

Answer 1

KERN-EXEC 3 normally means an Access Violation. This probably means that MFileService was not properly initialized in the plugin DLL.

1. Check to ensure MFileService was properly created.
2. Check that the harness is calling the correct entry point in the DLL. This is typically the first function in the DLL (Check the .def file)
3. Check that the plugin DLL actually has a valid value for MFileService BEFORE the protocol DLL is created.

Without the code, I cannot give you more detail than this.

Answer 2

Since File I/O cannot be done in the protocol DLLs ( it cannot access the applications private folder )

This is in fact not so. DLL code runs in the process (exe) context and can essentially do whatever the main exe can, including accessing its private directory data cage.