Re: [ooc-compiler] oo2c-2.0.18 allocator problem

[Tim T. <ra...@ed...>]

Hallo!

> The problem appears to be that the 'theme' element in the DisplayPrefsD=
esc
> object isn't being cleared when the object is allocated. Adding a state=
ment
> to VO:OS:X11:Display.Mod to explicitly assign an empty string to 'theme=
'
> cures the problem.

This has been fixe din CVS by defining a

   PROCEDURE (p : DisplayPrefs) Init*;

in VO:Base:Display, that does initialisation for all Drivers.

When removing this assignment I was able to reproduce it with current oo2=
c.

This is already fixed in CVS and if I remember correctly occured with=20
older version of oo2c, too. It seems like memory initialisation is=20
different among the installed systems. While in theory memory should not =

be initialized at all (see manpage of malloc), it seems like it is on=20
most systems. This is bad, since the compiler does not warn you. The=20
questions is, who is responsible? libc? The gc? Is it realy always by=20
accidient that most of the time memory seems cleared?

> 'man GC_malloc_atomic' says that GC_malloc_atomic doesn't clear the
> allocated memory, which is consistent with the observed behaviour. Howe=
ver,
> the DisplayPrefsDesc object does contain pointers, so GC_malloc_atomic
> shouldn't be getting called.

The gc documentation says that:

  void * GC_MALLOC(size_t nbytes)
     Allocates and clears nbytes of storage. Requires (amortized) time=20
proportional to nbytes. The resulting object will be automatically=20
deallocated when unreferenced. References from objects allocated with=20
the system malloc are usually not considered by the collector. (See=20
GC_MALLOC_UNCOLLECTABLE, however.) GC_MALLOC is a macro which invokes=20
GC_malloc by default or, if GC_DEBUG is defined before gc.h is included, =

a debugging version that checks occasionally for overwrite errors, and=20
the like.

An instance of DisplayPrefs is allocated at the end of VO:Prefs:Display. =

The code generated is like this:

   i0 =3D=20
(OOC_INT32)RT0__NewObject(_td_VO_Prefs_Display__DisplayItem.baseTypes[0])=
;

New object check for a special flag (RT0__flagAtomic) in the descriptor, =

which is: Since the second last entry is "0" (which should be the flags=20
attribute), it seems lie the flag is not set. So DisplayPrefs is not=20
marked as atomic.

RT0__StructDesc _td_VO_Base_Display__DisplayPrefs =3D {=20
(RT0__Struct[]){&_td_VO_Base_Display__DisplayPrefsDesc}, NULL, NULL,=20
&_mid, "DisplayPrefs", 4, -1, 0, RT0__strPointer };

So it seems, like GC_MALLOC does not always clear memory?

--=20
Gru=DF...
        Tim.