You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 431 Reporter: administrator Status: closed Resolution: fixed Priority: normal Severity: minor Category: -for CamlIDL use https://github.com/xavierleroy/camlidl/issues
Bug description
Full_Name: Dmitry Bely
Version: 3.01, camlidl current cvs
OS: Windows NT 4.0
Submission from: d207.p3.col.ru (195.210.132.207)
I've faced very strange problem. I have an ocaml-written COM component and a C++
client code that calls its methods. Everything went fine until some
modifications were made to the caml code. After that C++ client started to
crash with access violation error. Debugging showed that ocaml side destroyed
interface's vmt:
//
// client side
//
...
void testComponent(const CLSID & clsid)
{
IPlatePatterns* pIPlatePatterns = NULL; /* some interface /
IPlatePatternIterator pIPlatePatternIterator = NULL;
HRESULT hr = ::CoCreateInstance(clsid,
NULL,
CLSCTX_INPROC_SERVER,
IID_IPlatePatterns,
(void**)&pIPlatePatterns) ;
CHECK_RES; /* error checking macro /
hr = pIPlatePatterns->load("getnumb.cfg");
/ now vmt is overwritten with some data and the next method fails with
access violation */
CHECK_RES;
hr = pIPlatePatterns->makeIPlatePatternIterator( &pIPlatePatternIterator );
...
}
in more detail
//
// server side: camlidl generated code:
//
HRESULT STDMETHODCALLTYPE camlidl_config_IPlatePatterns_load_callback(
struct IPlatePatterns * this,
/* in */ char *file)
{
value _varg[2] = { 0, 0, };
value _vres;
static value _vlabel = 0;
HRESULT _res;
Begin_roots_block(_varg, 2)
_varg[0] = ((struct camlidl_intf ) this)->caml_object;
_varg[1] = copy_string(file);
if (_vlabel == 0) _vlabel = camlidl_lookup_method("load");
End_roots();
_vres = callbackN_exn(Lookup(_varg[0], _vlabel), 2, _varg);
/ vmt is destroyed after returning from callbackN_exn() */
if (Is_exception_result(_vres))
return camlidl_result_exception("config.IPlatePatterns::load",
Extract_exception(_vres));
_res = S_OK;
return _res;
}
Unfortunately I cannot create small test example that demonstrates the bug. But
I can suppose that it happens because GC moves in memory the caml object
representing the interface, which obviously is not acceptable. Can this be true?
If yes, could you fix it?
The text was updated successfully, but these errors were encountered:
Original bug ID: 431
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: -for CamlIDL use https://github.com/xavierleroy/camlidl/issues
Bug description
Full_Name: Dmitry Bely
Version: 3.01, camlidl current cvs
OS: Windows NT 4.0
Submission from: d207.p3.col.ru (195.210.132.207)
I've faced very strange problem. I have an ocaml-written COM component and a C++
client code that calls its methods. Everything went fine until some
modifications were made to the caml code. After that C++ client started to
crash with access violation error. Debugging showed that ocaml side destroyed
interface's vmt:
//
// client side
//
...
void testComponent(const CLSID & clsid)
{
IPlatePatterns* pIPlatePatterns = NULL; /* some interface /
IPlatePatternIterator pIPlatePatternIterator = NULL;
HRESULT hr = ::CoCreateInstance(clsid,
NULL,
CLSCTX_INPROC_SERVER,
IID_IPlatePatterns,
(void**)&pIPlatePatterns) ;
CHECK_RES; /* error checking macro /
hr = pIPlatePatterns->load("getnumb.cfg");
/ now vmt is overwritten with some data and the next method fails with
access violation */
CHECK_RES;
hr = pIPlatePatterns->makeIPlatePatternIterator( &pIPlatePatternIterator );
...
}
in more detail
//
// server side: camlidl generated code:
//
HRESULT STDMETHODCALLTYPE camlidl_config_IPlatePatterns_load_callback(
struct IPlatePatterns * this,
/* in */ char *file)
{
value _varg[2] = { 0, 0, };
value _vres;
static value _vlabel = 0;
HRESULT _res;
Begin_roots_block(_varg, 2)
_varg[0] = ((struct camlidl_intf ) this)->caml_object;
_varg[1] = copy_string(file);
if (_vlabel == 0) _vlabel = camlidl_lookup_method("load");
End_roots();
_vres = callbackN_exn(Lookup(_varg[0], _vlabel), 2, _varg);
/ vmt is destroyed after returning from callbackN_exn() */
if (Is_exception_result(_vres))
return camlidl_result_exception("config.IPlatePatterns::load",
Extract_exception(_vres));
_res = S_OK;
return _res;
}
Unfortunately I cannot create small test example that demonstrates the bug. But
I can suppose that it happens because GC moves in memory the caml object
representing the interface, which obviously is not acceptable. Can this be true?
If yes, could you fix it?
The text was updated successfully, but these errors were encountered: