Bug #27724 for Gtk2: File chooser tests hang

Mon Jun 25 05:05:49 2007 djh [...] cpan.org - Ticket created

Subject:

Gtk2 fails install tests

I just installed Gtk2 1.144 on a Suse 10.2 AMD64 system and had problems with the FileChooser* tests: t/GtkEventBox......................ok t/GtkExpander......................ok t/GtkFileChooser...................skipped all skipped: unreliable GtkFileChooser test t/GtkFileChooserButton............. make: *** wait: No child processes. Stop. make: *** Waiting for unfinished jobs.... make: *** wait: No child processes. Stop. TSCH/Gtk2-1.144.tar.gz /usr/bin/make test -- NOT OK GtkFileChooserButton.t just hung. The log shows the result of CTRL-C. After removing that test, the following two tests also hung: t/FileChooserDialog.t t/GtkFileChooserWidget.t After removing all three, I got another ordinary failure: t/GtkIconTheme.....................ok 1/16 # Failed test at t/GtkIconTheme.t line 80. # got: 'exec' # expected: undef # Looks like you failed 1 test of 16. t/GtkIconTheme.....................dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 15 I force-installed the module and it seems to work, though I didn't try to use FileChoosers or icons. My test program says versions are as follows: Module version 1.144 Built for gtk+ 2.10.6 Running with gtk+ 2.10.6 and perl -V says: Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=linux, osvers=2.6.18, archname=x86_64-linux-thread-multi uname='linux eisler 2.6.18 #1 smp tue nov 21 12:59:21 utc 2006 x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -Wall -pipe' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement' ccversion='', gccversion='4.1.2 20061115 (prerelease) (SUSE Linux)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.5.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Nov 25 2006 11:02:03 %ENV: PERL5LIB="/home/dhoworth/progs/modules" PERLDOC_PAGER="vi" @INC: /home/dhoworth/progs/modules /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 /usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl . Let me know if there's any other information that would be useful. BTW, one other annoyance with the install process is that when it finds missing dependencies, it just stops instead of getting cpan to prepend them to the list. So I have to type every package name by hand. Cheers, Dave

Mon Jun 25 16:27:13 2007 kaffeetisch [...] gmx.de - Correspondence added

Subject:

File chooser tests hang

Show quoted text

> GtkFileChooserButton.t just hung. The log shows the result of CTRL-C. > After removing that test, the following two tests also hung: > > t/FileChooserDialog.t > t/GtkFileChooserWidget.t

Yeah, the file choose tests are known to be pretty unstable. I haven't seen hangs with the button, dialog, and widget tests though. Can you find out where they hang? You can run the tests manually, after you installed Gtk2, by simply executing them with perl: $ perl t/GtkFileChooserButton.t. Show quoted text

> After removing all three, I got another ordinary failure: > > t/GtkIconTheme.....................ok > 1/16 > # Failed test at t/GtkIconTheme.t line 80. > # got: 'exec' > # expected: undef > # Looks like you failed 1 test of 16.

This was fixed recently in CVS, I think.

Mon Jun 25 16:27:15 2007 The RT System itself - Status changed from 'new' to 'open'

Mon Jun 25 16:27:49 2007 kaffeetisch [...] gmx.de - Subject changed from 'Gtk2 fails install tests' to 'File chooser tests hang'

Mon Jun 25 17:38:40 2007 dave [...] howorth.org.uk - Correspondence added

Subject:	Re: [rt.cpan.org #27724] File chooser tests hang
Date:	Mon, 25 Jun 2007 22:38:12 +0100
To:	bug-Gtk2 [...] rt.cpan.org
From:	Dave Howorth <dave [...] howorth.org.uk>

On Mon, 2007-06-25 at 16:27 -0400, Torsten Schönfeld via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=27724 > >

> > GtkFileChooserButton.t just hung. The log shows the result of CTRL-C. > > After removing that test, the following two tests also hung: > > > > t/FileChooserDialog.t > > t/GtkFileChooserWidget.t

> > Yeah, the file choose tests are known to be pretty unstable. I haven't > seen hangs with the button, dialog, and widget tests though. Can you > find out where they hang? You can run the tests manually, after you > installed Gtk2, by simply executing them with perl: > > $ perl t/GtkFileChooserButton.t.

There's not much to go on. I tried perl -d but it hangs after the first c/n/s command without any output, even with trace on. Looks like the new() hangs: # perl -d GtkFileChooserButton.t Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. 1..9 main::(GtkFileChooserButton.t:9): my $dialog = Gtk2::FileChooserDialog -> new("Urgs", undef, "open", main::(GtkFileChooserButton.t:10): "gtk-cancel" => "cancel", main::(GtkFileChooserButton.t:11): "gtk-ok" => "ok"); DB<1> s [kill process] Terminated So I did an strace; HTH. Let me know if something else would be helpful. # strace perl GtkFileChooserButton.t 2> strace.log 1..9 [CTRL-C] strace.log attached Cheers, Dave

Download strace.log
application/x-perl 101k

Message body not shown because it is not plain text.

Mon Jul 02 14:23:05 2007 kaffeetisch [...] gmx.de - Correspondence added

Subject:	Re: [rt.cpan.org #27724] File chooser tests hang
Date:	Mon, 02 Jul 2007 20:22:39 +0200
To:	bug-Gtk2 [...] rt.cpan.org
From:	Torsten Schoenfeld <kaffeetisch [...] gmx.de>

On Mon, 2007-06-25 at 17:38 -0400, Dave Howorth via RT wrote: Show quoted text

> strace.log attached

Hmm, looks like the file chooser is hung in a futex() call, waiting for the lock to be released, which apparently never happens in your case. Can you use any of the file chooser widgets normally in an application? Can you try to come up with a small program that exhibits this bug? -- Bye, -Torsten

Tue Jul 03 08:05:41 2007 dave [...] howorth.org.uk - Correspondence added

Subject:	Re: [rt.cpan.org #27724] File chooser tests hang
Date:	Tue, 03 Jul 2007 12:30:39 +0100
To:	bug-Gtk2 [...] rt.cpan.org
From:	Dave Howorth <dave [...] howorth.org.uk>

On Mon, 2007-07-02 at 14:23 -0400, Torsten Schönfeld via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=27724 > > > On Mon, 2007-06-25 at 17:38 -0400, Dave Howorth via RT wrote: >

> > strace.log attached

> > Hmm, looks like the file chooser is hung in a futex() call, waiting for > the lock to be released, which apparently never happens in your case. > > Can you use any of the file chooser widgets normally in an application? > > Can you try to come up with a small program that exhibits this bug?

Well GtkFileChooserButton.t is fairly small! But I can reduce it to this: #!/usr/bin/perl -w use strict; use Gtk2 '-init'; my $dialog = Gtk2::FileChooserDialog -> new("Urgs", undef, "open", "gtk-cancel" => "cancel", "gtk-ok" => "ok"); Is that small enough? :) What's probably more interesting is that in writing this program I discovered that it works for me as a normal user but not as root (it hangs). I'm not sure what differences might be important. The perl -V printout is identical for root and myself. I've attached the output of env for both users; I can't see anything significant. I'm not sure what else might be relevant. Let me know if you'd like anything else. Cheers, Dave

Message body is not shown because sender requested not to inline it.

Thu Jul 05 16:38:32 2007 kaffeetisch [...] gmx.de - Correspondence added

Subject:	Re: [rt.cpan.org #27724] File chooser tests hang
Date:	Thu, 05 Jul 2007 22:38:03 +0200
To:	bug-Gtk2 [...] rt.cpan.org
From:	Torsten Schoenfeld <kaffeetisch [...] gmx.de>

On Tue, 2007-07-03 at 08:05 -0400, Dave Howorth via RT wrote: Show quoted text

> > Can you try to come up with a small program that exhibits this bug?

> > Well GtkFileChooserButton.t is fairly small!

Oh, right. :-) Show quoted text

> What's probably more interesting is that in writing this program I > discovered that it works for me as a normal user but not as root (it > hangs).

To rule out more alternatives, can you try the attached C program and see if it hangs as well? If so, a) it's not bindings related and b) you can try to get some more information with gdb. -- Bye, -Torsten

Message body is not shown because sender requested not to inline it.

Fri Jul 06 07:25:19 2007 dave [...] howorth.org.uk - Correspondence added

Subject:	Re: [rt.cpan.org #27724] File chooser tests hang
Date:	Fri, 06 Jul 2007 12:24:43 +0100
To:	bug-Gtk2 [...] rt.cpan.org
From:	Dave Howorth <dave [...] howorth.org.uk>

On Thu, 2007-07-05 at 16:39 -0400, Torsten Schönfeld via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=27724 > > To rule out more alternatives, can you try the attached C program and > see if it hangs as well? If so, a) it's not bindings related and b) you > can try to get some more information with gdb.

OK. It built cleanly (as normal user) and it runs as my normal user. It hangs when I run it as root. I'm not familiar with gdb but there's a log below. It hung when run, I typed CTRL-C then when I did bt it said there was an internal error in gdb. I guess that's not what you hope for? I tried again (see second log) and single-stepped main but it hung immediately. The third log is the result of single-stepping as a normal user. I'm not sure what to try next. Cheers, Dave ------------------------------------------------------- # gdb dialog GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) run Starting program: /home/dhoworth/progs/gtk/dialog-test/dialog [Thread debugging using libthread_db enabled] [New Thread 47081357781968 (LWP 20704)] Program received signal SIGINT, Interrupt. [Switching to Thread 47081357781968 (LWP 20704)] 0x00002ad1f9fe8a68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00002ad1f9fe8a68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00002ad1f9fe4a78 in _L_mutex_lock_106 () from /lib64/libpthread.so.0 dwarf2-frame.c:521: internal-error: Unknown CFI encountered. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) ----------------------------------------------------------------- [as root] (gdb) break main Breakpoint 1 at 0x40081c (gdb) run Starting program: /home/dhoworth/progs/gtk/dialog-test/dialog [Thread debugging using libthread_db enabled] [New Thread 47972515281872 (LWP 20742)] [Switching to Thread 47972515281872 (LWP 20742)] Breakpoint 1, 0x000000000040081c in main () (gdb) s Single stepping until exit from function main, which has no line number information. Program received signal SIGINT, Interrupt. --------------------------------------------------------------------- [as normal user] (gdb) break main Breakpoint 1 at 0x40081c (gdb) run Starting program: /home/dhoworth/progs/gtk/dialog-test/dialog [Thread debugging using libthread_db enabled] [New Thread 47618411293648 (LWP 20761)] [Switching to Thread 47618411293648 (LWP 20761)] Breakpoint 1, 0x000000000040081c in main () (gdb) s Single stepping until exit from function main, which has no line number information. [New Thread 1082132800 (LWP 20762)] [New Thread 1090525504 (LWP 20763)] 0x00002b4f05442ae4 in __libc_start_main () from /lib64/libc.so.6 (gdb)

Tue Jul 10 12:18:21 2007 kaffeetisch [...] gmx.de - Correspondence added

Subject:	Re: [rt.cpan.org #27724] File chooser tests hang
Date:	Tue, 10 Jul 2007 18:18:02 +0200
To:	bug-Gtk2 [...] rt.cpan.org
From:	Torsten Schoenfeld <kaffeetisch [...] gmx.de>

On Fri, 2007-07-06 at 07:25 -0400, Dave Howorth via RT wrote: Show quoted text

> OK. It built cleanly (as normal user) and it runs as my normal user. It > hangs when I run it as root. I'm not familiar with gdb but there's a log > below. It hung when run, I typed CTRL-C then when I did bt it said there > was an internal error in gdb. I guess that's not what you hope for?

Ouch. Never seen that before. The single stepping might work better if you compile the program with the -g switch so it gets debugging symbols. Also, if you can get a gtk+ installed with debugging symbols, a run with valgrind might provide some more information: $ valgrind --tool=memcheck --num-callers=100 ./dialog -- Bye, -Torsten

Wed Jul 11 18:32:54 2007 dave [...] howorth.org.uk - Correspondence added

Subject:	Re: [rt.cpan.org #27724] File chooser tests hang
Date:	Wed, 11 Jul 2007 23:32:34 +0100
To:	bug-Gtk2 [...] rt.cpan.org
From:	Dave Howorth <dave [...] howorth.org.uk>

On Tue, 2007-07-10 at 12:18 -0400, Torsten Schönfeld via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=27724 > > > On Fri, 2007-07-06 at 07:25 -0400, Dave Howorth via RT wrote: >

> > OK. It built cleanly (as normal user) and it runs as my normal user. It > > hangs when I run it as root. I'm not familiar with gdb but there's a log > > below. It hung when run, I typed CTRL-C then when I did bt it said there > > was an internal error in gdb. I guess that's not what you hope for?

> > Ouch. Never seen that before. > > The single stepping might work better if you compile the program with > the -g switch so it gets debugging symbols.

OK, it now reads: Breakpoint 1, main (argc=1, argv=0x7fff16499dd8) at dialog.c:10 10 gtk_init (&argc, &argv); (gdb) s 12 dialog = gtk_file_chooser_dialog_new ("Test", (gdb) s Program received signal SIGINT, Interrupt. 0x00002b0097903a68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00002b0097903a68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00002b00978ffa78 in _L_mutex_lock_106 () from /lib64/libpthread.so.0 Show quoted text

> Also, if you can get a gtk+ installed with debugging symbols, a run with > valgrind might provide some more information: > > $ valgrind --tool=memcheck --num-callers=100 ./dialog

Sadly, I'm having problems installing the gtk2-debuginfo package thanks to some version-dependency catch-22. Anders Johansson on the Suse list suggested I run an strace, which gave this: ... write(6, "\0", 1) = 1 write(6, "AUTH EXTERNAL 30\r\n", 18) = 18 poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(6, "OK edc29446c3e132dcf7020f13cb28b"..., 2048) = 37 poll([{fd=6, events=POLLOUT, revents=POLLOUT}], 1, -1) = 1 write(6, "BEGIN\r\n", 7) = 7 poll([{fd=6, events=POLLIN|POLLOUT, revents=POLLIN|POLLOUT|POLLHUP}], 1, -1) = 1 read(6, "", 2048) = 0 close(6) = 0 futex(0x6707d0, FUTEX_WAIT, 2, NULL <unfinished ...> and on that information he has deduced this: -------------------- Show quoted text

>On Wednesday 11 July 2007 22:40:40 Anders Johansson wrote:

>> It also shows that it happens immediately after failing to read

something Show quoted text

>> from dbus >> >> This should be solvable

> >Well, I have the reason, but not a solution > >root contacts the user's dbus session (since you did an su, instead of >su -, the environment variables are still there). > >dbus then does a getuid(), sees that someone other than the owner is >trying to talk to it, and proceeds to ignore it > >This is why it's hanging. Bad design in gtk if you ask me > >But the workaround would be to go to root using su -, and then launch a >new dbus using > >eval `dbus-launch --auto-syntax` > >After that, your gtk app will work as root as well as a user > >...and all this just using strace :)

------------------------ I've confirmed that using dbus-launch does indeed cause the application to work as root. I hope that helps solve the problem. I'll keep trying to figure out the package problems I'm having. BTW, somebody else on the Suse list says that this problem affects all gtk applications when the user is running a gnome session and tries to run the application as root. As soon as the user tries to access the file dialog, the application hangs. He used gedit as an example, which I've confirmed hangs. Cheers, Dave

Sun Jul 22 07:50:45 2007 kaffeetisch [...] gmx.de - Correspondence added

On Wed Jul 11 18:32:54 2007, dave@howorth.org.uk wrote: Show quoted text

> I've confirmed that using dbus-launch does indeed cause the application > to work as root. I hope that helps solve the problem. I'll keep trying > to figure out the package problems I'm having. > > BTW, somebody else on the Suse list says that this problem affects all > gtk applications when the user is running a gnome session and tries to > run the application as root. As soon as the user tries to access the > file dialog, the application hangs. He used gedit as an example, which > I've confirmed hangs.

OK, that confirms that this is not a problem in the bindings. If you wish, you can brings this up with the gtk+ developers: <http://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B>

Sun Jul 22 07:50:48 2007 kaffeetisch [...] gmx.de - Status changed from 'open' to 'resolved'