Wt

Constructing a WPdfImage using the constructor that does not accept a HPDF_Doc results in a memory leak when the WPdfImage is destructed. This leak is apparently a HPDF_GState that libharu fails to release, even though the WPdfImage destructor calls HPDF_Free. The problem seems to be that this code path leaves a document page with two GStates on the GState stack, but HPDF_Free appears to free at most one GState.

The memory leak can be observed with valgrind on the stand-alone charts example. Testing was done with Wt 3.3.4 on Debian 7.8 (wheezy), using libharu from github RELEASE_2_3_0RC2-61-g22e741e. Here is a lightly edited loss record from the charts example:

600 bytes in 3 blocks are definitely lost in loss record 600 of 680
   at: malloc (vg_replace_malloc.c:263)
   by: HPDF_GetMem (hpdf_mmgr.c:204)
   by: HPDF_GState_New (hpdf_gstate.c:34)
   by: HPDF_Page_New (hpdf_pages.c:337)
   by: HPDF_AddPage (hpdf_doc.c:877)
   by: Wt::WPdfImage::WPdfImage(Wt::WLength const&, Wt::WLength const&, Wt::WObject*) (WPdfImage.C:63)
   by: Wt::ServerSideFontMetrics::ServerSideFontMetrics() (ServerSideFontMetrics.C:25)
   by: Wt::WCanvasPaintDevice::fontMetrics() (WCanvasPaintDevice.C:626)
   by: Wt::WMeasurePaintDevice::fontMetrics() (WMeasurePaintDevice.C:149)
   by: Wt::WMeasurePaintDevice::drawText(Wt::WRectF const&, Wt::WFlags<Wt::AlignmentFlag>, Wt::TextFlag, Wt::WString const&) (WMeasurePaintDevice.C:97)
   by: Wt::WPainter::drawText(Wt::WRectF const&, Wt::WFlags<Wt::AlignmentFlag>, Wt::WString const&) (WPainter.C:500)
   by: Wt::Chart::WAxis::renderLabel(Wt::WPainter&, Wt::WString const&, Wt::WPointF const&, Wt::WFlags<Wt::AlignmentFlag>, double, int) const (WAxis.C:1347)
   by: Wt::Chart::WAxis::render(Wt::WPainter&, Wt::WFlags<Wt::Chart::AxisProperty>, Wt::WPointF const&, Wt::WPointF const&, double, double, double, Wt::WFlags<Wt::AlignmentFlag>) const (WAxis.C:1293)
   by: Wt::Chart::WCartesianChart::renderAxis(Wt::WPainter&, Wt::Chart::WAxis const&, Wt::WFlags<Wt::Chart::AxisProperty>) const (WCartesianChart.C:1968)
   by: Wt::Chart::WCartesianChart::renderAxes(Wt::WPainter&, Wt::WFlags<Wt::Chart::AxisProperty>) const (WCartesianChart.C:1974)
   by: Wt::Chart::WCartesianChart::initLayout(Wt::WRectF const&, Wt::WPaintDevice*) const (WCartesianChart.C:1444)
   by: Wt::Chart::WCartesianChart::render(Wt::WPainter&, Wt::WRectF const&) const (WCartesianChart.C:1396)
   by: Wt::Chart::WCartesianChart::paint(Wt::WPainter&, Wt::WRectF const&) const (WCartesianChart.C:1381)
   by: Wt::Chart::WCartesianChart::paintEvent(Wt::WPaintDevice*) (WCartesianChart.C:1388)
   by: Wt::WPaintedWidget::createDomElement(Wt::WApplication*) (WPaintedWidget.C:335)

While the leak in WPdfImage does not appear to be new, it may be encountered more often via the new setAutoLayoutEnabled feature in WCartesianChart.

The attached patch has been (lightly) tested as a workaround. Perhaps this should really be considered a bug in libharu?