Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

camlidl: problem with GC? #2833

Closed
vicuna opened this issue Jul 12, 2001 · 1 comment
Closed

camlidl: problem with GC? #2833

vicuna opened this issue Jul 12, 2001 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Jul 12, 2001

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?

@vicuna
Copy link
Author

vicuna commented Jul 30, 2001

Comment author: administrator

See #2835

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant