Re: [Gtk2hs-devel] Re: gtk2hs bug

[Axel S. <A....@ke...>]

On Tue, 2006-03-21 at 15:05 +0000, Duncan Coutts wrote:
> On Tue, 2006-03-21 at 14:46 +0000, Julian Tibble wrote:
> > Hi Duncan,
> > 
> > I tried gtk2hs and the 'fonts' demo crashes on my machine.
> > 

I found the cause of this bug and it's with Pango. The gist is that we
can't create a new FontMap ever, since the memory management in
cairoFontMapListFamilies is broken. The workaround for now is to get rid
of cairoFontMapNew and only provide access to the cairoFontMapGetDefault
function which creates a FontMap but never frees it (and hence the bug
doesn't manifest itself). This is not so nice, since if you change the
FontMap you change the FontMap for everything else in your application
(which is the reason why cairoFontMapGetDefault wasn't bound initially).

It's a workround, not more.

Axel.

Comment from the commit:


Tue May  2 11:35:37 PDT 2006  Axel Simon <A....@ke...>
  * Workaround for font enumeration bug in Pango.
  
  This patch removes the cairoFontMapNew function and adds
  cairoFontMapGetDefault. While the former function can be bound and
  is itself correct, certain functions like pangoFontMapListFamilies
  are not. The latter function creates FontFace structures (and others)
  whose reference is added to the FontMap object. The FontFace
  objects themselves contain a pointer to
  the FontMap that they are embedded in. Alas, they do not add a
reference
  to the FontMap they have locally in their own structure.
  Hence, when Haskell garbage collects the FontMap created by
cairoFontMapNew
  the FontMap that contains the FontFaces vanishes and the FontFace
(which
  itself is a GObject) stays alive and has thereby a dangling pointer to
  the FontMap. This is certainly a bug in Pango but they might not want
to
  fix this since it involves breaking cycles in reference counting.