Error Delete module instance on exit

[vchamp]

Before posting a bug in Orbiter SDK, I want to be sure that I do everything correctly.

Here we have a very simple example of the new Module API usage:

ModuleEntry.cpp

#define STRICT
#define ORBITER_MODULE

#include "MyModule.h"
#include "resource.h"

using namespace oapi;

HINSTANCE g_hInst;  // module instance handle
MyModule* g_module;    // module instance

DLLCLBK void InitModule (HINSTANCE hDLL)
{
    g_hInst = hDLL; // remember the instance handle

    g_module = new MyModule(hDLL);
    oapiRegisterModule(g_module);
}

DLLCLBK void ExitModule (HINSTANCE hDLL)
{
    oapiWriteLog("before delete");
    delete g_module;
    oapiWriteLog("exit");
}

MyModule.h

#pragma once

#include "orbitersdk.h"
#include "ModuleAPI.h"

namespace oapi {

class MyModule : public Module {
public:

    MyModule(HINSTANCE hDLL);
    ~MyModule();

};

};

MyModule.cpp

#include "MyModule.h"

using namespace oapi;

MyModule::MyModule(HINSTANCE hDLL) : Module (hDLL) {

};

MyModule::~MyModule() {

}

Now the problem is that oapiWriteLog("exit") is never called and in the debug mode the output window displays:

First-chance exception at 0x68af11e3 (ModuleCheck.dll) in orbiter.exe: 0xC0000005: Access violation reading location 0xdddddddd.
'orbiter.exe': Unloaded 'D:\projects\vs\Modules\Plugin\ModuleCheck.dll'

I made my module following the RControl sample and the standard RControl.dll is unloaded with error too:

First-chance exception at 0xc35ec68b in orbiter.exe: 0xC0000005: Access violation reading location 0xc35ec68b.
'orbiter.exe': Unloaded 'D:\projects\vs\Modules\Plugin\Rcontrol.dll'

Is this a bug in SDK or in my module? Maybe 'delete g_module;' is unnecessary?

---------- Post added at 10:51 AM ---------- Previous post was at 10:09 AM ----------

Found this in Orbiter API reference:

Note:
The DLL should not delete the module instance in ExitModule. Orbiter destroys all registered modules automatically when required.

It answers my question. However RControl should be fixed.

Also it makes the use of a smart pointer for a module instance undesirable.