Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000431OCamlCamlIDLpublic2001-07-12 14:272001-07-30 16:26
Reporteradministrator 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000431: camlidl: problem with GC?
DescriptionFull_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?

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000052)
administrator (administrator)
2001-07-30 16:26

See PR#433

- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker