New feature: a GUI proxy for BaCon

[vovchik]

Dear Alex,

I was also wondering about the raw_array. It's a convenient way to do it, but it could certainly be done in another way. I have attached my latest source...

With kind regards,
vovchik

Attachments:

djt-45-gtk2-memtest-alex-bac.tar.gz (3.58 KB)

[alexfish]

Hi Vovchik

can avoid that array by a direct cast.
also not sure on bacon LEN when UTF8 is involved it can give LEN as UTF8LEN
some times need to avoid this.
possible cast as follows and see what happens

' ------------------
FUNCTION SVG_BUFF(STRING svg$) TYPE GdkPixbuf*
' ------------------
' use global to free later
LOCAL pixloader TYPE GdkPixbufLoader*
' use global to free later
LOCAL pixbuf TYPE GdkPixbuf*
LOCAL size TYPE NUMBER
LOCAL res TYPE int
'LOCAL raw_array TYPE unsigned char*
'size = LEN(svg$)
'raw_array =
pixloader = gdk_pixbuf_loader_new()
res = gdk_pixbuf_loader_write(pixloader,(unsigned char*)svg$, strlen(svg$), 0)
res = gdk_pixbuf_loader_close(pixloader, 0)
pixbuf = gdk_pixbuf_loader_get_pixbuf(pixloader)
gdk_pixbuf_loader_close(pixloader, NULL)

RETURN pixbuf
END FUNCTION

will look at the code now.

and a a comparison
although the gui does not show here under valgrid ?

here is are the results my original code: adapted with the above

==3040== HEAP SUMMARY:
==3040==     in use at exit: 53,449 bytes in 491 blocks
==3040==   total heap usage: 696 allocs, 205 frees, 71,316 bytes allocated
==3040==
==3040== LEAK SUMMARY:
==3040==    definitely lost: 0 bytes in 0 blocks
==3040==    indirectly lost: 0 bytes in 0 blocks
==3040==      possibly lost: 15,312 bytes in 94 blocks
==3040==    still reachable: 38,137 bytes in 397 blocks
==3040==         suppressed: 0 bytes in 0 blocks
==3040== Rerun with --leak-check=full to see details of leaked memory
==3040==
==3040== For counts of detected and suppressed errors, rerun with: -v
==3040== Use --track-origins=yes to see where uninitialised values come from
==3040== ERROR SUMMARY: 195019 errors from 164 contexts (suppressed: 409 from 1)



BR
Alex

[vovchik]

Dear Alex,

I added another cast (in strlen), just to make sure the size really matches the array, but get the same result in valgrind:

' ------------------
FUNCTION SVG_BUFF(STRING svg$) TYPE GdkPixbuf*
' ------------------
LOCAL pixloader TYPE GdkPixbufLoader*
LOCAL pixbuf TYPE GdkPixbuf*
LOCAL res TYPE int
pixloader = gdk_pixbuf_loader_new()
res = gdk_pixbuf_loader_write(pixloader, (unsigned char*)svg$, strlen((unsigned char*)svg$), 0)
res = gdk_pixbuf_loader_close(pixloader, 0)
pixbuf = gdk_pixbuf_loader_get_pixbuf(pixloader)
gdk_pixbuf_loader_close(pixloader, NULL)
RETURN pixbuf
END FUNCTION

Weird. Maybe the error is related to pixloader.

With kind regards,
vovchik

[alexfish]

Hi Vovchik

my valgrind results are above RE My original code adapted.

Now looking at your code.

if it be 'gdk_pixbuf_loader_close'? . I think not since that is the call to free it. I hope says he.

BR
Alex

[alexfish]

Hi Vovchik

RE GTK2
Your code with the adaption

' ------------------
FUNCTION SVG_BUFF(STRING svg$) TYPE GdkPixbuf*
' ------------------
' use global to free later
LOCAL pixloader TYPE GdkPixbufLoader*
' use global to free later
LOCAL pixbuf TYPE GdkPixbuf*
LOCAL size TYPE NUMBER
LOCAL res TYPE int
LOCAL raw_array TYPE unsigned char*
''size = LEN(svg$)
''raw_array = (unsigned char*)svg$
pixloader = gdk_pixbuf_loader_new()
res = gdk_pixbuf_loader_write(pixloader,(unsigned char*)svg$, strlen(svg$), 0)
res = gdk_pixbuf_loader_close(pixloader, 0)
pixbuf = gdk_pixbuf_loader_get_pixbuf(pixloader)
gdk_pixbuf_loader_close(pixloader, NULL)
RETURN pixbuf
END FUNCTION


Valgrind
==3598== HEAP SUMMARY:
==3598==     in use at exit: 53,474 bytes in 491 blocks
==3598==   total heap usage: 696 allocs, 205 frees, 71,486 bytes allocated
==3598==
==3598== LEAK SUMMARY:
==3598==    definitely lost: 0 bytes in 0 blocks
==3598==    indirectly lost: 0 bytes in 0 blocks
==3598==      possibly lost: 15,312 bytes in 94 blocks
==3598==    still reachable: 38,162 bytes in 397 blocks
==3598==         suppressed: 0 bytes in 0 blocks
==3598== Rerun with --leak-check=full to see details of leaked memory
==3598==
==3598== For counts of detected and suppressed errors, rerun with: -v
==3598== Use --track-origins=yes to see where uninitialised values come from
==3598== ERROR SUMMARY: 195019 errors from 164 contexts (suppressed: 409 from 1)

as mentioned earlier .gtk can show a loss :: but here get no erro . least of all since there is no recast of the svg$
BR
Alex

[alexfish]

Hi Vovchik

have compared with other gtk apps. here RPI responses only.

Re mem loss , from here there is indications of mem loss during the running. but no more than what I see in other gtk apps.

and the system survives , or appears to recoop most of the memory after exit

however previous demo's like the 'rotating cubes' are leaking memory like a water through a sieve.

I think these need to be fixed

not sure on this one but can check if the image was successful IE the write is complete

Signals like area-prepared area-updated or pixloader is closed
HERE
BR
Alex

[vovchik]

Dear Alex,

Thanks. I will have to fix those and post again. At least we know that the leakage was due mainly to the pixbuf handling, and you showed how to fix it.

With kind regards,
vovchik

[vovchik]

Dear all,

Here are some fixed guisvg demos - I created a new sub GUISVG that creates the pixbuf, updates the gui and handles the pixbuf unref. Everything is in the archive. I hope this goes some way in reducing/preventing memory leaks.

With kind regards,
vovchik

Attachments:

guisvg-demo.tar.gz (21.81 KB)

[alexfish]

Hi Vovchik

Thanks for the updates

On a Personal note RE Gtk Image::

looking back esp Stockfish and using a series of image's , and constant update.

Did we run into trouble there , can say from a RPI aspect 'Yes'

in the end had 'suspected' 'Image problem' . In short , images were put onto a 'layer' and as they say put image at xpos ypos

as a fix I destroyed the layer with the images , add new layer and add new images at where ever. gtk docs states the pixbuf is not owned
by the user ? even if you 'get' it ,

Some food for thought.

Re Cairo canvas , gtk drawing area and some demo's and including the gif demo, now retracted.

these do no show any memory loss like what I see when using gtk image in the fashion here

How about trying gtk drawing area and see what happens.

HTH +

BR
Alex

[vovchik]

Dear Alex,

Yes, there is something about GtkImages that is peculiar, and the release of the pixbuf. I will look at that drawing area and using cairo. I have some older stuff that I will try to port...and see what happens in valgrind.

With kind regards,
vovchik

[alexfish]

Hi Vovchik

Think you will manage to get there.

But.

If get stuck re compositing wise on the allocated cr , and or where to free the bits.

send me a PM. Saying that , I Can't say, I be perfect

BR
Alex

Forgot to mention

RE Timeout . although not 100% , looks like there could be a race condition or stepping problem >

[vovchik]

Dear Alex,

I think you are probably right about the timeout, although it could be something else as well. I am testing all sorts of GUI proxy gtk2/3 bits and see increasing memory use the longer these progs run. Thinking about this now...and wondering.

With kid regards,
vovchik

PS. Also seems to be happening with Motif, but more slowly.

[alexfish]

Hi Vovchik


Had to check the loader write function. as can say re the passing of the svg string

docs state that to be a 'const unsigned' char , so for testing pass as per docs.

gboolean
gdk_pixbuf_loader_write (GdkPixbufLoader *loader,
                        const guchar *buf,
                        gsize count,
                        GError **error);

there again do not think it will make any diff , but can rule this one out.

BR
Alex

[vovchik]

Dear Alex,

I modified GUISVG and stll get memory consumption:

' ------------------
SUB GUISVG(NUMBER gid, STRING widget$, STRING property$, STRING svg$)
' ------------------
LOCAL pixloader TYPE GdkPixbufLoader*
LOCAL pixbuf TYPE GdkPixbuf*
LOCAL res TYPE int
LOCAL svg TYPE const unsigned char*
svg = (const unsigned char*)svg$
pixloader = gdk_pixbuf_loader_new()
res = gdk_pixbuf_loader_write(pixloader, svg, strlen(svg), 0)
res = gdk_pixbuf_loader_close(pixloader, 0)
pixbuf = gdk_pixbuf_loader_get_pixbuf(pixloader)
gdk_pixbuf_loader_close(pixloader, NULL)
CALL GUISET(gid, widget$, property$, pixbuf)
g_object_unref(pixbuf)
END SUB

In any event, this seems to be cleaner. My attempts to dereference pixloader (GdkPixbufLoader) cause a runtime segfault.

With kind regards,
vovchik

[bigbass]

Hello vovchik and Alex

glad to see the improvements

I will move the other part of the post to documentation

Joe