[Gc] how to link libgc to prevent a garbage collection problem

Tommaso Tagliapietra (EXT VE SYS) tommaso.tagliapietra at enel.it
Thu Nov 15 05:04:39 PST 2007


I've a problem with my application using GC 6.7 and Cygwin on Windows
XP. The Application is linked to a DLL rappresenting the core of the
process (main DLL). This DLL load some other dll extensions linked to
the main DLL as the main.exe. The load of extensions is performed with
the native dlopen.

Main.dll is statically linked with libgc.a and exports all symbols.
Dll extensions import the gc functions from main.dll 

The main DLL define symbol_new that request memory for this object:

struct symbol_t {
  object_t _super;
  flag_t bound;
  char  *name;
  object_t *value;
  object_t *next;
};

...
x = GC_MALLOC(sizeof(struct symbol_t));
....

One of the extensions work with the FTP protocol and after a lot of work
throw an exception doing a non local exit via longjump:

static inline void throw_ftp(void)
{
  static symbol_t *tag = NULL;

  if (tag == NULL)
    tag = symbl_new("ftp", nil);

  throw(tag, NULL);  /* Do a strcmp and then longjmp. */
}

The "ftp" string is assigned to tag->name with a combination of
GC_MALLOC and memcpy:

    tag->name = GC_MALLOC(4);
    memcpy(tag->name, "ftp", 4 /*copy also the \0 char */);  

When the exception happen tag->name point to another memory location
(sometimes to another string, sometimes to NULL). I've verified that
"ftp" is not collected but GC do a mistake with the collection and
reassignment of memory locations. 

I've compiled the ftp.dll extension with a direct link to gc and then
work well, but ... is that correct? 
I think there's a duplication of internal data structures of libgc.
Right? 
And ftp.dll cannot collect object of main.dll and viceversa without a
confusion. Right?
I've tried to compile libgc as shared object but the result is always on
Cygwin a static library (libgc.a). 

Can someone help me?




More information about the Gc mailing list