Thanks for taking the time to report this bug.
Unfortunately, that stack trace is missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. Can you get us a stack trace with debugging symbols by installing debug packages for (lib)glib2 and (lib)gtk3? Please see http://live.gnome.org/GettingTraces for more information on how to do so and reopen this bug or report a new one. Thanks in advance!

I wasn' t able to reproduce this error. I just compile zenity from git using libgtk 3.4.0-0ubuntu3~oneiric1 package, and everything works as expected. Which version of ubuntu are you using? Perhaps is something wrong with this gtk/zenity version/package...

NEEDINFO status as per last comment

Hi all, 

here is a new stack trace with libglib2.0-0-dbg and libgtk-3-0-dbg. 
Same commands were used. hth. 

(gdb) bt

+ Trace 230047

Created attachment 212236 [details] [review]
Fix segmentation fault

I wasn't able to reproduce the bug in my machine, however, I verify that the code was using channel->is_readable which isn't the correct way.

Korobkin,

Can you please apply this patch and verify if will still get the segmentation fault?

Thanks, no segfaults with the patch!

Cool. the patch is already applied on master. I'm closing this bug.
Thanks for open the bug.

the fix for this causes endless loops
see: https://bugs.launchpad.net/ubuntu/+source/zenity/+bug/995435

you must mask the result of g_io_channel_get_flags not just compare for equality as more than one can be set (in this case is_seekable.

e.g. if(g_io_channel_get_flags(channel) & G_IO_FLAG_IS_READABLE)

+ Trace 230193

$2 = {
  ref_count = 2, 
  funcs = 0x7ffff6e1abc0, 
  encoding = 0x0, 
  read_cd = 0xffffffffffffffff, 
  write_cd = 0xffffffffffffffff, 
  line_term = 0x0, 
  line_term_len = 0, 
  buf_size = 1024, 
  read_buf = 0x0, 
  encoded_read_buf = 0x0, 
  write_buf = 0x0, 
  partial_write_buf = "\000\000\000\000\000", 
  use_buffer = 1, 
  do_encode = 0, 
  close_on_unref = 0, 
  is_readable = 1, 
  is_writeable = 0, 
  is_seekable = 1, 
  reserved1 = 0x0, 
  reserved2 = 0x0
}
(gdb) p (int)G_IO_FLAG_IS_READABLE
$4 = 4
(gdb) p g_io_channel_get_flags(channel)
$5 = 22

Created attachment 213706 [details] [review]
patch for busy loop

attached a patch against git head that fixes the issue for me

Thanks for the patch. It's already applied in the master.

*** Bug 675830 has been marked as a duplicate of this bug. ***

The endless loop with 100% CPU usage is still happening here in Ubuntu Trusty with Zenity 3.8.0-1.

Just run:

$ zenity --list --column X </dev/null

...and try to close Zenity, it won't close but stderr will be full of those:

(zenity:26465): GLib-WARNING **: /build/buildd/glib2.0-2.39.1/./glib/giounix.c:412Error while getting flags for FD: Bad file descriptor (9)

In the patch sent by Julian, I tried adding a sleep:

    while ((g_io_channel_get_flags(channel) & G_IO_FLAG_IS_READABLE) != G_IO_FLAG_IS_READABLE)
+        g_usleep(1000000);
      ;

...and after compiling and running:

$ zenity --list --column X </dev/null

...I only got one message per second on stderr, so I guess that "while" needs to also check if "channel" is a valid descriptor.

Could someone with enough rights change the bug status to *REOPENED*?

The fix for the initial problem caused an endless loop regression, and the patch by Julian doesn't eliminate all the cases where the endless loop happens.

Please reopen the bug report until the loop that I mentioned in comment #14 also checks if the file descriptor is valid.

In real life use, the endless loops happens about once per hour in a classroom of 10 students working with scratch/squeak (the squeak launcher calls zenity), and it's causing 100% CPU usage even after the zenity window is closed with xkill, so the students then complain that their workstation is too slow and the teacher needs to reboot it.

I can confirm comment 13 on Fedora 20.

Is it possible for you guys check the latest git code? I've tested here and it's working. I also test the Fedora 20, and the version shipped have this problem. I will release a new tarball soon with all the fixes, but meanwhile, I would like you guys to check the master instead of the version shipped with ubuntu and fedora.

I could not reproduce comment 13 with the latest git code, there's no problem there.
I can reproduce it in the latest version shipped with Ubuntu.

Thanks, please release the new tarball.

There's a new zenity tarball (3.12.1) who fix this problem, and a new one is on the way.
I'm closing this bug.