Some additional info:
This is gnome-games 2.17.1 compiled on gnome 2.16.1, though I doubt this combination really
has special effect on the crash. Besides, it seems this crash is not particularly useful;
when I have time I'll post a backtrace with debugging info enabled.

Even more info:
It's not related to four-in-a-row at all. This crash happens when inside ggz room frontend,
without launching any real game.

Hi Abel Cheung,

Thanks for testing the network support. If you find any other crashes, please submit bugreports about it. Also if you have any suggestions, I would be happy to try to improve the network support. The more bugs we can remove now this early in the release cycle, the better the network support will be in the final 2.18.0.

Surely this is a bug in libggz-gtk.  But without debugging symbols it won't be easy to trace.

I can get a related but different crash if I open the 'about' menu with a busted installation.

+ Trace 99213

The problem here is in about.c.

	colormap = gdk_colormap_get_system();
	pixmap = gdk_pixmap_new(widget->window, 250, 300, -1);
	bg_img = load_pixbuf("about_bg");
	if (bg_img == NULL)
		g_error("Couldn't create about background pixmap.");

In this case the about_bg file is simply not installed (it's a busted installation, I accidentally deleted it), and so the g_error here gets called.

But this shouldn't be a fatal error.  There should be a fallback.  Is there an error-message-without-crash that can be added here?  Whoever wrote this may not have realized that the code would crash with a core file for something that is not a code error.

-jason

Strangely, I am not able to reproduce this crash anymore. There have been many changes to gnect and the gnect server, and to the ggz library in the meantime. So it's possible that it has been fixed. 

Abel, could you please try to reproduce this crash again now? 

I'm now able to reproduce this crash again.

Here is a simple way to reproduce this bug:
1. start gnibbles
2. Select "Game -> Network game" on the menu.
3. Click Cancel
4. Select "Game -> Network game" on the menu (again).
5. Click the "Connect" button.

This results in a crash every time.

Here is the backtrace:

Starting program: /usr/local/bin/gnibbles 
[Thread debugging using libthread_db enabled]
[New Thread -1208771712 (LWP 3495)]

(gnibbles:3495): Pango-CRITICAL **: pango_layout_set_text: assertion `layout != NULL' failed

(gnibbles:3495): Pango-CRITICAL **: pango_layout_get_pixel_extents: assertion `PANGO_IS_LAYOUT (layout)' failed

Program received signal SIGSEGV, Segmentation fault.

+ Trace 103311

I get similar results in valgrind:

==19831== Invalid read of size 4
==19831==    at 0x442128: gtk_xtext_adjustment_set (xtext.c:759)
==19831==    by 0x448464: gtk_xtext_render_page_timeout (xtext.c:4681)
==19831==    by 0xC5FB6DA: g_timeout_dispatch (gmain.c:3488)
==19831==    by 0xC5FAFB1: g_main_context_dispatch (gmain.c:2061)
==19831==    by 0xC5FE2AC: g_main_context_iterate (gmain.c:2694)
==19831==    by 0xC5FE595: g_main_loop_run (gmain.c:2898)
==19831==    by 0x947CD61: gtk_main (gtkmain.c:1163)
==19831==    by 0x416856: main (main.c:1082)
==19831==  Address 0x14 is not stack'd, malloc'd or (recently) free'd

The complete line in question is:

adj->page_size =
    (GTK_WIDGET (buf->xtext)->allocation.height -
     buf->xtext->font->descent) / buf->xtext->fontsize;

My testing indicates that buf->xtext->font is NULL, so the access to buf->xtext->font->descent is invalid and causes the segfault. I think this is a red herring to be honest.

My understanding of what happens is this:

Doing "Game->Network game" calls gnibbles/ggz-network.c:on_network_game() which initialises the ggz-gtk dialogues and then sets the current GTK_NOTEBOOK page to NETWORK_PAGE unless ggz_network_mode is TRUE in which case it just sets the current GTK_NOTEBOOK page to NETWORK_PAGE as the dialogue has already been initialised.

Clicking the Cancel button on the login dialog (ie. NETWORK_PAGE) calls ggz-gtk/login.c:login_cancel_button_clicked() which goes on to call ggz_closed_cb() which has been set to gnibbles/ggz-network.c:ggz_closed(). ggz_closed() sets the current GTK_NOTEBOOK page to MAIN_PAGE (the normal dialogue you get when starting gnibbles), sets ggz_network_mode to FALSE and calls end_game(). end_game() eventually calls gnibbles/main.c:network_gui_update(), which uses ggz_network_mode to determine whether the some widgets should be shown or not.

When we next click "Game->Network game" ggz_network_mode is FALSE, so the ggz-gtk dialogues are reinitialised and probably duplicated on the GTK_NOTEBOOK.

By commenting out the "ggz_network_mode = FALSE;" line in ggz-network.c:ggz_closed() gnibbles no longer crashes using the procedure outlined by Andreas above, but the gui does do strange things when "Cancel" is pressed (the chat widget and other bits remain visible).


It's late now and I've been working on this for a few hours now so I've probably got a few details wrong but it does get to the heart of the problem. Hopefully that gives you enough information to figure out how to fix it.

Although I've been talking about gnibbles here instead of gnect, it's written just the same in gnect.

Created attachment 105426 [details] [review]
Possible fix against svn revision 7384.

The attached patch seems to work for both gnibbles and gnect, but I was unable to test it on iagno due to other problems.

Thanks Roger! The patch looks very good, and has been applied to SVN trunk:
http://svn.gnome.org/viewvc/gnome-games?view=revision&revision=7442

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

This bug is being reassigned to the "general" component so we can close the ggz bugzilla component.  Apologies for the mass email!