Emerges with no problems, but runs very, very slowly - if I run it, a blank space appears in the system tray, minutes later an icon appears, minutes later a blank window appears, minutes later I get bored and kill it. This happens whether my ~/.gaim dir is present or not. Portage 2.1.2_pre3-r7 (default-linux/ppc/ppc64/2006.0/64bit-userland/970/pmac, gcc-4.1.1, glibc-2.5-r0, 2.6.18-gentoo ppc64) ================================================================= System uname: 2.6.18-gentoo ppc64 PPC970FX, altivec supported Gentoo Base System version 1.12.5 Last Sync: Sun, 22 Oct 2006 22:00:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="ppc64 ~ppc64" AUTOCLEAN="yes" CBUILD="powerpc64-unknown-linux-gnu" CFLAGS="-O2 -mtune=970 -mcpu=970 -mabi=altivec -pipe" CHOST="powerpc64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -mtune=970 -mcpu=970 -mabi=altivec -pipe" DISTDIR="/mnt/shared/distfiles" FEATURES="autoconfig metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="ppc64 X alsa altivec apache2 apm berkdb bitmap-fonts cli cracklib cups dbus dlloader dri elibc_glibc emboss encode foomaticdb fortran gdbm gif gnome gpm gstreamer gtk hal imlib input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jpeg kde kernel_linux libg++ libwww mad mikmod motif mp3 mpeg ncurses nls nptl offensive ogg opengl oss pam pcre perl png pppd python qt3 quicktime readline reflection samba sdl session spell spl ssl tcpd tiff truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_ati video_cards_dummy video_cards_fbdev video_cards_mga video_cards_nv video_cards_sisusb video_cards_v4l vorbis xml xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I should really get more sleep...
Runs fine in a 32bit chroot. (i.e. ppc)
I can confirm this (stable system - gcc-3.4, glibc-2.3.6). Though I don't know how to debug. amd64: could one of you please try if this also happens in your 64bit userland (nomultilib profile)? If not, then I guess it is a toolchain issue.
Runs fine on amd64.
Runs fine here in 64-bit userland: Portage 2.1.2_pre3-r7 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.18-ck1-dfg3 x86_64) I have gotten several random crashes, but that's not abnormal for 64-bit gaim.
amd64: thanks for testing. removing you fron CC again.
(In reply to comment #3) > I can confirm this (stable system - gcc-3.4, glibc-2.3.6). Though I don't know > how to debug. > > amd64: could one of you please try if this also happens in your 64bit userland > (nomultilib profile)? If not, then I guess it is a toolchain issue. > If you would please emerge strace if not already installed and get me an strace to follow.
Created attachment 104523 [details] gaim-2.0.0_beta5-r1_strace.txt this is a backtrace of gaim running for about 3 minutes ( or that is to say: eating up my cpu for about 3 minutes ;-) ). then I killed it. don't know if this helps.
I dont see much.. can you try net-im/pidgin ?
Problem persists with net-im/pidgin-2.0.0_beta7
(In reply to comment #10) > Problem persists with net-im/pidgin-2.0.0_beta7 Still a problem w/ pidgin-2.0.2 ?
Yeah, problem still exists with net-im/pidgin-2.0.2
can someone from ppc64 investigate?
Well two of us that reported it are on the ppc64 team. I looked at it today and nothing jumped out at me. It does seem like bizarre behavior. Any advice on how you want us to investigate?
Still happening with pidgin 2.1.0. I ran it in gdb and broke after it "locked". A backtrace shows: #0 0x0000040000beda80 in .g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0 #1 0x0000040000d1e298 in .purple_savedstatus_new () from /usr/lib/libpurple.so.0 #2 0x0000040000d1e5e4 in .purple_savedstatus_get_default () from /usr/lib/libpurple.so.0 #3 0x0000040000d1e834 in .purple_savedstatus_get_current () from /usr/lib/libpurple.so.0 #4 0x00000000100ae654 in .pidgin_status_box_new () #5 0x00000000100af318 in .pidgin_status_box_new () #6 0x00000000100b0360 in .pidgin_status_box_new () #7 0x0000040000b577f4 in .g_type_create_instance () from /usr/lib/libgobject-2.0.so.0 #8 0x0000040000b384c4 in .g_object_set () from /usr/lib/libgobject-2.0.so.0 #9 0x0000040000b3660c in .g_object_newv () from /usr/lib/libgobject-2.0.so.0 #10 0x0000040000b37278 in .g_object_new_valist () from /usr/lib/libgobject-2.0.so.0 #11 0x0000040000b37388 in .g_object_new () from /usr/lib/libgobject-2.0.so.0 #12 0x00000000100ae248 in .pidgin_status_box_new () #13 0x0000000010048110 in .pidgin_blist_refresh () #14 0x0000000000000000 in ?? () So, perhaps an issue with the hashtable lookup? I'll keep digging.
Could you provide a strace log with -tt (ie timing info).. This bug is really strange.
may be a compiler thing where an infinite loop is generated ... i just ran it on my machine, and after all while, strace stops printing and pidgin starts chewing the cpu ... which means there's some code being executed in a tight loop w/out system calls ...
Did you make any progress? Or is there some ppc64 machine on which I could test?
(In reply to comment #18) > Did you make any progress? Or is there some ppc64 machine on which I could > test? > No, no progress. Just yesterday I tested pidgin 2.2.2 with some new versions of gcc/glibc etc, but it still fails. The ppc64 machine hosted at OSL is currently being replaced and I'm not sure, what the status is. You might want to join #gentoo-ppc64 and ask ranger, if he knows when the new machine comes online.
So, here's where I'm at with this bug, just to get it set in bugzilla: glib returns a hash reference, even when the item requested isn't currently hashed. This incorrect behavior is what causes the infinite looping. It doesn't appear to be a bug in pidgin, as far as I can tell.
*** Bug 189781 has been marked as a duplicate of this bug. ***
Created attachment 153843 [details, diff] Fixes the lockup on ppc64 This patch fixes the bug, but upstream wants a different approach. I'll update the bug once I've got something that's okay with upstream.
The actual problem is that the hash table implementation they're using uses int types for the hash keys, but in pidgin, they're using time_t. On 32 bit systems, this is fine, but on 64 bit systems, the value is truncated. On LE 64 bit systems, due to byte ordering, the least significant 32 bits are used, which is fine for the hash. On 64 bit systems, the most significant 32 bits are used, which causes it to loop for a *very* long time when adding new hash elements.
Created attachment 153873 [details, diff] Fixes the lockup on ppc64 (version submitted upstream)
hmm, so ppc64 is really the only arch we'd see this problem with huh ... no one really runs mips64/s390x/sparc64 64bit userlands let alone glib based packages like pidgin ... sucks to be ppc64 :)
Upstream included a variation on this patch with version 2.5.5, marked ~ppc64.
