Re: Threads and idle functions
Hi Igor, On Tuesday, 3 July 2012, Igor Chetverovod wrote Hi David, probably you should use macros: gdk_threads_enter () gdk_threads_leave (). Those macros were used to lock the main gdk thread in earlier versions of gtk if you wanted to call gtk_ functions from many threads. They are now deprecated, I think, and you are only supposed to call gtk functions from the main thread. They are not necessary for g_idle_add(). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 2.24.10 memory leak on win32?
code (that I think is correct) do not leak in linux (ubuntu 12.04, gtk 2.24.10) nor on win32 (GTK 2.16) while it leaks about 12kbyte/sec with GTK 2.24.10 on win32. G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --num-callers=32 src/your-binary I had already tested there was no leak in linux (same gtk version 2.24.10), with ps hat is not that accurate in the short term, but if you let your program run a pair of hours and both VSZ and RSS do not change I think it's accurate enough. Anyway I ran valgrind (without suppress file) for a pair of minutes and I got a positive result (at least I think): ==11727== HEAP SUMMARY: ==11727== in use at exit: 320,761 bytes in 5,570 blocks ==11727== total heap usage: 72,767 allocs, 67,197 frees, 3,161,964 bytes allocated ==11727== ==11727== LEAK SUMMARY: ==11727==definitely lost: 0 bytes in 0 blocks ==11727==indirectly lost: 0 bytes in 0 blocks ==11727== possibly lost: 9,848 bytes in 309 blocks ==11727==still reachable: 310,913 bytes in 5,261 blocks ... on win32 with gtk 2.24.10 (20120208 bundle from gtk.org) the program leaks about 10kb per sec, and as I said there is no leak also on win32 with 2.16.6 (20100207 bundle from gtk.org) -- Ing. Gabriele Greco, DARTS Engineering Tel: +39-0100980150 Fax: +39-0100980184 s-mail: Piazza Della Vittoria 9/3 - 16121 GENOVA (ITALY) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 2.24.10 memory leak on win32?
On 2 July 2012 15:44, Gabriele Greco gabriele.gr...@darts.it wrote: I'm posting the code here before creating a bugzilla entry for it since I'm not sure I can use g_idle_add to notify a new frame is available without freeing the source, that works in linux and in older WIN32 versions and it seems correct since g_idle_add() documentation says: Your code looks a bit strange, but I agree it should work with no leaks. Probably a bug. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 2.24.10 memory leak on win32?
... on win32 with gtk 2.24.10 (20120208 bundle from gtk.org) the program leaks about 10kb per sec, and as I said there is no leak also on win32 with 2.16.6 (20100207 bundle from gtk.org) Filed bug 679312 https://bugzilla.gnome.org/show_bug.cgi?id=679312 -- Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 2.24.10 memory leak on win32?
Your code looks a bit strange, but I agree it should work with no leaks. Probably a bug. In the real code there are 1 to X (up to 12) GdkImage(s) that are semaphore protected and filled by h264 decoders in different threads. Once the thread fills his GdkImage with the frame data it uses g_idle_add() to signal the GUI thread that the associated GdkDrawingArea has to be redraw, the idle function simply queue the draw of the widget and the expose event locks the gdkimage and do the real drawing. This works quite smoothly (25fps) with twelve 352x288 video inputs on any dual core PC . I pulled out all the threaded logic and made an example as simple as possible to trigger the problem, actually I could also remove the drawing itself, but it was useful to see that the program was not hung :) -- Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
