glib: modular test fixtures?
Maybe I've just been up too late and am not thinking straight, but I suppose it doesn't hurt to ask... is there some way to use the Glib testing framework so as to have modular fixtures that could be combined or separated on a per-test basis? I'm staring at the API, but not seeing it. What I mean is: Say, I have test function A, which needs a fixture providing an open FILE stream, and test function B, which needs a fixture providing an character buffer, and test function C, which needs both. Ideally, I would be able to simply write a file stream fixture, and a character buffer fixture, and then somehow use both in test function C. Obviously, one approach would be to write a single fixture which provides both the FILE stream and the character buffer, and pass that to all functions. But then it starts to get complicated if, say, I add a test function D, which needs the same FILE stream, but a character buffer of a different size. Add enough functions, and I end up with a bunch of massive, clumsy fixtures (and fixture functions) that repeat a lot of the same code, yet differ slightly from each other. -- frigidcode.com indicium.us ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Help with a multi-threaded application. Spot a crash.
Hello, I have a multi-threaded application that filters data practically while user types text in an entry-field. But this applications regularly crashes. This surprises me because I have done similar code in another occacion and language. This particular Gtk code is from an open source app. So Would you help me to spot this annoying segmentation fault so I could move on. This seq-fault happens every time. $ ./test2 Came here 0 Came here 0 Came here 0 Came here 0 Came here 0 Came here 0 Came here 0 Came here 0 Came here 0 Came here 0 Came here 1 Came here 1 Segmentation fault Here is a complete test-code which I modelled after the actual application. It will show the crash. http://www.futuredesktop.org/tmp/test2.c Compile it for Gtk2: gcc -Wall test2.c -o test2 $(pkg-config --cflags --libs gtk+-2.0 gdk-2.0 gthread-2.0) Or for Gtk3: gcc -Wall test2.c -o test2 $(pkg-config --cflags --libs gtk+-3.0 gdk-3.0 gthread-2.0) And run: ./test2 TIA! All comments are welcomed. Kindly osmo antero http://www.futuredesktop.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Help with a multi-threaded application. Spot a crash.
Oh, I forgot to mension. Compile and start the test2 app and then press the Test... button at the top. It will fire 10 threads. Each of them creates own a GRegex object. Then the crash. // Osmo Antero ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Help with a multi-threaded application. Spot a crash.
On Wed, May 30, 2012 at 08:30:40PM +0100, Osmo Antero wrote: I have a multi-threaded application that filters data practically while user types text in an entry-field. But this applications regularly crashes. GRegex is not a GObject, it's just POD. So if (G_IS_OBJECT(search-regex)) will surely attempt to read some bogus memory location and crash. I cannot see why such code is there at all but anyway set search-regex to NULL if it does not exist and then just use if (search-regex) if necessary. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 05/29/2012 10:21 PM, Ben Pfaff wrote: Mikkel Kamstrup Erlandsenmikkel.kamst...@canonical.com writes: On 05/29/2012 07:23 PM, Ben Pfaff wrote: Mikkel Kamstrup Erlandsenmikkel.kamst...@canonical.com writes: I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. Is it possible to combine use of this GCC-specific attribute with the concept in Doug Gwyn's mostly-portable alloca implementation, so that you would end up with something that works pretty much everywhere (but is more efficient with GCC)? Here's one copy of the Doug Gwyn alloca that just happened to be on the top of the results of my web search: ftp://ftp.dante.de/tex-archive/fonts/utilities/ps2mf/alloca.c There is already g_alloca() and g_newa() for allocating on the stack. I'm not suggesting an implementation of an alloca-like function based on these ideas; as you say, glib already has alloca-like functions. I'm suggesting that one could use the idea behind the Doug Gwyn portable alloca to implement something like, or at least related to, the GCC cleanup attribute even when GCC is not the compiler in use. (However, the attribute syntax wouldn't work, and the interface would otherwise need to be different.) Sorry, I misunderstood you then :-) I am afraid the answer is no. alloca() does not provide a callback when cleaning up, and we need that for anything that needs a teradown function - which is basically everything that is not a string... Also this portable alloca() mentions in the docs that memory is not guaranteed to be freed when you leave the scope, but mayb happen higher up in the stack - and there even should be a mainloop driving garbage collection with alloca(0) as well. This means that the automagic lock management I added wouldn't work fx. Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 05/30/2012 05:17 AM, Paul Davis wrote: On Wed, May 30, 2012 at 3:22 AM, Mikkel Kamstrup Erlandsen mikkel.kamst...@canonical.com mailto:mikkel.kamst...@canonical.com wrote: alloca() does not provide a callback when cleaning up, and we need that for anything that needs a teradown function - which is basically everything that is not a string... those who refuse to acknowledge the role of the compiler in supporting object-oriented programming are doomed to repeat cfront :) What's wrong with cfront? I want cfront back! /me runs b ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: compiler optimization causing issues with glib
On Wed, May 30, 2012 at 6:43 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 24/05/12 17:20, Mike wrote: I am using glib 2.26.0 [...] The application I'm having issues with uses gdbus [...] - Thread stuck in futex wait inside kernel When I've attached GDB (or done SysRq), it's the gdbus thread that is stuck. If your application is calling GDBus APIs from more than one thread (it's unclear from your message whether it is or not), you should certainly upgrade. GDBus earlier than 2.32 has known thread-safety bugs, notably https://bugzilla.gnome.org/show_bug.cgi?id=665211. I use g_dbus_connection_emit_signal in the callback from g_child_watch_add. Does that occur in the main loop? Does the gdbus thread ever call back in to my code, or does it also go through the main loop? If you can't upgrade all the way to 2.32 right now for whatever reason, 2.28 or 2.30, or perhaps even a later 2.26.x version, would still be an improvement: for instance, https://bugzilla.gnome.org/show_bug.cgi?id=651268 and https://bugzilla.gnome.org/show_bug.cgi?id=662100 were both fixed since 2.28.0. I did attempt 2.28.0, same issue. I'll just have to upgrade my host tools and build 2.32. Still of course unclear whether I'm looking at a kernel or userspace issue. The part that bothers me the most is that simply sending a SIGCHLD to the gdbus thread causes it to wake up and function. Mike ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
wide characters in label
int main(int argc, char *argv[] ){
gtk_init (argc, argv);
setlocale(LC_CTYPE, UTF-8);
GtkWidget *window=gtk_window_new (GTK_WINDOW_TOPLEVEL);
GtkWidget *hbox=gtk_hbox_new (FALSE, 1);
wchar_t wide[]=Lthis is wide;
GtkWidget *label=gtk_label_new(wide);
gtk_container_add (GTK_CONTAINER (window), hbox);
gtk_box_pack_start (GTK_BOX (hbox), label, FALSE, FALSE, 0);
gtk_widget_show(label);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
--
View this message in context:
http://old.nabble.com/wide-characters-in-label-tp33926204p33926204.html
Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
Mikkel Kamstrup Erlandsen mikkel.kamst...@canonical.com writes: I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. Is it possible to combine use of this GCC-specific attribute with the concept in Doug Gwyn's mostly-portable alloca implementation, so that you would end up with something that works pretty much everywhere (but is more efficient with GCC)? Here's one copy of the Doug Gwyn alloca that just happened to be on the top of the results of my web search: ftp://ftp.dante.de/tex-archive/fonts/utilities/ps2mf/alloca.c ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
Mikkel Kamstrup Erlandsen mikkel.kamst...@canonical.com writes: On 05/29/2012 07:23 PM, Ben Pfaff wrote: Mikkel Kamstrup Erlandsenmikkel.kamst...@canonical.com writes: I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. Is it possible to combine use of this GCC-specific attribute with the concept in Doug Gwyn's mostly-portable alloca implementation, so that you would end up with something that works pretty much everywhere (but is more efficient with GCC)? Here's one copy of the Doug Gwyn alloca that just happened to be on the top of the results of my web search: ftp://ftp.dante.de/tex-archive/fonts/utilities/ps2mf/alloca.c There is already g_alloca() and g_newa() for allocating on the stack. I'm not suggesting an implementation of an alloca-like function based on these ideas; as you say, glib already has alloca-like functions. I'm suggesting that one could use the idea behind the Doug Gwyn portable alloca to implement something like, or at least related to, the GCC cleanup attribute even when GCC is not the compiler in use. (However, the attribute syntax wouldn't work, and the interface would otherwise need to be different.) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Text does not align in GTK label
Hello all Iam new here .. Iam experiencing a strange problem in a GTK label. I have created a label with justification as CENTER using glade. if I manually add text using glade then all is well with the label. but if the text is loaded from the program it seems to shift to the left of the label for some strange reason. Has anyone experienced such a problem. -- View this message in context: http://old.nabble.com/Text-does-not-align-in-GTK-label-tp33930871p33930871.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: wide characters in label
This is the wrong mailing list, dedicated to development of Gtk+. Your e-mail does not contain any question. So I suppose you want to know why your code is broken. On Tue, May 29, 2012 at 09:18:38AM -0700, jessCPP wrote: setlocale(LC_CTYPE, UTF-8); A bit strange and not actually influencing anything else in your code. wchar_t wide[]=Lthis is wide; Gtk+ works with UTF-8 encoded strings (i.e. sequences of bytes), *not* wide characters. wchar_t is an arbitrary poorly-defined platform-dependent type, making difficult to write a portable code. Do not use wide characters unless you have to. And if you have to then convert them to UTF-8 for use with Gtk+, e.g. using iconv with WCHAR_T as the source encoding. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: compiler optimization causing issues with glib
On Wed, May 30, 2012 at 9:12 AM, Mike puffy.t...@gmail.com wrote: On Wed, May 30, 2012 at 6:43 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 24/05/12 17:20, Mike wrote: I am using glib 2.26.0 [...] The application I'm having issues with uses gdbus [...] - Thread stuck in futex wait inside kernel When I've attached GDB (or done SysRq), it's the gdbus thread that is stuck. If your application is calling GDBus APIs from more than one thread (it's unclear from your message whether it is or not), you should certainly upgrade. GDBus earlier than 2.32 has known thread-safety bugs, notably https://bugzilla.gnome.org/show_bug.cgi?id=665211. I use g_dbus_connection_emit_signal in the callback from g_child_watch_add. Does that occur in the main loop? Does the gdbus thread ever call back in to my code, or does it also go through the main loop? If you can't upgrade all the way to 2.32 right now for whatever reason, 2.28 or 2.30, or perhaps even a later 2.26.x version, would still be an improvement: for instance, https://bugzilla.gnome.org/show_bug.cgi?id=651268 and https://bugzilla.gnome.org/show_bug.cgi?id=662100 were both fixed since 2.28.0. I did attempt 2.28.0, same issue. I'll just have to upgrade my host tools and build 2.32. Still of course unclear whether I'm looking at a kernel or userspace issue. The part that bothers me the most is that simply sending a SIGCHLD to the gdbus thread causes it to wake up and function. So I upgraded to 2.32.3. I seem to have the original problem and more unexplainable errors (there's a bit of time between each message, a second or so): (process:494): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (process:494): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (process:494): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (process:494): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (process:494): GLib-GIO-CRITICAL **: g_dbus_message_new_method_reply: assertion `G_IS_DBUS_MESSAGE (method_call_message)' failed (process:494): GLib-GIO-CRITICAL **: g_dbus_message_set_body: assertion `G_IS_DBUS_MESSAGE (message)' failed (process:494): GLib-GIO-CRITICAL **: g_dbus_connection_send_message: assertion `G_IS_DBUS_MESSAGE (message)' failed At the end is when it segfaulted. GDB claimed is crashed here #0 g_dbus_method_invocation_return_value_internal (invocation=0x28a00, parameters=0xbeb248d4, fd_list=0x0) at gdbusmethodinvocation.c:357 #1 0x8fc4 in handle_method_call (connection=0x1d800, sender=0x2a238 :1.11, object_path=0x2a8e0 /, interface_name=0x28538 org.example.Interface, method_name=0x2a770 Execute, parameters=0x18878, invocation=0x28a00, user_data=0x0) at main.c:166 #2 0x400fa470 in validate_and_maybe_schedule_method_call (connection=0x2a238, message=0x28a00, registration_id=100472, subtree_registration_id=value optimized out, interface_info=0x2a6f0, vtable=0x402e3330, main_context=0x8, user_data=0x40210de4) at gdbusconnection.c:4733 #3 0x402127ec in g_main_dispatch (context=0x0) at gmain.c:2539 #4 g_main_context_dispatch (context=0x0) at gmain.c:3075 #5 0x40215068 in g_main_context_iterate (context=0x19b70, block=1, dispatch=1, self=value optimized out) at gmain.c:3146 #6 0x402152d0 in g_main_loop_run (loop=0x1d2e8) at gmain.c:3340 #7 0x9154 in main () at main.c:234 The parameters variable is pointing at the stack -- no idea why as I recorded the value sent to that function and it definitely is not that one. I'm recompiling with -O0 to see if I can trap it with better debug. I'm setting up a laptop with a newer glib version and will run the same test there (of course, that is x86 not the target arch which is arm), just to make sure. I may end up recompiling everything just to make sure I don't have someone odd laying around. Mike ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
