Bug#691576: [reverse-bisected] GDB stops with SIGTRAP at 0 address fixed with GCC 4.8
Hi, Please have a look at upstream bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799 I was asked to test GCC 4.8 and found this issue go away with locally-recompiled GCC 4.8.2 (upstream source, as ia64 is no more supported by Debian). Whether this was expected or not, I don't know. Feel free to discuss more in details with ia64/GCC gurus in upstream bug. Thanks, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: [bisected] GDB stops with SIGTRAP at 0 address
This has nothing to do with kernel version, but with gcc version, as alluded to nearly two years ago by Stephan Schreiber [1]... Upstream bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799 Émeric [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576#10 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
Hi, Probably message for posterity as nobody cares ia64 anymore, but gcc optimization isn't the cause of this, as alluded to earlier. While it seems to sometimes fix the problem, I'm now having various -O1-compiled kernels on Gentoo. Some exhibit the GDB issue, others don't. Émeric 2014-01-19 20:55 GMT+01:00 Kurt Roeckx k...@roeckx.be: On Sun, Jan 19, 2014 at 08:40:27PM +0100, Émeric MASCHINO wrote: [1] https://lists.debian.org/debian-68k/2013/05/msg00065.html === BTW, why is it archived on debian-68k? Because it was send to debian-ports@lists and not debian-ia64@lists like this, and debian-ports goes to all the porter lists including m68k and ia64. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736618: [ia64][patch] iceweasel-24.2.0esr-1 Web browsing simply doesn't work
Package: iceweasel
Version: 24.2.0esr-1
Severity: important
With today's Jessie updates, iceweasel was upgraded from 17 to 24.
Firefox 17 never worked on ia64 because of upstream bug #910845 [1].
Despite of Stephan Schreiber's hard work, his patches failed to be
merged in time for Firefox 17 release and thus to iceweasel 17.
Fortunately, these were merged upstream for Firefox 24, so I had great
hopes of upgrading my system from iceweasel 10 (last working on ia64)
to 24.
Well, it's simply impossible to surf the web with iceweasel 24 at the
moment: entering an URL in the URL edit box and then hitting the Enter
key or clicking the Go button has no effect at all. Similarly,
entering keywords in the Search edit box and hitting Enter or clicking
the Magnifying glass button has no effect either. It's noteworthy that
everything else (i.e. navigating Firefox menus and dialogs) seems to
work fine.
I was hitting the exact same issue on Gentoo, though with Firefox 26
[2], as I never succeeded in compiling Firefox 24 [3]. But I
nevertheless was more lucky on Gentoo as messages displayed in the
console quickly oriented me to upstream bug #812647 [4]. Original
patch didn't work and I was asked to test patch of upstream bug
#878791 [5] that fixed the problem for me.
iceweasel 26 isn't available in unstable for ia64, so I can't checked
whether patch for upstream bug #878791 has been merged by iceweasel
team or not. Would it be possible to ensure this, please, so I can
test either iceweasel 24 or 26 on ia64 again and report the results?
At the moment, setting severity to important as iceweasel is simply
unusable on ia64.
Émeric
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=910845
[2] https://bugs.gentoo.org/show_bug.cgi?id=497516
[3] https://bugs.gentoo.org/show_bug.cgi?id=497514
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=812647
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=878791
-- Package-specific info:
-- Extensions information
Name: Default theme
Location:
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled
Name: Français Language Pack locale
Location:
/usr/lib/iceweasel/browser/extensions/langpack...@iceweasel.mozilla.org.xpi
Package: iceweasel-l10n-fr
Status: enabled
-- Plugins information
Name: DivX® Web Player
Location: /usr/lib/mozilla/plugins/libtotem-mully-plugin.so
Package: totem-mozilla
Status: enabled
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled
Name: QuickTime Plug-in 7.6.6
Location: /usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so
Package: totem-mozilla
Status: enabled
Name: Shockwave Flash
Location: /usr/lib/lightspark/liblightsparkplugin.so
Package: browser-plugin-lightspark
Status: enabled
Name: VLC Multimedia Plugin (compatible Videos 3.8.2)
Location: /usr/lib/mozilla/plugins/libtotem-cone-plugin.so
Package: totem-mozilla
Status: enabled
Name: Windows Media Player Plug-in 10 (compatible; Videos)
Location: /usr/lib/mozilla/plugins/libtotem-gmp-plugin.so
Package: totem-mozilla
Status: enabled
-- Addons package information
ii browser-plugin 0.7.2-3 ia64 High-performance SWF player - Moz
ii gnome-shell3.8.4-5 ia64 graphical shell for the GNOME des
ii iceweasel 24.2.0esr-1 ia64 Web browser based on Firefox
ii iceweasel-l10n 1:24.2.0esr- all French language package for Icewe
ii totem-mozilla 3.8.2-3 ia64 Totem Mozilla plugin
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: ia64
Kernel: Linux 3.12-1-mckinley (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages iceweasel depends on:
ii debianutils 4.4
ii fontconfig 2.11.0-2
ii libatk1.0-0 2.10.0-2
ii libc6.1 2.17-97
ii libcairo21.12.16-2
ii libfontconfig1 2.11.0-2
ii libfreetype6 2.5.2-1
ii libgcc1 1:4.8.2-14
ii libgdk-pixbuf2.0-0 2.28.2-1+b1
ii libglib2.0-0 2.36.4-1
ii libgtk2.0-0 2.24.22-1
ii libnspr4 2:4.10.2-1
ii libnspr4-0d 2:4.10.2-1
ii libpango-1.0-0 1.36.0-1+b1
ii libpangocairo-1.0-0 1.36.0-1+b1
ii libpangoft2-1.0-01.36.0-1+b1
ii libsqlite3-0 3.8.2-1
ii libstdc++6 4.8.2-14
ii libunwind7 0.99-0.3
ii procps 1:3.3.4-2
ii xulrunner-24.0 24.2.0esr-1
iceweasel recommends no packages.
Versions of packages iceweasel suggests:
pn fonts-mathjax none
pn fonts-oflb-asana-math none
ii fonts-stix [otf-stix] 1.1.0-1
ii libgssapi-krb5-2 1.11.3+dfsg-3+nmu1
pn mozplugger none
Versions of packages xulrunner-24.0 depends on:
ii libasound21.0.27.2-3
ii libatk1.0-0 2.10.0-2
ii libbz2-1.0
Bug#691576: GDB still broken with 3.11.10-1
2014/1/12 Ben Hutchings b...@decadent.org.uk: If you have space to install wheezy on a separate partition, please can you try that. (Of course, that crash ought to be fixed in 3.2.y. But I don't know that anyone will have the time and knowledge to do so. And it's not part of this bug.) No more empty partition, so I managed to back up all my data and reinstall a fresh Wheezy 7.0.3 from the netinst CD. The issue with elilo that I reported back in May is still there [1]. Performed all the updates and install your -O1 kernel. Bang! Exact same crash as reported in [2]. Émeric [1] https://lists.debian.org/debian-68k/2013/05/msg00065.html === BTW, why is it archived on debian-68k? [2] https://lists.debian.org/debian-ia64/2014/01/msg9.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
2014/1/7 Ben Hutchings b...@decadent.org.uk: On Mon, 2014-01-06 at 10:15 +0100, Émeric MASCHINO wrote: I don't understand that - I still have 3.2 installed on this unstable (i386) system and can still boot it. How does it go wrong? It seems to crash with something wrong with systemd. You're getting in loop a callstack similar to the one starting at 32.334142, every ~28 seconds. And you can wait forever, never reaching login: Uncompressing Linux... done Loading file \EFI\debian\initrd.img.old...done [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-4-mckinley (debian-ker...@lists.debian.org) ( gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.51-1a~test [0.00] EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS= 0x3fb3a000 HCDP=0x3fb2c000 [0.00] booting generic kernel on platform hpzx1 [0.00] PCDP: v0 at 0x3fb2c000 [0.00] Explicit console=; ignoring PCDP [0.00] ACPI: RSDP 3fb2e000 00028 (v02 HP) [0.00] ACPI: XSDT 3fb2e02c 00094 (v01 HP zx6000 HP ) [0.00] ACPI: FACP 3fb36800 000F4 (v03 HP zx6000 HP ) [0.00] ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 (2011062 3/tbfadt-529) [0.00] ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 (2011062 3/tbfadt-529) [0.00] ACPI: DSDT 3fb2e0e0 05781 (v01 HP zx6000 0007 I NTL 02012044) [0.00] ACPI: FACS 3fb368f8 00040 [0.00] ACPI: SPCR 3fb36938 00050 (v01 HP zx6000 HP ) [0.00] ACPI: DBGP 3fb36988 00034 (v01 HP zx6000 HP ) [0.00] ACPI: APIC 3fb36a48 000B0 (v01 HP zx6000 HP ) [0.00] ACPI: SPMI 3fb369c0 00050 (v04 HP zx6000 HP ) [0.00] ACPI: CPEP 3fb36a10 00034 (v01 HP zx6000 HP ) [0.00] ACPI: SSDT 3fb33870 001D6 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb33a50 00342 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb33da0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb347c0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb351e0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb35c00 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb36620 000EB (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb36710 000EF (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: Local APIC address c000fee0 [0.00] 2 CPUs available, 2 CPUs total [0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs [0.00] Initial ramdisk at: 0xe040fdd01000 (19443165 bytes) [0.00] SAL 3.1: HP version 2.31 [0.00] SAL Platform features: None [0.00] SAL: AP wakeup using external interrupt vector 0xff [0.00] MCA related initialization done [0.00] Virtual mem_map starts at 0xa0007fffc720 [0.00] Zone PFN ranges: [0.00] DMA 0x0400 - 0x0004 [0.00] Normal 0x0004 - 0x0104 [0.00] Movable zone start PFN for each node [0.00] early_node_map[6] active PFN ranges [0.00] 0: 0x0400 - 0xfd79 [0.00] 0: 0xfec0 - 0xfecb [0.00] 0: 0x0004 - 0x0017 [0.00] 0: 0x0101 - 0x0103ff5a [0.00] 0: 0x0103ff6a - 0x0103ff84 [0.00] 0: 0x0103ffa0 - 0x0103fff0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pag es: 1512906 [0.00] Policy zone: Normal [0.00] Kernel command line: BOOT_IMAGE=scsi1:/EFI/debian/vmlinuz.old roo t=/dev/sdb2 console=ttyS0,9600 ro [0.00] PID hash table entries: 4096 (order: 1, 32768 bytes) [0.00] Memory: 25010192k/25105424k available (8557k code, 128096k reserv ed, 4496k data, 1088k init) [0.00] Hierarchical RCU implementation. [0.00] CONFIG_RCU_FANOUT set to non-default value of 32 [0.00] NR_IRQS:1024 [0.00] ACPI: Local APIC address c000fee0 [0.00] GSI 36 (level, low) - CPU 0 (0x) vector 49 [0.00] Console: colour VGA+ 80x25 [0.004000] Calibrating delay loop... 2246.65 BogoMIPS (lpj=4493312) [0.032028] pid_max: default: 32768 minimum: 301 [0.032211] Security Framework initialized [0.032223] AppArmor: AppArmor disabled by boot time parameter [0.033832] Dentry cache hash table entries: 4194304 (order: 11, 33554432 byt es) [0.065085] Inode-cache hash table entries: 2097152 (order: 10, 16777216 byte s) [0.080407] Mount-cache hash table entries: 1024
Bug#691576: GDB still broken with 3.11.10-1
2014/1/12 Ben Hutchings b...@decadent.org.uk: So this is a crash, not an incompatibility with the newer systemd. [...] Can you test the 3.2 kernel with sysvinit, in case this is a bug that's specifically provoked by systemd? That's why I was saying too old for my current Debian install on Jan 6th. Since I'm running GNOME 3.8, do you think I can safely reinstall and reboot with sysvinit or everything will be badly broken? Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
2014/1/12 Ben Hutchings b...@decadent.org.uk: You can have sysvinit and systemd installed in parallel and then use the 'init' kernel parameter to switch between them. Only systemd-sysv conflicts/replaces sysvinit. So, I've reinstalled sysvinit and sysvinit-core that purged systemd-sysv. I can't however remove systemd itself as it's required by numerous GNOME packages. I've rebooted my system and even reinstalled your -O1 kernel in order to be sure that initrd is regenerated. Still the same however! How is it that systemd-udevd still shows up? Emeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
2014/1/12 Ben Hutchings b...@decadent.org.uk: Sorry, I'm being silly. udev is built as part of systemd now, so this is independent of whether you use systemd as init. And systemd doesn't currently run as init in the initramfs. Uh, OK. How can I help further? Emeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
Hi, And happy new year! 2013/12/20 Ben Hutchings b...@decadent.org.uk: I actually tried building the kernel like that, so you could try the packages in: http://people.debian.org/~benh/packages/wheezy-ia64-kernel-O1/ Was your O1-compiled kernel working fine? I have no idea as no-one has reported their results yet. It seems that optimization settings have impact on this problem. Ben, I couldn't install your 3.2 kernel version (too old for my current Debian install). However, I've recompiled with -O1 a -O2 non-working kernel configuration on my Gentoo install. No problem with -O1 :-) Keep in mind that this is just an observation on a single kernel version/flavour at the moment. Future will tell us if this problem really comes up with optimization settings. Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
2013/12/12 Ben Hutchings b...@decadent.org.uk: So far as I know, there is no longer any commercial development of Linux on Itanium. Some old 'enterprise' distributions might continue to be supported for a few years but mainline isn't supported. It seems that Intel must provide hp with Itanium CPUs till 2017 [1][2]. With respect to this GDB problem, but also people having problem booting Wheezy on some systems, does it mean that nobody at Intel ensure that Linux still works fine with actual (and upcoming?) Itanium CPUs? Well, since hp is the major customer for Itanium CPUs, it's entirely plausible after all that hp focuses on hp-ux and thus Intel doesn't care about Linux on ia64. I heard from Will Deacon that gcc's code generation for ia64 has regressed in 4.6 or earlier and this may be responsible for some reported kernel bugs. He also though that reducing the optimisation level could help. I actually tried building the kernel like that, so you could try the packages in: http://people.debian.org/~benh/packages/wheezy-ia64-kernel-O1/ No, I didn't play with GCC optimization settings. Was your O1-compiled kernel working fine? Do you know if GCC regressions observed by Will Deacon are documented somewhere? Émeric [1] http://www.xbitlabs.com/news/cpu/display/20120201201109_HP_Paid_Intel_690_Million_to_Keep_Itanium_Alive_Court_Findings.html [2] http://www.wired.com/wiredenterprise/2012/02/hp-itanium/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
Ben, I was not reporting this as a reproach, but simply to track down which kernels work and which don't. From my records: - 2.6.38: KO (*) see below - 3.0.0-2: OK - 3.1.0-1: KO - 3.2.23: KO - 3.2.35-2: OK - 3.2.46-1+deb7u1: KO - 3.10.11-1: OK - 3.11.8-1: KO - 3.11.10-1: KO About upstream, I still don't understand how is it that this problem hasn't been talked about. I know I'm a bad programmer, but I would be very surprised being the only one needing GDB on ia64 ;-) I don't know if upstream people are subscribed to this list. When I asked on linux-ia64 which distro ia64 people are running [1], the only answer I got was from Raúl Porcel, the Gentoo-ia64 maintainer, nothing from Intel or hp developers. So I don't know how Linux/ia64 development is managed. Are Intel and hp people using a custom distro? Are they simply running Itanium systems? This is a legitimate question as I don't remember that they ever commented on this issue. Is it that they don't hit it? In fact, the only occurrence about this issue I can find on the linux-ia64 list is one of my remark in a post about a regression introduced with Sanitize cmpxchg_futex_value_locked API patch [2]. (*) And this was during kernel 2.6.38 development cycle! Bisecting back to such old kernel is simply impossible with today's udev and because of accept4 syscall was missing in 3.2.0-1 kernels. Also, as I reported some times ago [3], this issue is not specific to Debian kernels. In fact, a given kernel version can break GDB or not, depending upon its configuration (i.e. depending whether code is statically built or built as modules). Once again, I didn't get any comment on this, so don't know how I can help further: I'm not a kernel developer and have no knowledge of ia64 internals, except what I've read in ia-64 linux kernel book by David Mosberger and Stéphane Eranian, with a lot of things far behind my understanding. And even if I can go back as old as kernel 2.6.38, how to be sure that everything was definitely working fine then or just being lucky because of a working kernel configuration? Émeric [1] http://marc.info/?l=linux-ia64m=134858659916369w=2 [2] http://marc.info/?l=linux-ia64m=133124040906499w=2 [3] http://lists.debian.org/debian-ia64/2013/09/msg00024.html 2013/12/11 Ben Hutchings b...@decadent.org.uk: On Tue, Dec 10, 2013 at 11:36:37PM +0100, Émeric MASCHINO wrote: FYI, linux-image-3.11-2-mckinley 3.11.10-1 in today's Jessie updates didn't change anything w.r.t. gdb problem. Of course it didn't. If you want ia64 fixed then you'll have to talk to upstream or fix it yourself. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
FYI, linux-image-3.11-2-mckinley 3.11.10-1 in today's Jessie updates didn't change anything w.r.t. gdb problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: linux-image-mckinley 3.11+54 breaks gdb again
FYI, linux-image-3.11-2-mckinley 3.11.8-1 in today's Jessie updates breaks gdb again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724739: [regression] gnome-shell 3.8 unable to display 2560x1440 wallpapers
Hello,
Latest GNOME 3.8 packages hit Testing today and I'm now experiencing
the same issue than you on an ia64 workstation (FireGL1 X1 AGP
graphics adapter with 256MB VRAM, r300g driver). I'm however less
lucky than you as I'm not able to set a wallpaper bigger than
2560x1440 pixels (always get solid blue). It's noteworthy that
thumbnails and preview are OK.
As reported earlier on Gentoo [1], I don't think this is a hardware
limitation as suggested there, as gnome-themes-* were not updated
today and Adwaita wallpapers (that are 2560x1440 in size) were
displayed correctly with previous testing gnome-shell{-common}
3.4.2-16 and gnome-shell-extension 3.4.0-2 packages.
Émeric
[1] https://bugs.gentoo.org/show_bug.cgi?id=487190
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: linux-image-mckinley 3.10+52 is fine again with gdb
FYI, linux-image-3.10-3-mckinley 3.10.11-1 in today's Jessie updates brought back gdb to life. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719802: ia64, Iceweasel-17, JS needs ptrs have their high 17 bits cleared
Thanks Stephan, I'll test your patches. And I bet that the same will have to be done for Firefox ESR 21? BTW, I don't understand how upstream code is versioned. Shouldn't your original patches have been ported to the new JS engine by upstream when they released Firefox ESR 10 versions? Otherwise, what would prevent such breakages in the future with ESR 28, 35, ...? And the same for Webkit? I've reoppened bug 642750, as Epiphany status is as bad as Iceweasel ESR 17 since they switched from Webkit 1.8.1 to 2.0.4. Emeric 2013/8/28 Stephan Schreiber i...@fs-driver.org: retitle 719802 ia64, Iceweasel-17, JS needs ptrs have their high 17 bits cleared reassign 719802 src:iceweasel severity 719802 grave tags 719802 + patch thanks ia64. I experienced it, too. An assertion GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed Iceweasel 17esr crashed immediately before it shows its window on ia64. Furthermore the testsuite sometimes crashed when I built the unpatched iceweasel 17.0.8esr-2 on ia64. The failing assertion is *not* related with the crash. I didn't care about it. The reason for the crash is a known one: The Mozilla JS engine needs pointers have their high 17 bits cleared because it would break a variant data type which the engine uses. The patch doesn't fix the failing assertion. It will still occur, but the crash is gone. The patch is also important for the libmozjs17d package which will be used by gnome-shell soon. The patch is similar to some bugfixes of earlier versions: bug#696041 ia64 (Itanium) Mozilla JS engine needs pointers have their high 17 bits cleared bug#659186 gnome-shell: Segmentation fault in libmozjs185.so.1.0 at startup Noam Postavsky wrote: I'm having the same symptoms (same assertion failure and crash at startup) on amd64. The amd64 arch isn't affected by the ia64 crash which this patch addresses, believe me ;-) I suggest filing a separate bug report for the crash on amd64. Cheers Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642750: epiphany-browser once again unusable on ia64
Hi, With the switch from WebKit 1.8.1 to 2.0.4, instability is back on IA-64: Epiphany simply can't open any URL without crashing (cf. the attached gdb output when trying to go to http://www.gnome.org). Émeric Starting program: /usr/bin/epiphany-browser warning: Could not load shared library symbols for linux-gate.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/ia64-linux-gnu/libthread_db.so.1. [New Thread 0x2ade2f10 (LWP 2116)] [New Thread 0x2ba02f10 (LWP 2117)] [New Thread 0x2000147fef10 (LWP 2120)] [New Thread 0x200015f02f10 (LWP 2121)] [New Thread 0x200016906f10 (LWP 2125)] [Thread 0x200015f02f10 (LWP 2121) exited] [New Thread 0x200015f02f10 (LWP 2127)] [New Thread 0x20002c2fef10 (LWP 2128)] [New Thread 0x20002cefef10 (LWP 2129)] [New Thread 0x20002d6fef10 (LWP 2130)] [New Thread 0x20002defef10 (LWP 2131)] [New Thread 0x20002e6fef10 (LWP 2132)] [New Thread 0x20002eefef10 (LWP 2133)] Program received signal SIGSEGV, Segmentation fault. 0x21223121 in WebCore::getCachedDOMStructure(WebCore::JSDOMGlobalObject*, JSC::ClassInfo const*) () from /usr/lib/libwebkitgtk-3.0.so.0 #0 0x21223121 in WebCore::getCachedDOMStructure(WebCore::JSDOMGlobalObject*, JSC::ClassInfo const*) () from /usr/lib/libwebkitgtk-3.0.so.0 #1 0x2124fd80 in WebCore::toJS(JSC::ExecState*, WebCore::JSDOMGlobalObject*, WebCore::Document*) () from /usr/lib/libwebkitgtk-3.0.so.0 #2 0x212c3470 in WebCore::createWrapper(JSC::ExecState*, WebCore::JSDOMGlobalObject*, WebCore::Node*) () from /usr/lib/libwebkitgtk-3.0.so.0 #3 0x21238b10 in WebCore::JSDOMWindowBase::updateDocument() () from /usr/lib/libwebkitgtk-3.0.so.0 #4 0x21315d70 in WebCore::ScriptController::initScript(WebCore::DOMWrapperWorld*) () from /usr/lib/libwebkitgtk-3.0.so.0 #5 0x21316c50 in WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const, WebCore::DOMWrapperWorld*) () from /usr/lib/libwebkitgtk-3.0.so.0 #6 0x21317440 in WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const) () from /usr/lib/libwebkitgtk-3.0.so.0 #7 0x2186c270 in WebCore::ScriptElement::executeScript(WebCore::ScriptSourceCode const) () from /usr/lib/libwebkitgtk-3.0.so.0 #8 0x21d3c440 in WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent(WebCore::PendingScript) () from /usr/lib/libwebkitgtk-3.0.so.0 #9 0x21d3cf30 in WebCore::HTMLScriptRunner::executeParsingBlockingScript() () from /usr/lib/libwebkitgtk-3.0.so.0 #10 0x21d3d870 in WebCore::HTMLScriptRunner::executeParsingBlockingScripts() () from /usr/lib/libwebkitgtk-3.0.so.0 #11 0x21d3d8f0 in WebCore::HTMLScriptRunner::executeScriptsWaitingForStylesheets() () from /usr/lib/libwebkitgtk-3.0.so.0 #12 0x21d05cf0 in WebCore::HTMLDocumentParser::executeScriptsWaitingForStylesheets() () from /usr/lib/libwebkitgtk-3.0.so.0 #13 0x217340a0 in WebCore::Document::didRemoveAllPendingStylesheet() () from /usr/lib/libwebkitgtk-3.0.so.0 #14 0x217749f0 in WebCore::DocumentStyleSheetCollection::removePendingSheet(WebCore::DocumentStyleSheetCollection::RemovePendingSheetNotificationType) () from /usr/lib/libwebkitgtk-3.0.so.0 #15 0x21c08350 in WebCore::HTMLLinkElement::removePendingSheet(WebCore::HTMLLinkElement::RemovePendingSheetNotificationType) () from /usr/lib/libwebkitgtk-3.0.so.0 #16 0x21c08430 in WebCore::HTMLLinkElement::sheetLoaded() () from /usr/lib/libwebkitgtk-3.0.so.0 #17 0x216a2d20 in WebCore::StyleSheetContents::checkLoaded() () from /usr/lib/libwebkitgtk-3.0.so.0 #18 0x216a2b00 in WebCore::StyleSheetContents::checkLoaded() () from /usr/lib/libwebkitgtk-3.0.so.0 #19 0x21697f70 in WebCore::StyleRuleImport::setCSSStyleSheet(WTF::String const, WebCore::KURL const, WTF::String const, WebCore::CachedCSSStyleSheet const*) () from /usr/lib/libwebkitgtk-3.0.so.0 #20 0x21699ec0 in WebCore::StyleRuleImport::ImportedStyleSheetClient::setCSSStyleSheet(WTF::String const, WebCore::KURL const, WTF::String const, WebCore::CachedCSSStyleSheet const*) () from /usr/lib/libwebkitgtk-3.0.so.0 #21 0x220a2190 in WebCore::CachedCSSStyleSheet::checkNotify() () from /usr/lib/libwebkitgtk-3.0.so.0 #22 0x220a19d0 in WebCore::CachedCSSStyleSheet::data(WTF::PassRefPtrWebCore::ResourceBuffer, bool) () from /usr/lib/libwebkitgtk-3.0.so.0 #23 0x221f1d00 in WebCore::SubresourceLoader::didFinishLoading(double) () from /usr/lib/libwebkitgtk-3.0.so.0 #24 0x221d4780 in WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle*, double) () from /usr/lib/libwebkitgtk-3.0.so.0 #25 0x2382e930 in WebCore::readCallback(_GObject*, _GAsyncResult*, void*) () from /usr/lib/libwebkitgtk-3.0.so.0 #26 0x25b1f320 in
Bug#719802: [ia64] Iceweasel ESR 17 crashes at startup
Package: iceweasel Version: 17.0.8esr-2 Today's Jessie Testing updates upgraded Iceweasel ESR from 10 to 17. Unfortunately, Iceweasel 17 simply fails to start. Please find in attached the gdb output. If helpful, I'm getting the following error if Iceweasel is started from a terminal, just before the segmentation fault: GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed For records, previous Iceweasel ESR 10, or more precisely JS engine, was badly broken on ia64 for a long time (please have a look at bugs 696041 and 692053 for details). From what I understand there, JS engine in ESR 17 is far from ESR 10 one. As such, patches submitted to fix bug 696041 and 692053 cannot be applied. Most notably, patch allowing to turn off static strings allocation on ia64 is irrelevant, since static strings allocation was removed [1]. As already outlined earlier [2], such changes may broke JS engine on ia64 again. Is this what I'm seeing there? [1] http://hg.mozilla.org/mozilla-central/rev/3c429287dfbe [2] https://bugzilla.mozilla.org/show_bug.cgi?id=675806#c6 -- Package-specific info: -- Addons package information -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: ia64 Kernel: Linux 3.9-1-mckinley (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages iceweasel depends on: ii debianutils 4.4 ii fontconfig 2.10.2-2 ii libatk1.0-0 2.8.0-2 ii libc6.1 2.17-92 ii libcairo21.12.14-4 ii libfontconfig1 2.10.2-2 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.8.1-2 ii libgdk-pixbuf2.0-0 2.28.2-1 ii libglib2.0-0 2.36.3-3 ii libgtk2.0-0 2.24.20-1 ii libnspr4 2:4.10-1 ii libnspr4-0d 2:4.10-1 ii libpango-1.0-0 1.32.5-5+b1 ii libpangocairo-1.0-0 1.32.5-5+b1 ii libpangoft2-1.0-01.32.5-5+b1 ii libsqlite3-0 3.7.17-1 ii libstdc++6 4.8.1-2 ii libunwind7 0.99-0.3 ii procps 1:3.3.4-2 ii xulrunner-17.0 17.0.8esr-2 iceweasel recommends no packages. Versions of packages iceweasel suggests: ii fonts-stix [otf-stix] 1.1.0-1 ii libgssapi-krb5-2 1.10.1+dfsg-6.1 ii mozplugger 1.14.5-1 Versions of packages xulrunner-17.0 depends on: ii libasound21.0.27.1-2 ii libatk1.0-0 2.8.0-2 ii libbz2-1.01.0.6-4 ii libc6.1 2.17-92 ii libcairo2 1.12.14-4 ii libdbus-1-3 1.6.12-1 ii libdbus-glib-1-2 0.100.2-1 ii libevent-2.0-52.0.21-stable-1 ii libfontconfig12.10.2-2 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.8.1-2 ii libgdk-pixbuf2.0-02.28.2-1 ii libglib2.0-0 2.36.3-3 ii libgtk2.0-0 2.24.20-1 ii libhunspell-1.3-0 1.3.2-4 ii libjpeg8 8d-1 ii libmozjs17d 17.0.8esr-2 ii libnspr4 2:4.10-1 ii libnss3 2:3.15-1 ii libnss3-1d2:3.15-1 ii libpango-1.0-01.32.5-5+b1 ii libpangocairo-1.0-0 1.32.5-5+b1 ii libpangoft2-1.0-0 1.32.5-5+b1 ii libpixman-1-0 0.26.0-4 ii libsqlite3-0 3.7.17-1 ii libstartup-notification0 0.12-3 ii libstdc++64.8.1-2 ii libunwind70.99-0.3 ii libvpx1 1.2.0-2 ii libx11-6 2:1.6.0-1 ii libxext6 2:1.3.2-1 ii libxrender1 1:0.9.8-1 ii libxt61:1.1.3-1+deb7u1 ii zlib1g1:1.2.8.dfsg-1 Versions of packages xulrunner-17.0 suggests: ii libcanberra0 0.30-2 pn libgnomeui-0 none -- no debconf information GNU gdb (GDB) 7.6 (Debian 7.6-5) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as ia64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/lib/iceweasel/iceweasel...Reading symbols from /usr/lib/debug/usr/lib/iceweasel/iceweasel...done. done. (gdb) run Starting program: /usr/lib/iceweasel/iceweasel warning: Could not load shared library symbols for linux-gate.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/ia64-linux-gnu/libthread_db.so.1. [New Thread 0x2990b1d0 (LWP 2732)] [New Thread 0x2a55f1d0 (LWP 2733)] [New Thread 0x2ad5f1d0 (LWP 2734)] [New Thread 0x2b5e31d0 (LWP 2735)] [New Thread 0x2d0031d0
Bug#642750: epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Hi and happy new year, I've tested latest patchset from Stephan. Epiphany runs as great as with the v2 patchset. I'm however still getting the curious Google homepage crash I was talking about previously. Uninstalling gnash didn't help. But overall, Stephan work is a _huge_ improvement w.r.t. what we had before! Kudos to him. Best regards, Emeric 2013/1/2 Stephan Schreiber i...@fs-driver.org: I filed bug#697172 for yet another bug of webkit. Furthermore, bug#697173 for a bug in the epiphany-browser package. Furthermore, bug#697174 in order to enable seed on ia64. I also realized that gnash seems to crash epiphany sometimes. I browsed through the Debian bug reports and found ones which blame gnash to make the webkit based browsers unstable - epiphany-bowser on Gnome and Konqueror on KDE: bug#594822, 655839, 549309. I removed both gnash and gnash-common from my computer and realized a real improvement of epiphany's behaviour. But I still experienced some trouble, for example, a reproducable hang-up and a crash a few seconds subsequently: Enter www.kununu.de; enter a company name in the top right search edit box; enter; click on a company's name - hang-up, crash. I tried Fedora 17 i386 on another box (epiphany-browser 3.4.3; webkit 1.8.3; gnash isn't installed): same behaviour. It isn't an ia64 specific bug. I think epiphany-browser/webkit with all patches runs on ia64 as stable as on x86; this is the best we can do at the moment. A summary of the patches we had so far: webkit, this bug report 01-ia64-wide-ptr.patch 02-ia64-use-system-malloc.patch webkit, bug#694971 large-mem-page.patch webkit, bug#697172 thread-safe-icon-db.patch seed, bug#582774 seed no longer FTBFS without any change epiphany-browser, bug#697173 history-thread-startup-race.patch epiphany-browser, bug#697174 enabling seed in debian/rules If you want to test it, you can download the built debs: http://www.fs-driver.org/debian-ia64/webkitgtk-debs-v3.tar http://www.fs-driver.org/debian-ia64/seed-debs.tar http://www.fs-driver.org/debian-ia64/epiphany-debs.tar Remember to remove both gnash and gnash-common before you test it. Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692053: [ia64] Iceweasel 10.0 (and above?) randomly stops responding, eating 100% CPU
Hi, I've applied Stephan patches and recompiled Iceweasel. I used it for one week now without any problem. I even ran WebGL conformance test suite successfully whereas vanilla Iceweasel isn't able to complete it after a few tests. Notice however that, when I say successfully, I mean the process of running the tests. This doesn't mean that all tests passed successfully, but this is not related to this bug report ;-) Thank you again Stephan for your hard work. Emeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642750: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64, (IA-64/IPF/Itanium) platform
Hi Stephan,
I used your patched packages the passed week for my homeworks.
Stability is far better than the first patchset. With the notable
exception of the Google homepage. I don't know what's going wrong and
if other URLs are also affected. Let me explain.
Opening Epiphany with a blank page as startup page, typing
www.google.com in the bar address and clicking on Enter briefly goes
to the Google homepage and Epiphany immediately crashes. This is not a
history problem as going to the e.g. Debian homepage from the blank
page runs as expected. Then, from the Debian homepage, if you try to
go to the Google homepage, Epiphany crashes.
Now, the funny thing: from the blank page, if you visit the GMail
homepage first, and then the Google homepage, no problem! You can even
go back to the blank page and then visit the Google homepage without
crashing Epiphany. So the position in the history doesn't matter. I
don't know what the GMail homepage triggers that makes the Google
homepage work, but here is it. Just a remark: you don't have to visit
the GMail homepage right before the Google homepage. You can visit
other homepages in between. It's just that if you didn't visit the
GMail homepage before going to the Google homepage, Epiphany will
crash.
I know it's not a fantastic information, but that's the only
reproducible scenario I have that makes Epiphany crashes with your
updated packages.
Let me know if additional tests are welcomed.
Émeric
2012/12/7 Stephan Schreiber i...@fs-driver.org:
Émeric Maschino wrote:
Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report
I looked for anything that is different on a release build and on a debug
build. It turned out that a lot of code related to the memory heap is
different in Source/JavaScriptCore/wtf/FastMalloc.cpp:
#if !(defined(USE_SYSTEM_MALLOC) USE_SYSTEM_MALLOC) defined(NDEBUG)
#define FORCE_SYSTEM_MALLOC 0
#else
#define FORCE_SYSTEM_MALLOC 1
#endif
(Consider NDEBUG.)
Webkit doesn't use its own heap implementation in FastMalloc.cpp on the
debug build! When someone builds the release build all the buggy code runs
and will make trouble.
This was done to make debugging much easier :-). (Greetings from Google's
sadists club.)
I didn't try to find all bugs in the fast malloc implementation. One thing I
noticed which could break it on ia64 but works on x86-64 is the following in
Source/JavaScriptCore/wtf/FastMalloc.cpp:1375:
// Return 0 if we have no information, or else the correct sizeclass for
p.
// Reads and writes to pagemap_cache_ do not require locking.
// The entries are 64 bits on 64-bit hardware and 16 bits on
// 32-bit hardware, and we don't mind raciness as long as each read of
// an entry yields a valid entry, not a partially updated entry.
size_t GetSizeClassIfCached(PageID p) const {
return pagemap_cache_.GetOrDefault(p, 0);
}
void CacheSizeClass(PageID p, size_t cl) const { pagemap_cache_.Put(p,
cl); }
When different processor cores access one memory location - one processor at
first, the second one at next - the processor cores excange the data through
their caches as needed with their bus protocol automatically on x86 and
x86-64.
But on ia64 caches are not coherent automatically, the caches are flushed
using memory barriers (some special machine instructions).
When you use some dispatcher objects, for example, a mutex with the
following pattern
- acquire the dispatcher object
- read/write to the data location which are guarded by the dispatcher
object,
- release the dispatcher object
you don't need to think on the cache coherency and memory barriers. The
implementation of the dispatcher object does the memory barriers correctly
for you.
When you start to do something own what has multiple threads but doesn't use
any dispatcher object, you have to think on memory barriers. Ia64 isn't the
only arch that requires this.
One approach would be building-in the needed memory barrier in
FastMalloc.cpp. This would mean adding memory barrier definitions for a lot
of architectures. You can take a look at the hw/xfree86/common/compiler.h
file of the xserver-xorg-core package in order to get an idea what it would
mean.
So the second approach: We do no longer use the fast malloc implementation
on ia64 as it is already done on Blackberry OS and on the Qt port of webkit
on any OS other than UNIX.
An appropriate modification can be useful as well on other archs that
require memory barriers, for example, alpha, powerpc.
So here is a new set of patches:
01-ia64-wide-ptr.patch at first,
02-ia64-use-system-malloc.patch at next.
The patches are for the most recent libwebkitgtk-3.0-0 package of Wheezy.
The patches don't change anything on archs other than ia64.
The packages which were built with the patch of this bug report and the one
of bug#694971 are here; the tar contains all debs which
Bug#642750: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Thanks Stephan for your hard work.
I just tested Epiphany with the updated packages that you provided in
[1]. Are they self-contained or is yet another updated package
missing?
Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report, albeit you don't have to
click again on Debian URL to make it crash. Simply going back to the
Google results page and waiting a little bit is sufficient to trigger
the crash.
And unfortunately, trying to get an informative stacktrace in gdb, I'm
now hitting the SIGTRAP issue [2] :-(
Émeric
[1] http://www.fs-driver.org/debian-ia64/webkitgtk-debs.tar
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576
2012/12/2 Stephan Schreiber i...@fs-driver.org:
severity 642750 grave
tags 642750 + patch
block 582774 by 642750
thanks
While working on this bug I realized that webkit has yet another bug that
prevents it from working on ia64. I filed the separate bug#694971 for that.
I built the libwebkitgtk-3.0-0 package which was configured with
--enable-debug. (Wasn't possible with the initial 4GB of memory at all.
After a memory upgrade to 16GB it took eleven-and-a-half hour on my box with
the -j2 option.)
Just starting epiphany-browser showed a first hint what is going on:
ASSERTION FAILED: isCell()
../Source/JavaScriptCore/runtime/JSValueInlineMethods.h(491) : JSC::JSCell*
JSC::JSValue::asCell() const
Webkit uses a variant data type JSValue, which it uses for anything that can
be a thing on Java script. It can contain an integer number, a float number
or a pointer to an object - this is 'cell'.
It turned out that the 'isCell()' assertion failed for a JSValue that just
has been initialized as a pointer.
The arch determines how the JSValue is defined; there are two options (yet),
one for any 32-bits arch, the other one for 64-bits archs.
You can see this in Source/JavaScriptCore/runtime/JSValue.h - JSValue
defines an embedded data type 'EncodedValueDescriptor' for that:
#if USE(JSVALUE32_64)
typedef int64_t EncodedJSValue;
#else
typedef void* EncodedJSValue;
#endif
union EncodedValueDescriptor {
int64_t asInt64;
#if USE(JSVALUE32_64)
double asDouble;
#elif USE(JSVALUE64)
JSCell* ptr;
#endif
#if CPU(BIG_ENDIAN)
struct {
int32_t tag;
int32_t payload;
} asBits;
#else
struct {
int32_t payload;
int32_t tag;
} asBits;
#endif
};
#if USE(JSVALUE32_64)
/*
* On 32-bit platforms USE(JSVALUE32_64) should be defined, and we
use a NaN-encoded
* form for immediates.
*
* The encoding makes use of unused NaN space in the IEEE754
representation. Any value
* with the top 13 bits set represents a QNaN (with the sign bit
set). QNaN values
* can encode a 51-bit payload. Hardware produced and C-library
payloads typically
* have a payload of zero. We assume that non-zero payloads are
available to encode
* pointer and integer values. Since any 64-bit bit pattern where
the top 15 bits are
* all set represents a NaN with a non-zero payload, we can use this
space in the NaN
* ranges to encode other values (however there are also other
ranges of NaN space that
* could have been selected).
*
* For JSValues that do not contain a double value, the high 32 bits
contain the tag
* values listed in the enums below, which all correspond to
NaN-space. In the case of
* cell, integer and bool values the lower 32 bits (the 'payload')
contain the pointer
* integer or boolean value; in the case of all other tags the
payload is 0.
*/
enum { Int32Tag =0x };
enum { BooleanTag = 0xfffe };
enum { NullTag = 0xfffd };
enum { UndefinedTag =0xfffc };
enum { CellTag = 0xfffb };
enum { EmptyValueTag = 0xfffa };
enum { DeletedValueTag = 0xfff9 };
enum { LowestTag = DeletedValueTag };
uint32_t tag() const;
int32_t payload() const;
#elif USE(JSVALUE64)
/*
* On 64-bit platforms USE(JSVALUE64) should be defined, and we use
a NaN-encoded
* form for immediates.
*
* The encoding makes use of unused NaN space in the IEEE754
representation. Any value
* with the top 13 bits set represents a QNaN (with the sign bit
set). QNaN values
* can encode a 51-bit payload. Hardware produced and C-library
payloads typically
* have a payload of zero. We assume that non-zero payloads are
available to encode
* pointer and integer values. Since any 64-bit bit pattern where
the top 15 bits are
* all set represents a NaN with a non-zero payload, we can
Bug#659186: Debian bug 659186, new patch, ia64 libmozjs185
forwarded 659186 https://bugzilla.mozilla.org/show_bug.cgi?id=808512 thanks Hi, 2012/10/25 Michael Biebl bi...@debian.org: TBH, I don't know who maintains the mozjs185 branch/fork and where the upstream bug tracker for that is. Unfortunately, mozjs185 looks pretty much unmaintained :-/ Michael I nevertheless sent a message in a bottle [1] to track this down. Who knows! Emeric [1] https://bugzilla.mozilla.org/show_bug.cgi?id=808512 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692053: [ia64] Iceweasel 10.0 (and above?) randomly stops responding, eating 100% CPU
Package: iceweasel Version: 10.0~b2-1 Severity: important Hello, As reported in the debian-ia64 list back in March [1], Iceweasel 10.0 randomly stops responding, eating 100% CPU. There's no really a simple scenario to reproduce this issue: normal web browsing activity eventually ends up with Iceweasel stops responding and eating 100% CPU. Latest 100% working Iceweasel was 9.0.1-1. None of the successive Iceweasel 10.0.xesr releases that entered Testing solved this issue. Iceweasel 10.0~b2-1 (first Iceweasel 10.0 available for ia64) already exhibit this issue. I can't check if this issue is still present in Iceweasel 16.0 in Sid as it simply crashes at startup at the moment. It's noteworthy that Firefox 10.0.6 in Gentoo ia64 also has this problem. It thus probably relies upstream. I really would like to help further with hg bisect, but don't understand in the Firefox development process [2] how to find the correspondences of the mozilla-release's FIREFOX_9_0_1_RELEASE and FIREFOX_10_0_RELEASE tags in mozilla-central to start the bisection. Any suggestion and advice welcome. Thanks, Émeric [1] http://lists.debian.org/debian-ia64/2012/03/msg9.html [2] http://mozilla.github.com/process-releases/draft/development_specifics/ -- Package-specific info: -- Addons package information -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: ia64 Kernel: Linux 3.2.0-3-mckinley (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages iceweasel depends on: ii debianutils 4.3.2 ii fontconfig 2.9.0-7 ii libc6.1 2.13-35 ii libgcc1 1:4.7.1-7 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-2 ii libgtk2.0-0 2.24.10-2 ii libnspr4-0d 2:4.9.2-1 ii libstdc++6 4.7.1-7 ii procps 1:3.3.3-2 ii xulrunner-10.0 10.0~b2-1 iceweasel recommends no packages. Versions of packages iceweasel suggests: ii libgssapi-krb5-2 1.10.1+dfsg-2 pn mozplugger none pn ttf-lyx | latex-xft-fonts none pn ttf-mathematica4.1 none ii xfonts-mathml 6 Versions of packages xulrunner-10.0 depends on: ii libasound21.0.25-4 ii libatk1.0-0 2.4.0-2 ii libbz2-1.01.0.6-4 ii libc6.1 2.13-35 ii libcairo2 1.12.2-2 ii libdbus-1-3 1.6.8-1 ii libdbus-glib-1-2 0.100-1 ii libevent-2.0-52.0.19-stable-3 ii libfontconfig12.9.0-7 ii libfreetype6 2.4.9-1 ii libgcc1 1:4.7.1-7 ii libgdk-pixbuf2.0-02.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-2 ii libgtk2.0-0 2.24.10-2 ii libhunspell-1.3-0 1.3.2-4 ii libjpeg8 8d-1 ii libmozjs10d 10.0~b2-1 ii libnotify40.7.5-1 ii libnspr4-0d 2:4.9.2-1 ii libnss3-1d2:3.13.6-1 ii libpango1.0-0 1.30.0-1 ii libpixman-1-0 0.26.0-3 ii libreadline6 6.2-8 ii libsqlite3-0 3.7.13-1 ii libstartup-notification0 0.12-1 ii libstdc++64.7.1-7 ii libunwind70.99-0.3 ii libvpx0 0.9.7-1 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxrender1 1:0.9.7-1 ii libxt61:1.1.3-1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages xulrunner-10.0 suggests: ii libcanberra0 0.28-5 ii libgnomeui-0 2.24.5-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659186: Debian bug 659186, new patch, ia64 libmozjs185
Nice :-) Will this be forwarded upstream too? I think that generic (i.e. not Debian-packaged) mozjs185 is affected. This is at least also the case with Gentoo ia64. Best regards, Emeric 2012/10/25 Michael Biebl bi...@debian.org: Thanks a lot Stefan for the patches and thanks Emeric for testing. I'll see to it that we can get those patches into the Debian archive and into wheezy. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642750: Epiphany still unstable [ia64]: SIGSEGV in WebCore::toJSDOMWindow(WebCore::Frame*, WebCore::DOMWrapperWorld*)
tags 642750 - moreinfo thanks Hi, Please find attached an updated gdb stacktrace for libwebkitgtk-3.0.0 1.8.1-3.3 and epiphany-browser 3.4.2-2 currently in Debian Wheezy Testing when following steps described in Message #5 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750#5). Stacktrace is different than with WebKit 1.4/1.6 (but root cause is perhaps still the same). Hope this helps and let me now if you need additional information. Best regards, Emeric Starting program: /usr/bin/epiphany-browser [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/ia64-linux-gnu/libthread_db.so.1. [New Thread 0x2a006f50 (LWP 6808)] [New Thread 0x2a806f50 (LWP 6809)] [New Thread 0x2b006f50 (LWP 6810)] [New Thread 0x200010c36f50 (LWP 6811)] [New Thread 0x2000117c6f50 (LWP 6812)] [Thread 0x2000117c6f50 (LWP 6812) exited] [New Thread 0x2000117c6f50 (LWP 6816)] [New Thread 0x200018252f50 (LWP 6817)] [New Thread 0x200018e9af50 (LWP 6819)] [New Thread 0x2000196e6f50 (LWP 6820)] [Thread 0x2000196e6f50 (LWP 6820) exited] [New Thread 0x2000196e6f50 (LWP 6821)] [New Thread 0x20001a16af50 (LWP 6822)] [Thread 0x20001a16af50 (LWP 6822) exited] [Thread 0x200018e9af50 (LWP 6819) exited] [New Thread 0x200018e9af50 (LWP 6823)] [New Thread 0x20001a16af50 (LWP 6824)] [New Thread 0x20001a98af50 (LWP 6825)] [New Thread 0x20001b18af50 (LWP 6826)] [New Thread 0x20001b98af50 (LWP 6827)] [New Thread 0x20001c18af50 (LWP 6828)] [New Thread 0x20001c98af50 (LWP 6829)] [Thread 0x20001c18af50 (LWP 6828) exited] [Thread 0x20001c98af50 (LWP 6829) exited] [Thread 0x20001a16af50 (LWP 6824) exited] [Thread 0x200018e9af50 (LWP 6823) exited] [Thread 0x20001a98af50 (LWP 6825) exited] [Thread 0x20001b18af50 (LWP 6826) exited] [Thread 0x20001b98af50 (LWP 6827) exited] [New Thread 0x20001b98af50 (LWP 6831)] [Thread 0x2000196e6f50 (LWP 6821) exited] [New Thread 0x2000196e6f50 (LWP 6832)] [New Thread 0x20001b18af50 (LWP 6833)] [New Thread 0x20001a98af50 (LWP 6834)] [New Thread 0x200018e9af50 (LWP 6835)] [New Thread 0x20001a16af50 (LWP 6836)] [Thread 0x200018e9af50 (LWP 6835) exited] [Thread 0x20001b18af50 (LWP 6833) exited] [Thread 0x20001a16af50 (LWP 6836) exited] [Thread 0x20001a98af50 (LWP 6834) exited] [Thread 0x20001b98af50 (LWP 6831) exited] [New Thread 0x20001b98af50 (LWP 6837)] [New Thread 0x20001a98af50 (LWP 6838)] [New Thread 0x20001a16af50 (LWP 6839)] [New Thread 0x20001b18af50 (LWP 6840)] [Thread 0x20001a16af50 (LWP 6839) exited] [Thread 0x20001a98af50 (LWP 6838) exited] [New Thread 0x20001a98af50 (LWP 6841)] [New Thread 0x20001a16af50 (LWP 6842)] [Thread 0x20001b18af50 (LWP 6840) exited] [Thread 0x20001a16af50 (LWP 6842) exited] [Thread 0x20001a98af50 (LWP 6841) exited] [Thread 0x20001b98af50 (LWP 6837) exited] Program received signal SIGSEGV, Segmentation fault. 0x21292330 in WebCore::toJSDOMWindow(WebCore::Frame*, WebCore::DOMWrapperWorld*) () from /usr/lib/libwebkitgtk-3.0.so.0 #0 0x21292330 in WebCore::toJSDOMWindow(WebCore::Frame*, WebCore::DOMWrapperWorld*) () from /usr/lib/libwebkitgtk-3.0.so.0 No symbol table info available. #1 0x2128ddf0 in WebCore::toJSDOMGlobalObject(WebCore::Document*, WebCore::DOMWrapperWorld*) () from /usr/lib/libwebkitgtk-3.0.so.0 No symbol table info available. #2 0x2128ded0 in WebCore::toJSDOMGlobalObject(WebCore::ScriptExecutionContext*, WebCore::DOMWrapperWorld*) () from /usr/lib/libwebkitgtk-3.0.so.0 No symbol table info available. #3 0x213158a0 in WebCore::JSLazyEventListener::initializeJSFunction(WebCore::ScriptExecutionContext*) const () from /usr/lib/libwebkitgtk-3.0.so.0 No symbol table info available. #4 0x212bfa80 in WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) [clone .part.63] () from /usr/lib/libwebkitgtk-3.0.so.0 No symbol table info available. #5 0x216fbaf0 in WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::VectorWebCore::RegisteredEventListener, 1ul) () from /usr/lib/libwebkitgtk-3.0.so.0 No symbol table info available. #6 0x216fbe30 in WebCore::EventTarget::fireEventListeners(WebCore::Event*) () from /usr/lib/libwebkitgtk-3.0.so.0 No symbol table info available. #7 0x217180f0 in WebCore::Node::handleLocalEvents(WebCore::Event*) () from /usr/lib/libwebkitgtk-3.0.so.0 No symbol table info available. #8 0x216ee010 in WebCore::EventDispatcher::dispatchEvent(WTF::PassRefPtrWebCore::Event) () from /usr/lib/libwebkitgtk-3.0.so.0 No symbol table info available. #9 0x2170ecb0 in WebCore::MouseEventDispatchMediator::dispatchEvent(WebCore::EventDispatcher*) const () from /usr/lib/libwebkitgtk-3.0.so.0 No symbol table info available. #10
Bug#659186: Are there several JavaScript implementations?
Hi, Bill MacCoskley, author of commit 3c429287dfbe [1] is not convinced that this commit is responsible for the present ia64 JS engine problems, even if Mike thinks so [2] ;-) I too mistakenly thought this was the case [3]. Indeed, when Stephan noticed that the pages_map() function in memory/jemalloc/jemalloc.c doesn't match with the renewed code in libmozjs185-1.0 [4], I thought that the ia64 fixes [5] were reverted by Bill's commit. I should have noticed that these ia64 fixes and Bill's modifications were all commited to mozilla-central repository [1][6][7] whereas Debian src:mozjs/1.8.5-1.0.0+dfsg-3 README file says this release is based on revision 5f8f494a4c29 of https://hg.mozilla.org/releases/mozilla-2.0;, so a different mozilla-2.0 repository that seems to have little activity nowadays (last change Tue, 28 Jun 2011). This, and other assertions like SpiderMonkey 1.8.5 is the most recent standalone source code release. It implements JavaScript 1.8.5, and it is largely the same engine that shipped with Firefox 4. [8] make me wonder if I'm not mixing two related, but different, Mozilla projects: one standalone JavaScript 1.8.5 implementation (provided on Debian in src:mozjs) and an embedded implementation in Firefox/Iceweasel, with source code similar to src:mozjs in the past but that has independently evolved since then. So, dear package maintainers and other Mozilla developers, am I right saying that? Furthermore, I remember for sure having played with GNOME Shell in the pre-3.0 era. And indeed, gnome-shell-2.91.91-2 depends on libmozjs4d (2.0-3) and not on libmozjs185 (1.0.0) like current GNOME Shell. What's the difference between these packages? Different (standalone?) JavaScript implementations? From name and version, I tend to believe that libmozjs4d implements a more recent JavaScript revision than libmozjs185, but I can't find clear evidence of this: e.g. SpiderMonkey 1.9.2 seemed to be contemporary with... Firefox 3.6 [9]. I'm totally lost! Can you please shed my light? Thanks, Emeric [1] http://hg.mozilla.org/mozilla-central/rev/3c429287dfbe [2] https://bugzilla.mozilla.org/show_bug.cgi?id=675806#c6 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659186#43 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659186#33 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=589735 [6] http://hg.mozilla.org/mozilla-central/rev/00be7279f6ad [7] http://hg.mozilla.org/mozilla-central/rev/9c15d0fb3e25 [8] https://developer.mozilla.org/en-US/docs/SpiderMonkey [9] https://bugzilla.mozilla.org/show_bug.cgi?id=684815 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659186: JS engine broken again on ia64
Hi, JS engine is once again completely broken on ia64 since, at least, commit 3c429287dfbe [1] that reverted changes allowing to turn off static strings allocation [2]. Mike Hommey already pointed out this issue for more than a year [3], but nobody seems to care about ia64 since then. That's for the static strings allocation part of the original bugfix [4]. Now for the jemalloc.c part [5], looking at Mozilla Central history [6], I can't track how/when the ia64 changes have been reverted! Emeric [1] http://hg.mozilla.org/mozilla-central/rev/3c429287dfbe [2] http://hg.mozilla.org/mozilla-central/rev/00be7279f6ad [3] https://bugzilla.mozilla.org/show_bug.cgi?id=675806#c6 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=589735 [5] http://hg.mozilla.org/mozilla-central/rev/9c15d0fb3e25 [6] http://hg.mozilla.org/mozilla-central/log/tip/memory/jemalloc/jemalloc.c -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659186: mozjs-ia64.patch didn't help
Sorry for the late answer, I completely missed this request! Patched libmozjs185 [1] didn't solve the issue, though GNOME Shell crashes in a slightly different way. As I no more have my Debian development HDD available (currently evaluating Gentoo on it), I can't give an updated stacktrace at the moment. Anyway, while gnome-shell --replace simply returns to Metacity once crashed with the original version, the patched version seems to also kill Metacity fallback as I'm missing all the window manager decorations (window border, window title and system buttons). Looking at the proposed patch [2], I can see that it replicates (refactors?) the pages_map patch in jemalloc.c [3] to MapPages in jsgcchunk.cpp. Since the filenames are not the same, is it because of a code refactoring in JS engine? In this case, perhaps the second part of the fix is also missing. Indeed, looking at the original bug report again [4], it appears that JS engine breakage on ia64 was solved thanks to jemalloc patch [3], but also by allowing to turn off static JS strings allocation on ia64 [5]. Do these changes also need to be ported/refactored to the (supposed) new JS code? Emeric [1] http://www.fs-driver.org/debian-ia64/libmozjs185-1.0_1.8.5-1.0.0+dfsg-3.1_ia64.deb [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=33;filename=mozjs-ia64.patch;att=1;bug=659186 [3] http://hg.mozilla.org/mozilla-central/rev/9c15d0fb3e25 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=589735 [5] http://hg.mozilla.org/mozilla-central/rev/00be7279f6ad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638068: Re : initramfs-tools generates unbootable initrd.img on IA-64
Hello, To pass parameters to kernel, add an append= line in your elilo.conf file, just below the initrd= line. In the present case: append=debug=vc Please find attached the log that I've just recorded on a serial console passing debug=vc to kernel. Well, I don't see anything useful or different than without debug=vc. Emeric 2012/6/15 Aníbal Monsalve Salazar ani...@debian.org: On Fri, Jun 15, 2012 at 10:54:35AM +, maximilian attems wrote: Sorry for the time it took. According to your bug report klibc dash on ia64 has a working echo, so it's basic functionality should be good. It is not clear to me why the initramfs won't boot without busybox? It does here very well on x86 platforms. could you please list all the hooks that are shipped: ls /usr/share/initramfs-tools/hooks/ Also could you have a look at boot with the nont working initrmafs with supplied bootargument: debug=vc and no quiet please. It should show where in the boot process the initramfs hangs. thank you. -- maks # uname -a Linux debian 3.3.0-trunk-itanium #1 SMP Wed May 2 08:06:30 UTC 2012 ia64 GNU/Linux # ls /usr/share/initramfs-tools/hooks/ busybox dmsetup keymap klibc kmod thermal udev The photo at the web address below shows the output without the debug=vc kernel boot parameter. http://people.debian.org/~anibal/p1010539.jpg With the debug=vc kernel boot parameter there is no additional output. Just before the load of vmlinuz (at the ELILO boot prompt), I hit the tab key and typed LinuxOLD followed by debug=vc and it was ignored apparently. The prompt was: ELILO boot: Linux LinuxOLD (or a kernel file name: [[dev_name:/]path/]kernel_image cmdline options) ELILO boot: The machine is Dell PowerEdge 7250. I need to find out what's the dev_name of the EFI boot partition of the logical drive of the raid5. I tried debug=vc in elilo.conf and the system wouldn't boot and complained about that extra line in elilo.conf. My elilo.conf is below. ## elilo configuration file generated by elilo 3.12-4 # install=/usr/lib/elilo/elilo.efi # boot=/dev/sda1 # boot=/dev/disk/by-uuid/4DBC-29A7 delay=20 default=Linux relocatable image=/EFI/debian/vmlinuz label=Linux # root = /dev/sda2 root = UUID=e662a93c-2b14-46bc-82aa-5d29cc2b4db1 read-only initrd=/EFI/debian/initrd.img image=/EFI/debian/vmlinuz.old label=LinuxOLD # root = /dev/sda2 root = UUID=e662a93c-2b14-46bc-82aa-5d29cc2b4db1 read-only initrd=/EFI/debian/initrd.img.old Uncompressing Linux... done Loading file \EFI\debian\initrd.img...done [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-2-mckinley (Debian 3.2.19-1) (debian-kernel@l ists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-5) ) #1 SMP Fri Jun 1 22:37:41 UTC 2012 [0.00] EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS= 0x3fb3a000 HCDP=0x3fb2c000 [0.00] booting generic kernel on platform hpzx1 [0.00] PCDP: v0 at 0x3fb2c000 [0.00] Explicit console=; ignoring PCDP [0.00] ACPI: RSDP 3fb2e000 00028 (v02 HP) [0.00] ACPI: XSDT 3fb2e02c 00094 (v01 HP zx6000 HP ) [0.00] ACPI: FACP 3fb36800 000F4 (v03 HP zx6000 HP ) [0.00] ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 (2011062 3/tbfadt-529) [0.00] ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 (2011062 3/tbfadt-529) [0.00] ACPI: DSDT 3fb2e0e0 05781 (v01 HP zx6000 0007 I NTL 02012044) [0.00] ACPI: FACS 3fb368f8 00040 [0.00] ACPI: SPCR 3fb36938 00050 (v01 HP zx6000 HP ) [0.00] ACPI: DBGP 3fb36988 00034 (v01 HP zx6000 HP ) [0.00] ACPI: APIC 3fb36a48 000B0 (v01 HP zx6000 HP ) [0.00] ACPI: SPMI 3fb369c0 00050 (v04 HP zx6000 HP ) [0.00] ACPI: CPEP 3fb36a10 00034 (v01 HP zx6000 HP ) [0.00] ACPI: SSDT 3fb33870 001D6 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb33a50 00342 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb33da0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb347c0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb351e0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb35c00 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb36620 000EB (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb36710 000EF (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: Local APIC address c000fee0 [0.00] 2 CPUs
Bug#659485: Problem solved
Hi, Tony Luck proposed a patch to fix this issue in https://bugzilla.kernel.org/show_bug.cgi?id=42757. Current Debian Testing kernel 3.2-14 locally rebuilt including this patch works as expected :-) Many thanks, Emeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659485: [regression][bisected] General stability issues since futex: Sanitize cmpxchg_futex_value_locked API commit
Package: linux-image-3.2.0-1-mckinley Version: 3.2.4-1 Severity: important As reported first in http://lists.debian.org/debian-ia64/2012/01/msg00016.html, I'm getting stability issues with kernel 2.6.38. I've bisected the problem to commit 37a9d912b24f96a0591773e6e6c3642991ae5a70 (futex: Sanitize cmpxchg_futex_value_locked API). Here are some issues that can be easily observed: - in a X session (tested under GNOME Classic as well as TWM), hitting the Tab key while in a terminal window instantly triggers a X restart. X isn't crashed as I wrongly assume initially. From the logs, it's definitely properly shut down and restarted - still in a X session, clicking on the Edit menu or Back button of Firefox/Iceweasel triggers a crash of Firefox/Iceweasel. For this scenario, I have some kind of gdb stack trace in PulseAudio, before gdb itself goes wrong (more on this later; core file available) First investigations let me wrongly assume that these issues were related to something bad in PulseAudio, as uninstalling PulseAudio fixed both of them (Tab key in a terminal issue and Firefox/Iceweasel crash). However, other crashes make me believe that PulseAudio was only a evidence of something more general broken since the bisected commit. Most notably, gdb can't be started at all. Every attempts to debug a program immediately ends up with a SIGTRAP signal. Quite problematic to debug further... It's noteworthy that the exact same system doesn't exhibit these issues when rebooted with kernel linux-image-2.6.38-2-mckinley. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: ia64 Kernel: Linux 3.2.4-1-mckinley (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659186: gnome-shell: Segmentation fault in libmozjs185.so.1.0 at startup
Thank you for pointing this out. Just a question: how is it that bug #657321 is reported against ia64, but System Information says: Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Is it because bug #657321 also impacts amd64? Emeric Le 9 février 2012 00:50, Michael Biebl bi...@debian.org a écrit : On 09.02.2012 00:10, Émeric Maschino wrote: Package: gnome-shell Version: 3.2.2.1-1 Severity: important Hello, Gnome Shell cannot be started at all on ia64/IA-64/IPF (Itanium) platform. It instantly crashes at startup, receiving SIGSGEV from /usr/lib/libmozjs185.so.1.0. Gnome Classic starts up fine. Please find in attached the gdb output. Let me know if you need additional information. This is most likely the same issue as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657321 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659186: gnome-shell: Segmentation fault in libmozjs185.so.1.0 at startup
OK. BTW, was Mike on IRC referring to this issue? https://bugzilla.mozilla.org/show_bug.cgi?id=589735 Emeric Le 9 février 2012 10:16, Michael Biebl bi...@debian.org a écrit : On 09.02.2012 10:03, Émeric Maschino wrote: Thank you for pointing this out. Just a question: how is it that bug #657321 is reported against ia64, but System Information says: Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Is it because bug #657321 also impacts amd64? No, it is because I reported it from my amd64 laptop. I don't run or use ia64 myself. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659186: gnome-shell: Segmentation fault in libmozjs185.so.1.0 at startup
Package: gnome-shell Version: 3.2.2.1-1 Severity: important Hello, Gnome Shell cannot be started at all on ia64/IA-64/IPF (Itanium) platform. It instantly crashes at startup, receiving SIGSGEV from /usr/lib/libmozjs185.so.1.0. Gnome Classic starts up fine. Please find in attached the gdb output. Let me know if you need additional information. Thank you, Émeric -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: ia64 Kernel: Linux 2.6.38-2-mckinley (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.10.0-3 ii gir1.2-accountsservice-1.0 0.6.15-2 ii gir1.2-atk-1.0 2.2.0-2 ii gir1.2-caribou-1.0 0.4.1-2 ii gir1.2-clutter-1.0 1.8.2-2 ii gir1.2-cogl-1.0 1.8.2-1 ii gir1.2-coglpango-1.0 1.8.2-1 ii gir1.2-folks-0.6 0.6.6-1 ii gir1.2-freedesktop 1.31.1-1 ii gir1.2-gconf-2.0 2.32.4-1 ii gir1.2-gdkpixbuf-2.0 2.24.0-2 ii gir1.2-gee-1.0 0.6.1-3 ii gir1.2-gkbd-3.0 3.2.0-1 ii gir1.2-glib-2.0 1.31.1-1 ii gir1.2-gmenu-3.0 3.2.0.1-2 ii gir1.2-gnomebluetooth-1.03.2.1-1 ii gir1.2-gtk-3.0 3.2.3-1 ii gir1.2-json-1.0 0.14.2-1 ii gir1.2-mutter-3.03.2.2-1 ii gir1.2-networkmanager-1.00.9.2.0-2 ii gir1.2-pango-1.0 1.29.4-2 ii gir1.2-polkit-1.00.104-1 ii gir1.2-soup-2.4 2.34.3-1 ii gir1.2-telepathyglib-0.120.16.2-1 ii gir1.2-telepathylogger-0.2 0.2.12-1 ii gir1.2-upowerglib-1.00.9.15-1 ii gjs 1.30.0-3 ii gnome-bluetooth 3.2.1-1 ii gnome-icon-theme-symbolic3.2.2-1 ii gnome-settings-daemon3.2.2-2 ii gnome-shell-common 3.2.2.1-1 ii gsettings-desktop-schemas3.2.0-2 ii libatk1.0-0 2.2.0-2 ii libc6.1 2.13-26 ii libcairo-gobject21.10.2-6.2 ii libcairo21.10.2-6.2 ii libcamel-1.2-29 3.2.2-1 ii libcanberra0 0.28-3 ii libclutter-1.0-0 1.8.2-2 ii libcogl-pango0 1.8.2-1 ii libcogl5 1.8.2-1 ii libcroco30.6.2-2 ii libdbus-1-3 1.4.16-1 ii libdbus-glib-1-2 0.98-1 ii libdrm2 2.4.30-1 ii libebook-1.2-12 3.2.2-1 ii libecal-1.2-10 3.2.2-1 ii libedataserver-1.2-153.2.2-1 ii libedataserverui-3.0-1 3.2.2-1 ii libffi5 3.0.10-3 ii libfolks25 0.6.6-1 ii libfontconfig1 2.8.0-3.1 ii libfreetype6 2.4.8-1 ii libgconf2-4 2.32.4-1 ii libgdk-pixbuf2.0-0 2.24.0-2 ii libgee2 0.6.1-3 ii libgirepository-1.0-11.31.1-1 ii libgjs0b [libgjs0-libmozjs185-1.0] 1.30.0-3 ii libgl1-mesa-glx [libgl1] 7.11.2-1 ii libglib2.0-0 2.30.2-6 ii libgnome-desktop-3-2 3.2.1-3 ii libgnome-keyring03.2.2-2 ii libgnome-menu-3-03.2.0.1-2 ii libgstreamer0.10-0 0.10.35-1 ii libgtk-3-0 3.2.3-1 ii libical0 0.44-3 ii libjson-glib-1.0-0 0.14.2-1 ii libmozjs185-1.0 1.8.5-1.0.0+dfsg-3 ii libmutter0 3.2.2-1 ii libnm-glib4 0.9.2.0-2 ii libnm-util2 0.9.2.0-2 ii libnspr4-0d 4.8.9-1 ii libnss3-1d 3.13.1.with.ckbi.1.88-1 ii libpango1.0-01.29.4-2 ii
Bug#642153: Confirmed: Qt-related issue. Not better with 4.7.4
Hi, Just to let you know that Qt 4.7.4-2 in today's Debian Testing Wheezy updates didn't solve the problem. Émeric Le 20 septembre 2011 02:28, Adam Majer ad...@zombino.com a écrit : On Tue, Sep 20, 2011 at 12:17:00AM +0200, Émeric Maschino wrote: Thanks to snapshot.debian.org, I can confirm that qtcreator 1.3.1-3 currently in Debian Wheezy Testing can be run successfully with Qt packages up to 4.7.1-2. Starting with Qt packages 4.7.2-1, Qt Creator crashes with a bus error. Yes, it is in Qt. Applications don't touch internal Qt structures and don't deal with direct rendering of fonts (area where backtrace is pointing to) - Adam -- Adam Majer ad...@zombino.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642750: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platfor
Hi, Unfortunately, still the same issue. Please have a look at the attached gdb.txt. This is with epiphany 3.2.1-2 and webkit 1.6.1-5+b1 currently in Debian Testing. Hope this helps and let me know if you need more information. Émeric Le 17 janvier 2012 01:46, Michael Gilbert michael.s.gilb...@gmail.com a écrit : tag 642750 moreinfo thanks Hi, can you try webkit 1.6.1 or newer? I don't have an itanium to be able to test this. Starting program: /usr/bin/epiphany-browser [Thread debugging using libthread_db enabled] [New Thread 0x29606f70 (LWP 6607)] [New Thread 0x29e06f70 (LWP 6608)] [New Thread 0x2000107fef70 (LWP 6609)] [New Thread 0x20001138ef70 (LWP 6610)] [New Thread 0x200011ea2f70 (LWP 6611)] [New Thread 0x2000126aaf70 (LWP 6612)] [New Thread 0x2000132aef70 (LWP 6613)] [New Thread 0x200013aaef70 (LWP 6614)] [New Thread 0x2000142aef70 (LWP 6615)] [New Thread 0x200014aaef70 (LWP 6616)] [New Thread 0x2000152aef70 (LWP 6617)] [New Thread 0x200015ac6f70 (LWP 6618)] [New Thread 0x2000162def70 (LWP 6619)] [New Thread 0x200016af6f70 (LWP 6620)] [New Thread 0x2000173faf70 (LWP 6621)] [Thread 0x2000173faf70 (LWP 6621) exited] [Thread 0x200014aaef70 (LWP 6616) exited] [Thread 0x2000162def70 (LWP 6619) exited] [Thread 0x2000142aef70 (LWP 6615) exited] [Thread 0x200016af6f70 (LWP 6620) exited] [Thread 0x2000152aef70 (LWP 6617) exited] [Thread 0x200013aaef70 (LWP 6614) exited] [Thread 0x2000132aef70 (LWP 6613) exited] [Thread 0x200011ea2f70 (LWP 6611) exited] [Thread 0x200015ac6f70 (LWP 6618) exited] [New Thread 0x200015ac6f70 (LWP 6633)] [New Thread 0x200011ea2f70 (LWP 6634)] [New Thread 0x2000132aef70 (LWP 6635)] [New Thread 0x200013aaef70 (LWP 6636)] [New Thread 0x2000152aef70 (LWP 6637)] [New Thread 0x2000142aef70 (LWP 6638)] [New Thread 0x200014aaef70 (LWP 6639)] [New Thread 0x2000162def70 (LWP 6640)] [New Thread 0x2000173faf70 (LWP 6641)] [New Thread 0x200016af6f70 (LWP 6642)] [New Thread 0x2000185cef70 (LWP 6643)] [Thread 0x200015ac6f70 (LWP 6633) exited] [Thread 0x2000132aef70 (LWP 6635) exited] [Thread 0x2000162def70 (LWP 6640) exited] [Thread 0x2000173faf70 (LWP 6641) exited] [Thread 0x200013aaef70 (LWP 6636) exited] [Thread 0x2000142aef70 (LWP 6638) exited] [Thread 0x200016af6f70 (LWP 6642) exited] [Thread 0x200014aaef70 (LWP 6639) exited] [Thread 0x2000185cef70 (LWP 6643) exited] [Thread 0x200011ea2f70 (LWP 6634) exited] [New Thread 0x200011ea2f70 (LWP 6644)] [New Thread 0x2000185cef70 (LWP 6645)] [New Thread 0x200014aaef70 (LWP 6646)] [New Thread 0x200016af6f70 (LWP 6647)] [New Thread 0x2000142aef70 (LWP 6648)] [New Thread 0x2000133bef70 (LWP 6649)] [Thread 0x2000133bef70 (LWP 6649) exited] [Thread 0x2000142aef70 (LWP 6648) exited] [Thread 0x2000185cef70 (LWP 6645) exited] [Thread 0x2000152aef70 (LWP 6637) exited] [Thread 0x200016af6f70 (LWP 6647) exited] [Thread 0x200014aaef70 (LWP 6646) exited] Program received signal SIGSEGV, Segmentation fault. 0x212da0f0 in get (this=optimized out) at ../Source/JavaScriptCore/runtime/WriteBarrier.h:96 96 ../Source/JavaScriptCore/runtime/WriteBarrier.h: Aucun fichier ou dossier de ce type. in ../Source/JavaScriptCore/runtime/WriteBarrier.h Thread 28 (Thread 0x200011ea2f70 (LWP 6644)): #0 0xa0040721 in __kernel_syscall_via_break () No symbol table info available. #1 0x25167070 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/ia64-linux-gnu/libpthread.so.0 No symbol table info available. #2 0x24f30810 in g_cond_timed_wait_posix_impl () from /usr/lib/ia64-linux-gnu/libgthread-2.0.so.0 No symbol table info available. #3 0x24f66c20 in ?? () from /lib/ia64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #4 0x24f686d0 in g_async_queue_timed_pop () from /lib/ia64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #5 0x2503d070 in g_thread_pool_thread_proxy () from /lib/ia64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #6 0x25036cb0 in g_thread_create_proxy () from /lib/ia64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #7 0x2515abb0 in start_thread () from /lib/ia64-linux-gnu/libpthread.so.0 No symbol table info available. #8 0x25336180 in __clone2 () from /lib/ia64-linux-gnu/libc.so.6.1 No symbol table info available. #9 0x in ?? () No symbol table info available. Thread 7 (Thread 0x2000126aaf70 (LWP 6612)): #0 0xa0040721 in __kernel_syscall_via_break () No symbol table info available. #1 0x25167070 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/ia64-linux-gnu/libpthread.so.0 No symbol table info available. #2 0x259ca960 in WTF::ThreadCondition::timedWait (
Bug#638068: Root cause: busybox binary in initrd.img is incorrectly overwritten by klibc hook
Hi,
I've identified the root cause of this issue: busybox hook is called
_before_ klibc one. This ends up with /bin/sh binary in the generated
initrd.img being a copy of (or a symlink to) system
/usr/lib/klibc/bin/sh binary whereas it is expected to be a copy of
(or a symlink to) system /bin/busybox binary.
The explanations in details.
Up to initramfs-tools 0.98.8, an error message should have warn us.
When running e.g. dpkg -i initramfs-tools_0.98.8_all.deb, the
following error is displayed on console:
ln: failed to create symbolic link
`/tmp/mkinitramfs_o2WpcY/bin/sh': File exist
Following commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2
(mkinitramfs: copy over on
build instead of using symlink tree) from maximilian attems, this
error has disappeared in initramfs-tools 0.99. More on this later.
So, why are we getting this ln error with initramfs-tools 0.98.8?
Tracing an initramfs-tools run reveals that busybox hook is called
first, most notably executing:
rm -f ${DESTDIR}/bin/sh
rm -f ${DESTDIR}/bin/busybox
copy_exec ${BUSYBOXDIR}/busybox /bin/busybox
ln -s ${BUSYBOXDIR}/busybox ${DESTDIR}/bin/sh
initrd.img correctly has /bin/sh being a symlink to /bin/busybox
binary, the latter being a copy of system /bin/busybox binary.
But next klibc hook is called:
ln -s /usr/lib/klibc/bin/* ${DESTDIR}/bin
ln -s /lib/klibc-*.so ${DESTDIR}/lib
The problem lies in the first line: indeed, system /usr/lib/klibc/bin
directory _contains_ a sh binary. But since busybox hook already
created a symlink with the same name /bin/sh in initrd.img, system
/usr/lib/klib/bin/sh binary can't be copied over the /bin/sh symlink,
hence the ln error on the console.
Now, why is this error disappearing with initramfs-tools 0.99 and why
is the generated initrd.img unbootable?
Since maximilian commit, busybox hook now executes:
rm -f ${DESTDIR}/bin/sh
rm -f ${DESTDIR}/bin/busybox
copy_exec ${BUSYBOXDIR}/busybox /bin/sh
System /bin/busybox binary is thus copied as /bin/sh binary into initrd.img.
But then, klibc hook is called:
cp -pL /usr/lib/klibc/bin/* ${DESTDIR}/bin
cp -pL /lib/klibc-*.so ${DESTDIR}/lib
The problem still lies in the first line, but since these are no more
symlinks but file copies, (i) /bin/sh binary in initrd.img is
overwritten with system /usr/lib/klibc/bin/sh binary and (ii) there's
obviously no more ln error.
I've looked at current initramfs-tools git repository. The problem is
still there, with a subtle difference.
Now, busybox hook executes:
rm -f ${DESTDIR}/bin/sh
rm -f ${DESTDIR}/bin/busybox
copy_exec ${BUSYBOXDIR}/busybox /bin/busybox
ln -s busybox ${DESTDIR}/bin/sh
A copy of system /bin/busybox binary is thus put into initrd.img, with
a /bin/sh symlink pointing to it.
However, klibc hook still runs:
cp -pL /usr/lib/klibc/bin/* ${DESTDIR}/bin
cp -pL /lib/klibc-*.so ${DESTDIR}/lib
Because of system /usr/lib/klibc/bin/sh binary, this ends up by
overwriting the _target_ of /bin/sh (symlink previously created by
busybox hook), thus replacing /bin/busybox binary in initrd.img by
system /usr/lib/klibc/bin/sh binary, making initrd.img unbootable.
I've checked that simply replacing /bin/busybox binary in initrd.img
(being in fact a copy of system /usr/lib/klibc/bin/sh binary) by real
system /bin/busybox binary solves the issue.
Now, how to fix this properly? I haven't found where the hook calls
ordering is done. But busybox hook definitely has to be called _after_
klibc one.
I don't know for the other Debian architectures, but if busybox hook
is also called _before_ klibc one, then all the initrd.img are either
wrong (at the best, since /bin/sh binary is thus not a copy of or a
symlink to system /bin/busybox binary as it should) or broken as on
ia64.
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638068: busybox binary in initrd.img is incorrectly overwritten by klibc hook
Le 15 janvier 2012 19:08, maximilian attems m...@stro.at a écrit : Nice detective work. So the next question is: why does klibc-utils on ia64 provide /usr/lib/klibc/bin/sh instead of sh.shared like other architectures? #439181 ia64 works only static Thanks for pointing this out. I'd also be interested to hear how /usr/lib/klibc/bin/sh behaves in general: e.g., could you try ldd /usr/lib/klibc/bin/sh /usr/lib/klibc/bin/sh -c 'echo hi' ? /me too. Okay, okay, your wish is my command ;-) emeric@longspeak:~$ ldd /usr/lib/klibc/bin/sh not a dynamic executable Checked with: emeric@longspeak:~$ file /usr/lib/klibc/bin/sh /usr/lib/klic/bin/sh: ELF 64-bit LSB executable, IA-64, version 1 (SYSV), statically linked, stripped emeric@longspeak:~$ /usr/lib/klibc/bin/sh -c 'echo hi' hi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: gnome-settings-daemon can't connect to D-Bus and eats CPU on ia64 due to -Wl,-z-defs
Le 14 novembre 2011 23:51, Jonathan Nieder jrnie...@gmail.com a écrit :
So, to summarize, only libgconf.so and libsmartcard.so didn't need to
be replaced by recompiled versions without -z defs flag. I don't know
if it'll help further, but they can even be removed from
/usr/lib/gnome-settings-daemon-3.0 and both GDM3 and GNOME3 session
still run flawlessly.
Thanks, this is interesting.
Now for some stupid questions:
- does linking with gold instead (i.e., installing binutils-gold)
change the outcome?
Sorry for the late reply. Unfortunately, Gold isn't available on ia64,
neither in Wheezy, nor Sid. And I can't make it compile successfully
:-(
- does using -Wl,--no-undefined in place of -Wl,-z,defs change
anything?
No. But since -z defs and --no-undefined are the same (from the
manpage), that's a good thing ;-)
Presumably -Wl,--no-undefined -Wl,--error-unresolved-symbols errors out ---
what is the message when it does?
All the plugins complain about missing reference to
gnome_settings_plugin_get_type.
And some have additional missing references (mainly X11-related):
- a11y-keyboard: Xkb{Set|Get}Controls, XkbFreeKeyboard, XSync,
XkbQueryExtension, XkbSelectEvents;
- automount: XkbGetState;
- background: XInternAtom, XGetWindowProperty, XFree;
- clipboard: XSync, XInternAtom, XGetWindowProperty, XFree,
XChangeProperty, XConvertSelection, XSendEvent, XGetWindowAttributes,
XSelectInput, X{Set|Get}SelectionOwner, XCreateSimpleWindow,
XDestroyWindow, XExtendedMaxRequestSize, XMaxRequestSize, XIfEvent;
- keyboard: XkbFreeKeyboard, Xkb{Query|Use}Extension, XInternAtom,
XFree, XGetSelectionOwner, XAutoRepeat{On|Off}, XkbSetAutoRepeatRate,
XChangeKeyboardControl, XkbKeysymToModifiers, XkbSelectEventDetails,
XGetAtomName;
- mouse: floor, floorf, ceil, ceilf;
- print-notifications: notify_notification_new,
notify_notification_set_hint, notify_notification_show;
- xsettings: XInternAtom, XChangeProperty, XSendEvent, XSelectInput,
X{Set|Get}SelectionOwner, XCreateSimpleWindow, XDestroyWindow,
XIfEvent, X{Open|Close}Display, XResourceManagerString.
It's noteworthy than debian/rules top build script passes by default
--warn-unresolved-symbols to the linker, so the above missing
references are obviously hidden. I don't know if these missing
references are thus expected in the present context or if it's
expected that --warn-unresolved-symbols is passed to the linker rather
than --error-unresolved-symbols (default behavior from the manpage).
- what does using -z defs buy us when the error is demoted to a
warning by a later command-line option, anyway? Though I still
don't understand what is causing this code path to break.
Sorry Jonathan, my limited English doesn't allow me to understand this
last section. What do you mean by buy us?
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648626: GNOME 3's Metacity makes OpenGL applications unstable
Package: metacity Version: 2.34.1-2 Severity: important Hello, With the delivery of GNOME 3 into Testing, Metacity was upgraded from version 2.30.1-3 to version 2.34.1-2. Since then, I'm experiencing stability issue when running OpenGL-intensive applications (e.g. ioQuake3-based applications or WebGL Conformance Test Suite https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html): application runs fine for 10-20 sec. and then seems to lock up. Switching to a text console shows multiple instances of error messages like: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(11) [drm:radeon_cs_ioctl] *ERROR* Failed to schedule IB! Stopping and restarting X didn't help: the display is then garbaged, and switching back again to the text console reports the same error messages. This is with current Metacity 2.34.1-2 when running GNOME 3 in fallback mode (I can't try GnomeShell at this time because of an udev issue). I'm pretty sure this has to deal with some Metacity processing now performed by the GPU, whereas 2.30.1-3 was relying upon CPU. Indeed, I had no problem with Metacity 2.30.1-3 that was previously in Testing. However, I was experiencing the same kind of problem when switching the window manager from Metacity to Mutter in the GNOME 2 era, and IIRC, Mutter was heavily relying upon the GPU. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: ia64 Kernel: Linux 2.6.38-2-mckinley (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages metacity depends on: ii gnome-icon-theme 3.2.1.2-1 ii libatk1.0-0 2.2.0-2 ii libc6.1 2.13-21 ii libcairo2 1.10.2-6.1 ii libcanberra-gtk0 0.28-3 ii libcanberra0 0.28-3 ii libgconf2-4 2.32.4-1 ii libgdk-pixbuf2.0-02.24.0-1 ii libglib2.0-0 2.28.8-1 ii libgnome2-common 2.32.1-2 ii libgtk2.0-0 2.24.7-1 ii libgtop2-72.28.4-1 ii libice6 2:1.0.7-2 ii libmetacity-private0a 1:2.34.1-2 ii libpango1.0-0 1.29.4-2 ii libsm62:1.2.0-2 ii libstartup-notification0 0.12-1 ii libunwind70.99-0.3 ii libx11-6 2:1.4.4-2 ii libxcomposite11:0.4.3-2 ii libxcursor1 1:1.1.12-1 ii libxdamage1 1:1.1.3-2 ii libxext6 2:1.3.0-3 ii libxfixes31:5.0-4 ii libxinerama1 2:1.1.1-3 ii libxrandr22:1.3.2-2 ii libxrender1 1:0.9.6-2 ii metacity-common 1:2.34.1-2 ii zenity3.2.0-1 Versions of packages metacity recommends: ii gnome-session-fallback [x-session-manager] 3.0.2-3 Versions of packages metacity suggests: ii gnome-control-center 1:3.0.2-3 ii gnome-themes 2.30.2-1 ii xdg-user-dirs 0.14-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648626: GNOME 3's Metacity makes OpenGL applications unstable
2011/11/13 Josselin Mouette j...@debian.org: I find this dubious. The point of keeping metacity for the fallback mode is that it still does everything in software, or only with RENDER acceleration; it does not use OpenGL. Could it thus be possible that RENDER acceleration globally struggles the GPU so that it eventually can't process OpenGL request correctly? What has changed between Metacity 2.30 and 2.34 w.r.t 2D (3D?) acceleration that could explain this issue? I'm not sure if the lock up during the WebGL tests still appears on the same test. If yes, I imagine it will help understand what's going on. I'll try to have a reproduceable error. Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648626: GNOME 3's Metacity makes OpenGL applications unstable
2011/11/13 Émeric Maschino emeric.masch...@gmail.com: I'm not sure if the lock up during the WebGL tests still appears on the same test. If yes, I imagine it will help understand what's going on. I'll try to have a reproduceable error. Unfortunately, WebGL test suite not always locks up on the same test :-(. I fear this will be, once again on ia64, a nasty bug hard to reproduce and fix... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647825: udevd[XXX]: unable to receive ctrl connection: Function not implemented
2011/11/11 Ben Hutchings b...@decadent.org.uk: On Fri, Nov 11, 2011 at 07:48:24PM +0100, Émeric Maschino wrote: 2011/11/11 Ben Hutchings b...@decadent.org.uk: Isn't Wheezy eglibc 2.13-21 supposed to already implement accept4()? That is a little difficult when the system call is not even defined for an architecture! Until it is rebuilt against the new kernel header, I assume it will use a fallback implementation that always fails. OK. So I imagine that even with a patched kernel, udev will still fails until accept4() is rebuilt against the patched kernel. emeric@longspeak:~/Documents$ ./test_accept4 === Calling accept4(): flags = 0 accept4(): Function not implemented emeric@longspeak:~/Documents$ ./test_accept4 === Calling accept4(): flags = 0 Close-on-exec flag is not set (OK); nonblock flag is not set (OK) Test result: PASS === Calling accept4(): flags = 8 (SOCK_CLOEXEC) Close-on-exec flag is set (OK); nonblock flag is not set (OK) Test result: PASS === Calling accept4(): flags = 800 (SOCK_NONBLOCK) Close-on-exec flag is not set (OK); nonblock flag is set (OK) Test result: PASS === Calling accept4(): flags = 80800 (SOCK_CLOEXEC SOCK_NONBLOCK) Close-on-exec flag is set (OK); nonblock flag is set (OK) Test result: PASS I have no idea why this would still fail; maybe you need to change something additional in the kernel. Ask the linux-ia64 mailing list. Ben. I simply forgot to also installed the patched version of linux-libc-dev and compiling the test_accept4.c against it! Now, everything seems fine and SOCK_CLOEXEC seems to be supported. I'll thus create the patches against current kernel 3.2-rc1, test them and send them to the kernel-ia64 list. Thanks Ben and Marco for your help and guidelines. Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647825: [PATCH] ia64: Add accept4() syscall
From: Émeric Maschino emeric.masch...@gmail.com
Subject: ia64: Add accept4() syscall
While debugging udev 170 failure on Debian Wheezy
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648325), it appears
that the issue was in fact due to missing accept4() in ia64.
This patch simply adds accept4() to ia64. The
arch/ia64/include/asm/unistd.h and arch/ia64/kernel/entry.S diffs
apply cleanly against 3.2-rc1.
Patch has been successfully tested running an ia64-targeted version of
test_accept4.c (modified from x86/x86_64-centric original version from
http://git.kernel.org/linus/de11defebf7677fb7ee91d9b089b78786fbb):
/* test_accept4.c
Copyright (C) 2008, Linux Foundation, written by Michael Kerrisk
mtk.manpa...@gmail.com
Licensed under the GNU GPLv2 or later.
*/
#define _GNU_SOURCE
#include unistd.h
#include sys/syscall.h
#include sys/socket.h
#include netinet/in.h
#include stdlib.h
#include fcntl.h
#include stdio.h
#include string.h
#define PORT_NUM 3
#define die(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
/**/
/* The following is what we need until glibc gets a wrapper for
accept4() */
/* Flags for socket(), socketpair(), accept4() */
#ifndef SOCK_CLOEXEC
#define SOCK_CLOEXECO_CLOEXEC
#endif
#ifndef SOCK_NONBLOCK
#define SOCK_NONBLOCK O_NONBLOCK
#endif
#define __NR_accept4 1334
static int
__accept4(int fd, struct sockaddr *sockaddr, socklen_t *addrlen, int flags)
{
printf(Calling accept4(): flags = %x, flags);
if (flags != 0) {
printf( ();
if (flags SOCK_CLOEXEC)
printf(SOCK_CLOEXEC);
if ((flags SOCK_CLOEXEC) (flags SOCK_NONBLOCK))
printf( );
if (flags SOCK_NONBLOCK)
printf(SOCK_NONBLOCK);
printf());
}
printf(\n);
return syscall(__NR_accept4, fd, sockaddr, addrlen, flags);
}
/**/
static int
do_test(int lfd, struct sockaddr_in *conn_addr,
int closeonexec_flag, int nonblock_flag)
{
int connfd, acceptfd;
int fdf, flf, fdf_pass, flf_pass;
struct sockaddr_in claddr;
socklen_t addrlen;
printf(===\n);
connfd = socket(AF_INET, SOCK_STREAM, 0);
if (connfd == -1)
die(socket);
if (connect(connfd, (struct sockaddr *) conn_addr,
sizeof(struct sockaddr_in)) == -1)
die(connect);
addrlen = sizeof(struct sockaddr_in);
acceptfd = __accept4(lfd, (struct sockaddr *) claddr, addrlen,
closeonexec_flag | nonblock_flag);
if (acceptfd == -1) {
perror(accept4());
close(connfd);
return 0;
}
fdf = fcntl(acceptfd, F_GETFD);
if (fdf == -1)
die(fcntl:F_GETFD);
fdf_pass = ((fdf FD_CLOEXEC) != 0) ==
((closeonexec_flag SOCK_CLOEXEC) != 0);
printf(Close-on-exec flag is %sset (%s); ,
(fdf FD_CLOEXEC) ? : not ,
fdf_pass ? OK : failed);
flf = fcntl(acceptfd, F_GETFL);
if (flf == -1)
die(fcntl:F_GETFD);
flf_pass = ((flf O_NONBLOCK) != 0) ==
((nonblock_flag SOCK_NONBLOCK) !=0);
printf(nonblock flag is %sset (%s)\n,
(flf O_NONBLOCK) ? : not ,
flf_pass ? OK : failed);
close(acceptfd);
close(connfd);
printf(Test result: %s\n, (fdf_pass flf_pass) ? PASS : FAIL);
return fdf_pass flf_pass;
}
static int
create_listening_socket(int port_num)
{
struct sockaddr_in svaddr;
int lfd;
int optval;
memset(svaddr, 0, sizeof(struct sockaddr_in));
svaddr.sin_family = AF_INET;
svaddr.sin_addr.s_addr = htonl(INADDR_ANY);
svaddr.sin_port = htons(port_num);
lfd = socket(AF_INET, SOCK_STREAM, 0);
if (lfd == -1)
die(socket);
optval = 1;
if (setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, optval,
sizeof(optval)) == -1)
die(setsockopt);
if (bind(lfd, (struct sockaddr *) svaddr,
sizeof(struct sockaddr_in)) == -1)
die(bind);
if (listen(lfd, 5) == -1)
die(listen);
return lfd;
}
int
main(int argc, char *argv[])
{
struct sockaddr_in conn_addr;
int lfd;
int port_num;
int passed;
passed = 1;
port_num = (argc 1) ? atoi(argv[1]) : PORT_NUM;
memset(conn_addr, 0, sizeof(struct sockaddr_in));
conn_addr.sin_family = AF_INET;
conn_addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
conn_addr.sin_port = htons(port_num);
lfd = create_listening_socket(port_num);
if (!do_test(lfd, conn_addr, 0, 0))
passed = 0;
if (!do_test(lfd, conn_addr, SOCK_CLOEXEC, 0))
passed = 0;
if (!do_test(lfd, conn_addr, 0, SOCK_NONBLOCK))
passed = 0;
if (!do_test(lfd, conn_addr, SOCK_CLOEXEC, SOCK_NONBLOCK))
passed = 0;
close(lfd);
exit(passed ? EXIT_SUCCESS : EXIT_FAILURE);
}
Signed-off-by: Émeric Maschino emeric.masch...@gmail.com
---
diff -uprN -X linux-3.2-rc1
Bug#648325: Not an udev issue!
Patrice, The Loading please wait... issue you're experiencing isn't due to udev, but to initramfs-tools 0.99. See my bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638068) and feel free to add comment. Hi, I have got the same trouble after restarting a IA64 server running a Debian sid(*) with a 2.6.32-5-mckinley linux kernel. Then booting with a more recent 3.0.0-2-mckinley kernel give a hang on Loading wait... without any clue. I have to go back to Debian wheeze to get it booting again. Regards, Patrice. (*) udev is 172-1 initramfs-tools is 0.99 Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647825: udevd[XXX]: unable to receive ctrl connection: Function not implemented
2011/11/11 Ben Hutchings b...@decadent.org.uk: --- a/arch/ia64/include/asm/unistd.h 2011-03-15 02:20:32.0 +0100 +++ b/arch/ia64/include/asm/unistd.h 2011-11-10 21:27:31.0 +0100 @@ -315,11 +315,12 @@ #define __NR_fanotify_init 1323 #define __NR_fanotify_mark 1324 #define __NR_prlimit64 1325 +#define __NR_accept4 1326 #ifdef __KERNEL__ -#define NR_syscalls 302 /* length of syscall table */ +#define NR_syscalls 303 /* length of syscall table */ /* * The following defines stop scripts/checksyscalls.sh from complaining about --- a/arch/ia64/kernel/entry.S 2011-03-15 02:20:32.0 +0100 +++ b/arch/ia64/kernel/entry.S 2011-11-10 21:32:03.0 +0100 @@ -1771,6 +1771,7 @@ data8 sys_fanotify_init data8 sys_fanotify_mark data8 sys_prlimit64 // 1325 + data8 sys_accept4 .org sys_call_table + 8*NR_syscalls // guard against failures to increase NR_syscalls #endif /* __IA64_ASM_PARAVIRTUALIZED_NATIVE */ The above changes look reasonable; please send them to linux-i...@vger.kernel.org with a signed-off-by line as explained in Documentation/SubmittingPatches. OK, will do. I however imagine that these patches are to be created against current linux-3.2-rc1 source tree, right? One thing that thus worries me is that I won't be able to test the resulting kernel, since that the initramfs-tools 0.99 issue prevents me from running kernel 2.6.38. However, even with these patches applied, test_accept4 still report that accept4() is not implemented :-(. Isn't that because it is using the installed header which doesn't define __NR_accept4? What am I still missing? Don't know can you point to the version of test_accept4 that you are using? I only found the original version which is explicitly for x86 only. Sorry Ben, you were CC'ed too lately in the discussion! I was referring to the test_accept4.c file that I've modified and attached in Message #25 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647825#25). Here's the direct link to get the file: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=test_accept4.c;att=1;bug=647825 Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647825: udevd[XXX]: unable to receive ctrl connection: Function not implemented
2011/11/11 Ben Hutchings b...@decadent.org.uk:
That version just calls the libc implementation of accept4(), which
won't work until libc is rebuilt. You need to define __NR_accept4 and
call syscall(__NR_accept4, ...) in the test program instead.
Isn't Wheezy eglibc 2.13-21 supposed to already implement accept4()?
I've nevertheless modified test_accept.c following your guidelines. I
also had to rename accept4() to __accept4(), otherwise it will
conflict with non-static definition of accept4() in
/usr/include/ia64-linux-gnu/sys/socket.h (isn't this the eglibc
declaration?)
I'm however still getting the error message stating that accept4() is
not implemented, although I've rebuilt my kernel with the patches and
booted the system with it:
emeric@longspeak:~/Documents$ ./test_accept4
===
Calling accept4(): flags = 0
accept4(): Function not implemented
===
Calling accept4(): flags = 8 (SOCK_CLOEXEC)
accept4(): Function not implemented
===
Calling accept4(): flags = 800 (SOCK_NONBLOCK)
accept4(): Function not implemented
===
Calling accept4(): flags = 80800 (SOCK_CLOEXEC SOCK_NONBLOCK)
accept4(): Function not implemented
Is the attached test_accept4.c correctly modified and supposed to work
with the patched kernel or am I missing something else?
Émeric
/* test_accept4.c
Copyright (C) 2008, Linux Foundation, written by Michael Kerrisk
mtk.manpa...@gmail.com
Licensed under the GNU GPLv2 or later.
*/
#define _GNU_SOURCE
#include unistd.h
#include sys/syscall.h
#include sys/socket.h
#include netinet/in.h
#include stdlib.h
#include fcntl.h
#include stdio.h
#include string.h
#define PORT_NUM 3
#define die(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
/**/
/* The following is what we need until glibc gets a wrapper for
accept4() */
/* Flags for socket(), socketpair(), accept4() */
#ifndef SOCK_CLOEXEC
#define SOCK_CLOEXECO_CLOEXEC
#endif
#ifndef SOCK_NONBLOCK
#define SOCK_NONBLOCK O_NONBLOCK
#endif
#define __NR_accept4 1326
static int
__accept4(int fd, struct sockaddr *sockaddr, socklen_t *addrlen, int flags)
{
printf(Calling accept4(): flags = %x, flags);
if (flags != 0) {
printf( ();
if (flags SOCK_CLOEXEC)
printf(SOCK_CLOEXEC);
if ((flags SOCK_CLOEXEC) (flags SOCK_NONBLOCK))
printf( );
if (flags SOCK_NONBLOCK)
printf(SOCK_NONBLOCK);
printf());
}
printf(\n);
return syscall(__NR_accept4, fd, sockaddr, addrlen, flags);
}
/**/
static int
do_test(int lfd, struct sockaddr_in *conn_addr,
int closeonexec_flag, int nonblock_flag)
{
int connfd, acceptfd;
int fdf, flf, fdf_pass, flf_pass;
struct sockaddr_in claddr;
socklen_t addrlen;
printf(===\n);
connfd = socket(AF_INET, SOCK_STREAM, 0);
if (connfd == -1)
die(socket);
if (connect(connfd, (struct sockaddr *) conn_addr,
sizeof(struct sockaddr_in)) == -1)
die(connect);
addrlen = sizeof(struct sockaddr_in);
acceptfd = __accept4(lfd, (struct sockaddr *) claddr, addrlen,
closeonexec_flag | nonblock_flag);
if (acceptfd == -1) {
perror(accept4());
close(connfd);
return 0;
}
fdf = fcntl(acceptfd, F_GETFD);
if (fdf == -1)
die(fcntl:F_GETFD);
fdf_pass = ((fdf FD_CLOEXEC) != 0) ==
((closeonexec_flag SOCK_CLOEXEC) != 0);
printf(Close-on-exec flag is %sset (%s); ,
(fdf FD_CLOEXEC) ? : not ,
fdf_pass ? OK : failed);
flf = fcntl(acceptfd, F_GETFL);
if (flf == -1)
die(fcntl:F_GETFD);
flf_pass = ((flf O_NONBLOCK) != 0) ==
((nonblock_flag SOCK_NONBLOCK) !=0);
printf(nonblock flag is %sset (%s)\n,
(flf O_NONBLOCK) ? : not ,
flf_pass ? OK : failed);
close(acceptfd);
close(connfd);
printf(Test result: %s\n, (fdf_pass flf_pass) ? PASS : FAIL);
return fdf_pass flf_pass;
}
static int
create_listening_socket(int port_num)
{
struct sockaddr_in svaddr;
int lfd;
int optval;
memset(svaddr, 0, sizeof(struct sockaddr_in));
svaddr.sin_family = AF_INET;
svaddr.sin_addr.s_addr = htonl(INADDR_ANY);
svaddr.sin_port = htons(port_num);
lfd = socket(AF_INET, SOCK_STREAM, 0);
if (lfd == -1)
die(socket);
optval = 1;
if (setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, optval,
sizeof(optval)) == -1)
die(setsockopt);
if (bind(lfd, (struct sockaddr *) svaddr,
sizeof(struct sockaddr_in)) == -1)
die(bind);
if (listen(lfd, 5) == -1)
die(listen);
return lfd;
}
int
main(int argc, char *argv[])
{
struct sockaddr_in
Bug#537572: GNOME settings daemon 3.0.3 binaries, with and without -z defs flag passed to the linker
2011/11/10 Jonathan Nieder jrnie...@gmail.com:
Thanks. What would be really useful is a linker command line and the
collection of object files (.o, .a, and .so, including relevant system
libraries from /usr/lib/) that it refers to, as described in
/usr/share/bug/binutils/presubj. Feel free to send these to me by
private mail.
OK, I'm preparing this.
[...]
It's noteworthy however than passing -z defs flag ends up in autoreconf'ing:
- ./plugins/media-keys/gsd-marshal.{h|c}
- ./ltmain.sh
- ./data/gnome-settings-daemon.desktop.in
as can be seen by diff'ing autoreconf.{before|after}.
Hm? When I diff the autoreconf.{before,after} that you sent, I don't
see that at all (the ltmain.sh changes as expected, but the other
files you mentioned were left alone).
Sorry, I was unclear.
autoreconf.{before|after} files exist in both .tbz archives and come
from the build process (this is really how they are named).
Now if you diff broken/autoreconf.before vs. working/autoreconf.before
(not autoreconf.before vs autoreconf.after), and similarly for
autoreconf.after, then you'll see the differences I was talking about.
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647825: udevd[XXX]: unable to receive ctrl connection: Function not implemented
2011/11/10 Ben Hutchings b...@decadent.org.uk: But I do not understand why nobody else noticed this, unless you are the first person to install wheezy on ia64. That seems entirely plausible. Definitely since: - netinst Wheezy CD-ROM is unbootable on ia64 (although Squeeze was fine) - initramfs-tools 0.99 bug prevents from installing kernel 2.6.38 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638068) and Wheezy currently ships with 3.0.0. Unfortunately, I didn't get life signs recently about this initramfs-tools issue :-( The only way to run Wheezy is upgrading from Squeeze, but several packages. I think we need this, which applies cleanly to the current kernel version in squeeze: commit 9ab87644393d789b950ba984fa360f45c4df02e5 Author: Arnd Bergmann a...@arndb.de Date: Thu Dec 10 22:10:31 2009 +0100 asm-generic: add sys_accept4 to unistd.h Can someone test that the attached patch is sufficient to make the new udev work on ia64? (See the instructions at kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.) Since current kernel 3.0.0+39 in Wheezy cannot be installed due to the initramfs-tools 0.99 issue, I tried to apply the patch to last working in Wheezy 2.6.38+34 kernel. Patch was rejected as include/asm-generic/unistd.h in 2.6.38+34 already has __NR_accept4 defined to 242. I know nothing about kernel development, And nothing about ia64 architecture. However, looking at various kernel commits in order to understand how accept4 support was added for other architectures, and also looking at how accept() is currently defined for ia64, I ended up modifying the following files (patches against Wheezy 2.6.38+34 kernel, in attached): --- a/arch/ia64/include/asm/unistd.h2011-03-15 02:20:32.0 +0100 +++ b/arch/ia64/include/asm/unistd.h2011-11-10 21:27:31.0 +0100 @@ -315,11 +315,12 @@ #define __NR_fanotify_init 1323 #define __NR_fanotify_mark 1324 #define __NR_prlimit64 1325 +#define __NR_accept4 1326 #ifdef __KERNEL__ -#define NR_syscalls302 /* length of syscall table */ +#define NR_syscalls303 /* length of syscall table */ /* * The following defines stop scripts/checksyscalls.sh from complaining about --- a/arch/ia64/kernel/entry.S 2011-03-15 02:20:32.0 +0100 +++ b/arch/ia64/kernel/entry.S 2011-11-10 21:32:03.0 +0100 @@ -1771,6 +1771,7 @@ data8 sys_fanotify_init data8 sys_fanotify_mark data8 sys_prlimit64 // 1325 + data8 sys_accept4 .org sys_call_table + 8*NR_syscalls // guard against failures to increase NR_syscalls #endif /* __IA64_ASM_PARAVIRTUALIZED_NATIVE */ --- a/arch/ia64/kernel/fsys.S 2011-03-15 02:20:32.0 +0100 +++ b/arch/ia64/kernel/fsys.S 2011-11-10 21:34:53.0 +0100 @@ -1042,7 +1042,29 @@ data8 0 // tee data8 0 // vmsplice data8 0 - data8 fsys_getcpu // getcpu // 1304 + data8 fsys_getcpu // getcpu + data8 0 // 1305 + data8 0 + data8 0 + data8 0 + data8 0 + data8 0 // 1310 + data8 0 + data8 0 + data8 0 + data8 0 + data8 0 // 1315 + data8 0 + data8 0 + data8 0 + data8 0 + data8 0 // 1320 + data8 0 + data8 0 + data8 0 + data8 0 + data8 0 // 1325 + data8 0 // accept4 // 1326 // fill in zeros for the remaining entries .zero: For fsys.S, I don't know if adding data8 0 lines like I did in order to match accept4() 1326 define with unistd.h and entry.S is required or not. If yes, well, table hasn't been updated from quite some time then! However, even with these patches applied, test_accept4 still report that accept4() is not implemented :-(. What am I still missing? Émeric --- a/arch/ia64/include/asm/unistd.h 2011-03-15 02:20:32.0 +0100 +++ b/arch/ia64/include/asm/unistd.h 2011-11-10 21:27:31.0 +0100 @@ -315,11 +315,12 @@ #define __NR_fanotify_init 1323 #define __NR_fanotify_mark 1324 #define __NR_prlimit64 1325 +#define __NR_accept4 1326 #ifdef __KERNEL__ -#define NR_syscalls 302 /* length of syscall table */ +#define NR_syscalls 303 /* length of syscall table */ /* * The following defines stop scripts/checksyscalls.sh from complaining about --- a/arch/ia64/kernel/entry.S 2011-03-15 02:20:32.0 +0100 +++ b/arch/ia64/kernel/entry.S 2011-11-10 21:32:03.0 +0100 @@ -1771,6 +1771,7 @@ data8 sys_fanotify_init data8
Bug#647825: udevd[XXX]: unable to receive ctrl connection: Function not implemented
Marco,
Adapting test_accept4.c from de11defebf7677fb7ee91d9b089b78786fbb
(modified source file attached), I'm getting:
emeric@longspeak:~$ ./test_accept4
===
accept4(): Function not implemented
===
accept4(): Function not implemented
===
accept4(): Function not implemented
===
accept4(): Function not implemented
Well, it seems that the problem isn't in fact that SOCK_CLOEXEC isn't
implemented on ia64, but simply that sys_accept4() isn't implemented,
right?
Is it thus a kernel-related issued rather than an udev one?
Émeric
2011/11/7 Marco d'Itri m...@linux.it:
On Nov 07, Émeric Maschino emeric.masch...@gmail.com wrote:
It seems that SOCK_CLOEXEC is thus correctly defined, don't you think so?
Yes, but this does not mean that it is also implemented.
/* test_accept4.c
Copyright (C) 2008, Linux Foundation, written by Michael Kerrisk
mtk.manpa...@gmail.com
Licensed under the GNU GPLv2 or later.
*/
#define _GNU_SOURCE
#include unistd.h
#include sys/syscall.h
#include sys/socket.h
#include netinet/in.h
#include stdlib.h
#include fcntl.h
#include stdio.h
#include string.h
#define PORT_NUM 3
#define die(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
/**/
static int
do_test(int lfd, struct sockaddr_in *conn_addr,
int closeonexec_flag, int nonblock_flag)
{
int connfd, acceptfd;
int fdf, flf, fdf_pass, flf_pass;
struct sockaddr_in claddr;
socklen_t addrlen;
printf(===\n);
connfd = socket(AF_INET, SOCK_STREAM, 0);
if (connfd == -1)
die(socket);
if (connect(connfd, (struct sockaddr *) conn_addr,
sizeof(struct sockaddr_in)) == -1)
die(connect);
addrlen = sizeof(struct sockaddr_in);
acceptfd = accept4(lfd, (struct sockaddr *) claddr, addrlen,
closeonexec_flag | nonblock_flag);
if (acceptfd == -1) {
perror(accept4());
close(connfd);
return 0;
}
fdf = fcntl(acceptfd, F_GETFD);
if (fdf == -1)
die(fcntl:F_GETFD);
fdf_pass = ((fdf FD_CLOEXEC) != 0) ==
((closeonexec_flag SOCK_CLOEXEC) != 0);
printf(Close-on-exec flag is %sset (%s); ,
(fdf FD_CLOEXEC) ? : not ,
fdf_pass ? OK : failed);
flf = fcntl(acceptfd, F_GETFL);
if (flf == -1)
die(fcntl:F_GETFD);
flf_pass = ((flf O_NONBLOCK) != 0) ==
((nonblock_flag SOCK_NONBLOCK) !=0);
printf(nonblock flag is %sset (%s)\n,
(flf O_NONBLOCK) ? : not ,
flf_pass ? OK : failed);
close(acceptfd);
close(connfd);
printf(Test result: %s\n, (fdf_pass flf_pass) ? PASS : FAIL);
return fdf_pass flf_pass;
}
static int
create_listening_socket(int port_num)
{
struct sockaddr_in svaddr;
int lfd;
int optval;
memset(svaddr, 0, sizeof(struct sockaddr_in));
svaddr.sin_family = AF_INET;
svaddr.sin_addr.s_addr = htonl(INADDR_ANY);
svaddr.sin_port = htons(port_num);
lfd = socket(AF_INET, SOCK_STREAM, 0);
if (lfd == -1)
die(socket);
optval = 1;
if (setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, optval,
sizeof(optval)) == -1)
die(setsockopt);
if (bind(lfd, (struct sockaddr *) svaddr,
sizeof(struct sockaddr_in)) == -1)
die(bind);
if (listen(lfd, 5) == -1)
die(listen);
return lfd;
}
int
main(int argc, char *argv[])
{
struct sockaddr_in conn_addr;
int lfd;
int port_num;
int passed;
passed = 1;
port_num = (argc 1) ? atoi(argv[1]) : PORT_NUM;
memset(conn_addr, 0, sizeof(struct sockaddr_in));
conn_addr.sin_family = AF_INET;
conn_addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
conn_addr.sin_port = htons(port_num);
lfd = create_listening_socket(port_num);
if (!do_test(lfd, conn_addr, 0, 0))
passed = 0;
if (!do_test(lfd, conn_addr, SOCK_CLOEXEC, 0))
passed = 0;
if (!do_test(lfd, conn_addr, 0, SOCK_NONBLOCK))
passed = 0;
if (!do_test(lfd, conn_addr, SOCK_CLOEXEC, SOCK_NONBLOCK))
passed = 0;
close(lfd);
exit(passed ? EXIT_SUCCESS : EXIT_FAILURE);
}
Bug#647825: udevd[XXX]: unable to receive ctrl connection: Function not implemented
Hello Marco, 2011/11/6 Marco d'Itri m...@linux.it: On Nov 06, Émeric Maschino emeric.masch...@gmail.com wrote: Starting with udev 170 (well, IIRC!), console is flooded at startup with: udevd[XXX]: unable to receive ctrl connection: Function not implemented Your lacks support for SOCK_CLOEXEC on accept, why? Well, emeric@longspeak:~$ rgrep SOCK_CLOEXEC /usr/src/linux-source-2.6.38 most notably gives: /usr/src/linux-source-2.6.38/include/linux/net.h:#define SOCK_CLOEXECO_CLOEXEC Looking at net.h, I can see that SOCK_CLOEXEC is an unconditional definition. So, no problem there. What about O_CLOEXEC then? emeric@longspeak:~$ rgrep O_CLOEXEC /usr/src/linux-source-2.6.38 most notably gives: /usr/src/linux-source-2.6.38/include/asm-generic/fcntl.h:#define O_CLOEXEC 0200/* set close_on_exec */ /usr/src/linux-source-2.6.38/arch/alpha/include/asm/fcntl.h:#define O_CLOEXEC 01000 /* set close_on_exec */ /usr/src/linux-source-2.6.38/arch/mips/include/asm/socket.h:#define SOCK_CLOEXECO_CLOEXEC /usr/src/linux-source-2.6.38/arch/parisc/include/asm/fcntl.h:#define O_CLOEXEC 01000 /* set close_on_exec */ /usr/src/linux-source-2.6.38/arch/sparc/include/asm/fcntl.h:#define O_CLOEXEC 0x40 Here again, O_CLOEXEC is unconditionally defined to 0200 in fcntl.h and redefined for alpha, mips, parisc and sparc architectures only. It seems that SOCK_CLOEXEC is thus correctly defined, don't you think so? It is supposed to be available since 2.6.27. This is with latest installable on ia64 Wheezy kernel 2.6.38. Is there a way to check for SOCK_CLOEXEC symbol in the currently running kernel? This should give a definitive answer regardless SOCK_CLOEXEC support. Does the old_cloexec patch included up to release 164-4 fix this for you? Yes, udev 164-4 is fine (no error message, /dev correctly populated). Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647825: udevd[XXX]: unable to receive ctrl connection: Function not implemented
Package: udev Version: 172-1 Severity: important Hello, Starting with udev 170 (well, IIRC!), console is flooded at startup with: udevd[XXX]: unable to receive ctrl connection: Function not implemented where XXX is a number (PID?). And system takes ~3 min. to get login prompt. Last udev version not displaying this message was 167. However, /dev was nearly empty. Last fully working udev (i.e. no error message and /dev correctly populated) was 164(-3). This is on a Itanium (ia64/IA-64/IPF) workstation. I didn't find much references about this problem, except http://mintppc.org/forums/viewtopic.php?f=10t=350 on PowerPC G4. Upgrading the kernel seems to solve the problem there. Due to a serious issue with initramfs-tools 0.99 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638068), we're stuck with kernel 2.6.39 on ia64 at this time. However, upgrading to linux-image-3.0.0-1-mckinley (generating initramfs with initramfs-tools 0.98.8 from another running system) didn't make the error go away. I can try intermediate udev builds on snapshot.debian.org if helpful. Émeric -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: ia64 Kernel: Linux 2.6.38-2-mckinley (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages udev depends on: ii debconf [debconf-2.0] 1.5.40 ii libc6.12.13-21 ii libselinux12.1.0-1 ii libudev0 164-3 ii libusb-0.1-4 2:0.1.12-19 ii lsb-base 3.2-28 ii util-linux 2.19.1-5 Versions of packages udev recommends: ii pciutils 1:3.1.7-12 ii usbutils 1:004-2 udev suggests no packages. -- debconf information: udev/new_kernel_needed: false udev/title/upgrade: udev/reboot_needed: udev/sysfs_deprecated_incompatibility: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638068: initramfs-tools status?
Hi, Any progress on this? How can I help further? It's still impossible to either install Wheezy on ia64 from Debian netinst CD or upgrade from a running Lenny system as kernel 2.6.38 need initramfs-tools 0.99 that produces unbootable initrd images. Best regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
Hello Mike,
2011/10/6 Mike Hommey m...@glandium.org:
That would waste a 64-bits word. The usual way to do it is to use
unions:
union {
PRUint64 dummy;
struct {
PRUint32 m0;
PRUint16 m1;
PRUint16 m2;
};
};
Mike
nsID 64-bit alignment issue was already tracked down:
https://bugzilla.mozilla.org/show_bug.cgi?id=660335.
From what I understand, patch V3 performs struct alignment using GCC
or MSVC-specific keywords. Iceweasel 7.0.1-2 in current Debian
Wheezy Testing doesn't seem to include this patch (yet).
I'll apply it locally in order to check if other unaligned accesses
nevertheless surface.
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
2011/10/6 Mike Hommey m...@glandium.org:
On Thu, Oct 06, 2011 at 12:21:29AM +0200,
That would waste a 64-bits word. The usual way to do it is to use
unions:
union {
PRUint64 dummy;
struct {
PRUint32 m0;
PRUint16 m1;
PRUint16 m2;
};
};
Thanks for pointing this out. I've never seen such a construction before.
BTW, what's better/cleaner? Align nsID or adapt Equals to make 32-bit
words comparison? Is the following code OK:
inline PRBool Equals(const nsID other) const {
return
((PRUint32*) m0)[0] == ((PRUint32*) other.m0)[0]
((PRUint32*) m1)[0] == ((PRUint32*) other.m1)[0]
((PRUint32*) m3)[0] == ((PRUint32*) other.m3)[0]
((PRUint32*) m3)[1] == ((PRUint32*) other.m3)[1];
}
Emeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
2011/10/4 Mike Hommey m...@glandium.org:
On Tue, Oct 04, 2011 at 10:20:16PM +0200,
m0 is a 32-bit value, it needs 32-bits alignment. m1 is 16-bits, 16-bits
alignment, etc. Overall, the struct only requires 32-bits alignment.
Reading http://en.wikipedia.org/wiki/Data_structure_alignment, I
thought that gcc was padding the internal data of a structure so that
they are aligned. Furthermore, isn't nsID internal data nevertheless
packed on 16 bytes after compilation (it is 4+2+2+8 = 16 bytes before
compilation)?
If explicit 64-bit alignment is still required, do we need to add
dummy padding data to align nsID internal data? Such as (with
alignment recommendations taken from
http://software.intel.com/en-us/articles/data-alignment-when-migrating-to-64-bit-intel-architecture/):
struct nsID {
PRUint32 m0;
PRUint16 m1;
PRUint16 padding[1]; // 2 bytes for m2 to be aligned on a 4-byte boundary (*)
PRUint16 m2;
PRUint8 m3[8];
PRUint8 padding[6]; // 6 bytes to make total size of nsID 24 bytes
};
Emeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
2011/10/5 Mike Hommey m...@glandium.org:
On Wed, Oct 05, 2011 at 10:50:56AM +0200,
The problem is not the alignment of m2, the problem is the alignment of
the whole struct, which has a requirement of 32-bits. Which means a
struct nsID can end up at 0x0, 0x4, 0x8, or 0xc. When it's at 0x4 or
0xc, it can't be casted to a 64-bits word, because that's not 64-bits
aligned. There are two solutions: make sure struct nsIDs are 64-bits
aligned, or change the Equals function to use 2 32 bits words
comparisons.
Sorry, I thought that padding nsID like I did in my previous comment
was the way to make it 64-bit aligned :-(
How then can it be modified to make it 64-bit aligned?
Alternatively, if changing Equals to use 32-bit words comparisons,
will it become:
inline PRBool Equals(const nsID other) const {
return
((PRUint32*) m0)[0] == ((PRUint32*) other.m0)[0]
((PRUint32*) m1)[0] == ((PRUint32*) other.m1)[0]
((PRUint32*) m3)[0] == ((PRUint32*) other.m3)[0]
((PRUint32*) m3)[1] == ((PRUint32*) other.m3)[1];
}
Emeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
OK, reading http://www.osronline.com/ddkx/kmarch/64bitamd_20iv.htm
helped me understand structure alignment (well, I think!): The
alignment of the beginning of a structure or a union is the maximum
alignment of any individual member.
2011/10/5 Mike Hommey m...@glandium.org:
On Wed, Oct 05, 2011 at 10:50:56AM +0200,
The problem is not the alignment of m2, the problem is the alignment of
the whole struct, which has a requirement of 32-bits. Which means a
struct nsID can end up at 0x0, 0x4, 0x8, or 0xc. When it's at 0x4 or
0xc, it can't be casted to a 64-bits word, because that's not 64-bits
aligned. There are two solutions: make sure struct nsIDs are 64-bits
aligned, or change the Equals function to use 2 32 bits words
comparisons.
So, in order to have nsID 64-bit aligned, is simply inserting a
PRUint64 dummy internal data the way to enforce 64-bit alignment?
struct nsID {
PRUint64 dummy;
PRUint32 m0;
PRUint16 m1;
PRUint16 m2;
PRUint8 m3[8];
};
Emeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
Sorry for the late reply.
2011/9/28 Mike Hommey m...@glandium.org:
On Tue, Sep 27, 2011 at 10:32:17PM +0200, Émeric Maschino wrote:
Thanks so in fact the error is on the next line, and is due to this
code:
inline PRBool Equals(const nsID other) const {
return
((PRUint64*) m0)[0] == ((PRUint64*) other.m0)[0]
((PRUint64*) m0)[1] == ((PRUint64*) other.m0)[1];
}
Mike
Wow! How did you figure this? From the assembly output?
I still understand what's wrong with this code. nsID is defined as:
struct nsID {
PRUint32 m0;
PRUint16 m1;
PRUint16 m2;
PRUint8 m3[8];
...
};
It seems 64-bit aligned to me.
And if I understand Equals code correctly, (PRUint64*)[0] is a 64-bit
word with packed data of m0, m1 and m2 (32+16+16 = 64 bits) and
(PRUint64*)[1] is another 64-bit word with m3 data (8*8 = 64 bits).
Am I right? How can this be unaligned then?
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
I don't understand. What prevent nsID from being 64-bit aligned? Don't
m0, m1 and m2 fit in a 64-bit word and m3 in yet another one?
Émeric
2011/10/4 Mike Hommey m...@glandium.org:
On Tue, Oct 04, 2011 at 08:11:17PM +0200, Émeric Maschino wrote:
struct nsID {
PRUint32 m0;
PRUint16 m1;
PRUint16 m2;
PRUint8 m3[8];
...
};
Because the struct you copy/pasted is 32-bits aligned.
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
2011/9/27 Mike Hommey m...@glandium.org: Could you add the output for disassemble and info registers ? Mike Sure! Please find the attached gdb.txt. Émeric (gdb) run Starting program: /usr/lib/iceweasel/firefox-bin [Thread debugging using libthread_db enabled] [New Thread 0x700088cb1e0 (LWP 5714)] [New Thread 0x700091371e0 (LWP 5715)] Program received signal SIGBUS, Bus error. 0x0700033b3130 in NS_TableDrivenQI (aThis=0x70007174f40, entries=0x70004008fb8, aIID=..., aInstancePtr=0x70007168c58) at /build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/build-xulrunner/xpcom/build/nsISupportsImpl.cpp:44 44 /build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/build-xulrunner/xpcom/build/nsISupportsImpl.cpp: Aucun fichier ou dossier de ce type. in /build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/build-xulrunner/xpcom/build/nsISupportsImpl.cpp (gdb) x 0x700033b3130 0x700033b3130 NS_TableDrivenQI(void*, QITableEntry const*, nsID const, void**)+48: 0x44208809 (gdb) x 0x70004008fb8 0x70004008fb8 _ZZN15nsSupportsArray14QueryInterfaceERK4nsIDPPvE5table: 0x0390ab74 (gdb) p entries $1 = (const QITableEntry *) 0x70004008fb8 (gdb) p entries-iid $2 = (const nsIID *) 0x7000390ab74 (gdb) p entries-offset $3 = 0 (gdb) disassemble Dump of assembler code for function NS_TableDrivenQI(void*, QITableEntry const*, nsID const, void**): 0x0700033b3100 +0: [MMI] alloc r37=ar.pfs,8,7,0 0x0700033b3101 +1: ld8 r14=[r33] 0x0700033b3102 +2: mov r36=b0 0x0700033b3110 +16:[MMI] mov r38=r1 0x0700033b3111 +17:mov r15=r33 0x0700033b3112 +18:adds r18=16,r33;; 0x0700033b3120 +32:[MIB] nop.m 0x0 0x0700033b3121 +33:cmp.eq p6,p7=0,r14 0x0700033b3122 +34: (p06) br.cond.dpnt.few 0x700033b31a0 NS_TableDrivenQI(void*, QITableEntry const*, nsID const, void**)+160;; = 0x0700033b3130 +48:[MMI] ld8 r17=[r34],8 0x0700033b3131 +49:nop.m 0x0 0x0700033b3132 +50:nop.i 0x0;; 0x0700033b3140 +64:[MMI] nop.m 0x0 0x0700033b3141 +65:ld8 r16=[r14] 0x0700033b3142 +66:nop.i 0x0;; 0x0700033b3150 +80:[MIB] nop.m 0x0 0x0700033b3151 +81:cmp.eq p7,p6=r17,r16 0x0700033b3152 +82: (p07) br.cond.dpnt.few 0x700033b31d0 NS_TableDrivenQI(void*, QITableEntry const*, nsID const, void**)+208 0x0700033b3160 +96:[MMI] adds r15=16,r15;; 0x0700033b3161 +97:sub r14=r15,r33 0x0700033b3162 +98:nop.i 0x0;; 0x0700033b3170 +112: [MMI] add r14=r14,r18;; 0x0700033b3171 +113: adds r14=-16,r14 0x0700033b3172 +114: nop.i 0x0;; 0x0700033b3180 +128: [MMI] nop.m 0x0 0x0700033b3181 +129: ld8 r14=[r14] 0x0700033b3182 +130: nop.i 0x0;; 0x0700033b3190 +144: [MIB] nop.m 0x0 0x0700033b3191 +145: cmp.eq p7,p6=0,r14 0x0700033b3192 +146: (p06) br.cond.dptk.few 0x700033b3140 NS_TableDrivenQI(void*, QITableEntry const*, nsID const, void**)+64 0x0700033b31a0 +160: [MMI] nop.m 0x0 0x0700033b31a1 +161: st8 [r35]=r0 0x0700033b31a2 +162: mov.i ar.pfs=r37 0x0700033b31b0 +176: [MLX] nop.m 0x0 0x0700033b31b1 +177: movl r8=0x80004002;; 0x0700033b31c0 +192: [MIB] nop.m 0x0 0x0700033b31c1 +193: mov b0=r36 0x0700033b31c2 +194: br.ret.sptk.many b0 0x0700033b31d0 +208: [MMI] adds r14=8,r14 0x0700033b31d1 +209: ld8 r16=[r34] 0x0700033b31d2 +210: nop.i 0x0;; 0x0700033b31e0 +224: [MMI] nop.m 0x0 0x0700033b31e1 +225: ld8 r14=[r14] 0x0700033b31e2 +226: nop.i 0x0;; 0x0700033b31f0 +240: [MIB] nop.m 0x0 0x0700033b31f1 +241: cmp.eq p7,p6=r14,r16 0x0700033b31f2 +242: (p06) br.cond.dptk.few 0x700033b3160 NS_TableDrivenQI(void*, QITableEntry const*, nsID const, void**)+96 0x0700033b3200 +256: [MMI] adds r15=8,r15;; 0x0700033b3201 +257: ld4 r33=[r15] 0x0700033b3202 +258: nop.i 0x0;; 0x0700033b3210 +272: [MII] nop.m 0x0 0x0700033b3211 +273: sxt4 r33=r33;; 0x0700033b3212 +274: add r33=r32,r33;; 0x0700033b3220 +288: [MII] ld8 r8=[r33] 0x0700033b3221 +289: mov r39=r33;; 0x0700033b3222 +290: adds r8=16,r8;; 0x0700033b3230 +304: [MMI] ld8 r14=[r8],8;; 0x0700033b3231 +305: nop.m
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
Mike,
2011/9/25 Mike Hommey m...@glandium.org:
nsISupportsImpl.cpp:44 is:
while (entries-iid) {
entries is 0x70004008fb8, and its type is a pointer to:
struct QITableEntry
{
const nsIID *iid;
PROffset32 offset;
};
I fail to see how this can be unaligned...
What is the corresponding address of that particular SIGBUS?
Reporting and helping debugging unaligned access is new to me and I
can't find any decent howto on the web. So, I'm not sure to fully
understand what exactly you need :-(.
Do you simply want to check that the memory address of the SIGBUS is
indeed pointing to NS_TableDrivenQI()?
In an other debug session, here is what I've recorded:
(gdb) run
Starting program: /usr/lib/iceweasel/firefox-bin
[Thread debugging using libthread_db enabled]
[New Thread 0x700088c71e0 (LWP 4310)]
[New Thread 0x700091331e0 (LWP 4311)]
Program received signal SIGBUS, Bus error.
0x0700033b3130 in NS_TableDrivenQI (aThis=0x70007174f40, entries=0x70004008f
b8, aIID=..., aInstancePtr=0x70007168c58) at /build/buildd-iceweasel_6.0.2-1-ia6
4-HBKkq9/iceweasel-6.0.2/build-xulrunner/xpcom/build/nsISupportsImpl.cpp:44
44 /build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/build-xulrun
ner/xpcom/build/nsISupportsImpl.cpp: Aucun fichier ou dossier de ce type.
in /build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/build-xul
runner/xpcom/build/nsISupportsImpl.cpp
(gdb) x 0x700033b3130
0x700033b3130 NS_TableDrivenQI(void*, QITableEntry const*, nsID const, void**)
+48: 0x44208809
(gdb) x 0x70004008fb8
0x70004008fb8 _ZZN15nsSupportsArray14QueryInterfaceERK4nsIDPPvE5table:
0x0390ab74
(gdb) p entries
$1 = (const QITableEntry *) 0x70004008fb8
(gdb) p entries-iid
$2 = (const nsIID *) 0x7000390ab74
(gdb) p entries-offset
$3 = 0
Does it answer your question or not at all?
FYI, no unaligned access message is logged (neither in the console
/var/log/kern.log, /var/log/messages or /var/log/syslog) while in GDB.
Is this what you would like that I try to catch while running
Iceweasel in GDB?
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
Mike,
2011/9/25 Mike Hommey m...@glandium.org:
nsISupportsImpl.cpp:44 is:
while (entries-iid) {
entries is 0x70004008fb8, and its type is a pointer to:
struct QITableEntry
{
const nsIID *iid;
PROffset32 offset;
};
I fail to see how this can be unaligned...
What is the corresponding address of that particular SIGBUS?
Do you simply want the memory address (the ip value in the unaligned
access message) or something else?
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642750: epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Package: epiphany-browser Version: 3.0.4-1 Severity: important Epiphany is barely usable on ia64 platform (crashes *VERY* frequently). Steps to reproduce: - start up Epiphany; default page is http://www.debian.org - go to http://www.google.fr and search for Debian - click on the second Google hit (links to www.debian.org); the Debian homepage is displayed, as expected - click on the Epiphany Back button; you're back to the Google results page, as expected - click again on the link to www.debian.org in the Google results page; Epiphany received signal SIGSEGV in (missing?) WriteBarrier.h (see attached gdb.txt for details). I don't know if the missing WriteBarrier.h is expected. I have libwebkitgtk-3.0-0-dbg and libwebkitgtk-1.0-0-dbg 1.4.2-2 packages installed on my system. If it can help further, the following messages are recorded on the console if I reproduce the above steps, starting Epiphany from a terminal (not running it from gdb): ** Message: console message: undefined @0: 1.445053577918228e-154 ** Message: console message: undefined @0: 1.4450535779182651e-154 ** Message: console message: undefined @0: 1.445053577918293e-154 ** Message: console message: undefined @0: 1.4450535779183208e-154 ** Message: console message: undefined @0: 1.4450535779183486e-154 ** Message: console message: undefined @0: 1.4450535779183857e-154 ** Message: console message: undefined @0: 1.4450535779184135e-154 ** Message: console message: undefined @0: 1.4450535779184413e-154 ** Message: console message: undefined @0: 1.4450535779186732e-154 ** Message: console message: undefined @0: 1.445053577918701e-154 ** Message: console message: undefined @0: 1.4450535779187567e-154 ** Message: console message: undefined @0: 1.4450535779187845e-154 ** Message: console message: undefined @0: 1.4450535779188308e-154 ** Message: console message: undefined @0: 1.4450535779188587e-154 ** Message: console message: undefined @0: 1.4450535779188958e-154 ** Message: console message: undefined @0: 1.4450535779189236e-154 ** Message: console message: undefined @0: 1.4450535779189514e-154 ** Message: console message: undefined @0: 1.4450535779189792e-154 ** Message: console message: undefined @0: 1.445053577919007e-154 ** Message: console message: undefined @0: 1.4450535779190349e-154 ** Message: console message: undefined @0: 1.4450535779190627e-154 Segmentation fault. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: ia64 Kernel: Linux 2.6.38-2-mckinley (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages epiphany-browser depends on: ii dbus-x11 1.4.14-1 ii epiphany-browser-data 3.0.4-1 ii gnome-icon-theme 3.0.0-4 ii gsettings-desktop-schemas 3.0.1-1 ii iso-codes 3.28-1 ii libavahi-client3 0.6.30-5 ii libavahi-common3 0.6.30-5 ii libavahi-gobject0 0.6.30-5 ii libc6.12.13-21 ii libcairo2 1.10.2-6.1 ii libdbus-1-31.4.14-1 ii libdbus-glib-1-2 0.94-4 ii libgdk-pixbuf2.0-0 2.24.0-1 ii libgirepository-1.0-1 0.10.8-2 ii libglib2.0-0 2.28.6-1 ii libgnome-keyring0 3.0.0-2 ii libgtk-3-0 3.0.12-2 ii libice62:1.0.7-2 ii libnspr4-0d4.8.9-1 ii libnss3-1d 3.12.11-3 ii libpango1.0-0 1.28.4-3 ii libsm6 2:1.2.0-2 ii libsoup-gnome2.4-1 2.34.3-1 ii libsoup2.4-1 2.34.3-1 ii libunwind7 0.99-0.3 ii libwebkitgtk-3.0-0 1.4.2-2 ii libx11-6 2:1.4.4-1 ii libxml22.7.8.dfsg-4 ii libxslt1.1 1.1.26-8 Versions of packages epiphany-browser recommends: ii ca-certificates 20110502+nmu1 ii evince 2.32.0-1 ii yelp 2.30.1+webkit-1+b1 Versions of packages epiphany-browser suggests: pn epiphany-extensions none -- no debconf information Starting program: /usr/bin/epiphany-browser [Thread debugging using libthread_db enabled] [New Thread 0x28a06f70 (LWP 2718)] [New Thread 0x29206f70 (LWP 2719)] [New Thread 0x20001542ef70 (LWP 2720)] [New Thread 0x200015fbef70 (LWP 2721)] [New Thread 0x200016bc6f70 (LWP 2722)] [New Thread 0x2000177def70 (LWP 2723)] [New Thread 0x200017fdef70 (LWP 2724)] [New Thread 0x20001880af70 (LWP 2725)] [New Thread 0x20001900ef70 (LWP 2726)] [New Thread 0x200019826f70 (LWP 2727)] [New Thread 0x20001a03af70 (LWP 2728)] [New Thread 0x20001a83af70 (LWP 2729)] [New Thread 0x20001b03af70 (LWP 2730)] [New Thread 0x20001b83af70 (LWP 2731)] [Thread 0x20001b03af70 (LWP 2730) exited] [Thread 0x20001880af70 (LWP 2725) exited] [Thread 0x20001a03af70 (LWP 2728) exited] [Thread
Bug#642762: xulrunner-6.0: console flooded with unaligned access messages on ia64 (IA-64/IPF/Itanium) platform
Package: xulrunner-6.0
Version: 6.0.2-1
Severity: normal
As Iceweasel 6.0 (more precisely the JS engine as I understand it
correctly) is currently being (actively?) debugged on ia64 (and
probably other platforms too), I think it may be useful to report the
various unaligned access messages reported on the console. It could
help fixing various issues hard to reproduce (e.g. X display fonts
corruption, Iceweasel bitmap buttons corruption) and also improve
overall performances on ia64 as unaligned accesses have a cost.
So, running Iceweasel 6.0.2-1 currently in Debian Wheezy Testing,
and letting it run without doing anything, the console is flooded with
unaligned access messages like:
[ 6638.775640] ia64_handle_unaligned: 36911 callbacks suppressed
[ 6638.775648] firefox-bin(4081): unaligned access to
0x0700038103d4, ip=0x070002a3b9d1
[ 6638.775655] firefox-bin(4081): unaligned access to
0x0700039492f4, ip=0x070002a3bb31
[ 6638.775661] firefox-bin(4081): unaligned access to
0x07000391331c, ip=0x070002a3bb61
[ 6638.775667] firefox-bin(4081): unaligned access to
0x07000390291c, ip=0x070002a3bbc1
[ 6638.775673] firefox-bin(4081): unaligned access to
0x070003949304, ip=0x070002a3bcb1
Running prctl --unaligned=signal iceweasel -g to catch them gives a
first hit in NS_TableDrivenQI (see attached gdb.txt).
Hope this helps,
Émeric
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: ia64
Kernel: Linux 2.6.38-2-mckinley (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages xulrunner-6.0 depends on:
ii libasound21.0.24.1-4
ii libatk1.0-0 2.0.1-2
ii libbz2-1.01.0.5-7
ii libc6.1 2.13-21
ii libcairo2 1.10.2-6.1
ii libdbus-1-3 1.4.14-1
ii libevent-1.4-21.4.14b-stable-1
ii libfontconfig12.8.0-3
ii libfreetype6 2.4.6-2
ii libgcc1 1:4.6.1-4
ii libgdk-pixbuf2.0-02.24.0-1
ii libglib2.0-0 2.28.6-1
ii libgtk2.0-0 2.24.4-3
ii libhunspell-1.2-0 1.2.14-4
ii libjpeg8 8c-2
ii libmozjs6d6.0.2-1
ii libnspr4-0d 4.8.9-1
ii libnss3-1d3.12.11-3
ii libpango1.0-0 1.28.4-3
ii libpixman-1-0 0.22.2-1
ii libreadline6 6.2-4
ii libsqlite3-0 3.7.7-2
ii libstartup-notification0 0.12-1
ii libstdc++64.6.1-4
ii libunwind70.99-0.3
ii libvpx0 0.9.7.p1-1
ii libx11-6 2:1.4.4-1
ii libxext6 2:1.3.0-3
ii libxrender1 1:0.9.6-2
ii libxt61:1.1.1-2
ii zlib1g1:1.2.3.4.dfsg-3
xulrunner-6.0 recommends no packages.
Versions of packages xulrunner-6.0 suggests:
ii libcanberra0 0.28-1
ii libdbus-glib-1-2 0.94-4
ii libgconf2-4 2.32.4-1
ii libgnomeui-0 2.24.5-2
ii libgnomevfs2-01:2.24.4-1
ii libnotify40.7.4-1
-- no debconf information
Starting program: /usr/lib/iceweasel/firefox-bin
[Thread debugging using libthread_db enabled]
[New Thread 0x700088c71e0 (LWP 4065)]
[New Thread 0x700091331e0 (LWP 4066)]
Program received signal SIGBUS, Bus error.
0x0700033b3130 in NS_TableDrivenQI (aThis=0x70007174f40,
entries=0x70004008fb8, aIID=..., aInstancePtr=0x70007168c58) at
/build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/build-xulrunner/xpcom/build/nsISupportsImpl.cpp:44
44
/build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/build-xulrunner/xpcom/build/nsISupportsImpl.cpp:
Aucun fichier ou dossier de ce type.
in
/build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/build-xulrunner/xpcom/build/nsISupportsImpl.cpp
#0 0x0700033b3130 in NS_TableDrivenQI (aThis=0x70007174f40,
entries=0x70004008fb8, aIID=..., aInstancePtr=0x70007168c58) at
/build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/build-xulrunner/xpcom/build/nsISupportsImpl.cpp:44
No locals.
#1 0x0700033f5a70 in nsSupportsArray::QueryInterface (this=0x70007174f40,
aIID=..., aInstancePtr=0x70007168c58) at
/build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/xpcom/ds/nsSupportsArray.cpp:219
rv = 2147500037
table = {{iid = 0x7000390ab74, offset = 0}, {iid = 0x7000399b7d0,
offset = 0}, {iid = 0x700038112ac, offset = 0}, {iid = 0x7000380c3b4, offset =
0}, {iid = 0x0, offset = 0}}
#2 0x0700033f7900 in nsSupportsArray::Create (aOuter=0x0, aIID=...,
aResult=0x70007168c58) at
/build/buildd-iceweasel_6.0.2-1-ia64-HBKkq9/iceweasel-6.0.2/xpcom/ds/nsSupportsArray.cpp:216
it = {nsCOMPtr_base = {mRawPtr = 0x0}, No data fields}
#3 0x070003411510 in nsDirectoryService::RealInit () at
Bug#642145: iceweasel: segfault at startup in /usr/lib/xulrunner-5.0/libmozjs.so
Is this related to build problem with gcc 4.6: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635153 (g++-4.6: ICE on ia64 when building iceweasel 5.0-4)? Is it worth reporting further issues against Iceweasel 5.0-6 or is it better to play and report bugs against Iceweasel 6.0-2 right now? Epiphany also randomly crashes and Chromium isn't available on ia64. So, graphical web browser choice is scarce ;-) Emeric 2011/9/20 Mike Hommey m...@glandium.org: On Mon, Sep 19, 2011 at 10:09:41PM +0200, 6.0.2-1 is available in unstable. 5.0-6 is known to be broken on ia64. 6.0.2-1 should work better, though may crash randomly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642145: iceweasel: segfault at startup in /usr/lib/xulrunner-5.0/libmozjs.so
2011/9/20 Mike Hommey m...@glandium.org: Not at all, it's the js engine that doesn't work on ia64, and the patches to make it moslty work have been applied to 6.0.2-1 https://bugzilla.mozilla.org/show_bug.cgi?id=589735 seems a good candidate. Is it worth reporting further issues against Iceweasel 5.0-6 or is it better to play and report bugs against Iceweasel 6.0-2 right now? The latter, please :) Will do. Thanks, Emeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642153: qtcreator: Program received signal SIGBUS, Bus error at startup
Package: qtcreator
Version: 1.3.1-3
Severity: important
Qt Creator crashes at startup with a bus error. I can briefly see the
main window being drawn (completely empty, just the Qt Creator title
window, with Qt Creator icon and system buttons are shown).
I don't know if it will help, but console also reports unaligned
accesses (ia64-specific issues?) and QSslSocket messages:
emeric@longspeak:~$ qtcreator
qtcreator.bin(11188): unaligned access to 0x2000121ade0e,
ip=0x2cd9c0c1
qtcreator.bin(11188): unaligned access to 0x2000121ade76,
ip=0x2cd9bfc0
qtcreator.bin(11188): unaligned access to 0x2000121adede,
ip=0x2cd9c0c1
qtcreator.bin(11188): unaligned access to 0x2000121adee6,
ip=0x2cd9c0c1
qtcreator.bin(11188): unaligned access to 0x2000121adeee,
ip=0x2cd9c0c1
QSslSocket: cannot resolve SSLv2_client_method
QSslSocket: cannot resolve SSLv2_server_method
Bus error
I remember having used Qt Creator successfully in the past (I don't
remember which version though). Strangely enough, all qtcreator
packages available in snapshot.debian.org are dying with a bus error.
I thus wonder if the problem isn't coming from Qt itself. Anyway,
please find in attached the stacktrace I've recorded with libqt4*-dbg
packages installed (I can't find qtcreator-dbg in Debian
repositories).
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: ia64
Kernel: Linux 2.6.38-2-mckinley (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages qtcreator depends on:
ii libc6.12.13-18
ii libgcc11:4.6.1-4
ii libqt4-help4:4.7.3-5
ii libqt4-network 4:4.7.3-5
ii libqt4-sql-sqlite 4:4.7.3-5
ii libqtcore4 4:4.7.3-5
ii libqtgui4 4:4.7.3-5
ii libstdc++6 4.6.1-4
ii libunwind7 0.99-0.3
Versions of packages qtcreator recommends:
ii gdb 7.3-1
ii gnome-terminal [x-terminal-emulator] 3.0.1-1
ii make 3.81-8.1
ii qt4-demos 4:4.7.3-5
ii qt4-dev-tools 4:4.7.3-5
ii qt4-doc 4:4.7.3-5
ii qtcreator-doc 1.3.1-3
ii xterm [x-terminal-emulator] 271-1
Versions of packages qtcreator suggests:
ii cmake none
ii git [git-core] 1:1.7.5.4-1
ii subversion 1.6.17dfsg-1
-- no debconf information
Starting program: /usr/bin/qtcreator.bin
[Thread debugging using libthread_db enabled]
[New Thread 0x24b73190 (LWP 11059)]
[New Thread 0x2000113b7190 (LWP 11062)]
[New Thread 0x200012153190 (LWP 11063)]
[New Thread 0x200013037190 (LWP 11064)]
[New Thread 0x200013837190 (LWP 11065)]
[New Thread 0x2000187ff190 (LWP 11074)]
[New Thread 0x200018fff190 (LWP 11075)]
[New Thread 0x2000197ff190 (LWP 11076)]
[Thread 0x2000187ff190 (LWP 11074) exited]
[New Thread 0x2000187ff190 (LWP 11077)]
[Thread 0x200018fff190 (LWP 11075) exited]
[New Thread 0x200019fff190 (LWP 11078)]
[Thread 0x2000187ff190 (LWP 11077) exited]
[Thread 0x200019fff190 (LWP 11078) exited]
[New Thread 0x200019fff190 (LWP 11079)]
[Thread 0x2000197ff190 (LWP 11076) exited]
[New Thread 0x2000197ff190 (LWP 11080)]
Program received signal SIGBUS, Bus error.
0x223360b0 in __sigsetjmp () from /lib/ia64-linux-gnu/libc.so.6.1
#0 0x223360b0 in __sigsetjmp () from /lib/ia64-linux-gnu/libc.so.6.1
No symbol table info available.
#1 0x208bd410 in gray_convert_glyph_inner (worker=0x6fff5658)
at painting/qgrayraster.c:1590
error = 38177702
#2 0x208be780 in gray_convert_glyph (worker=0x6fff5658) at
painting/qgrayraster.c:1715
bottom = optimized out
top = optimized out
middle = optimized out
error = -40088
bands = {{min = 0, max = 42}, {min = -41088, max = 1610616831}, {min =
-41136, max = 1610616831}, {min = -41152, max = 1610616831}, {min = 1, max =
0}, {min = 0, max = 0}, {min = -43760, max = 1610616831}, {min = 0, max = 0},
{min = 0, max = 536870912}, {min = 786672, max = 1610612736}, {min = 87952648,
max = 536870912}, {min = 32960200, max = 536870912}, {min = 2883642, max = 0},
{min = 0, max = 1077411840}, {min = 0, max = 0}, {min = 128, max = 768}, {min =
1792, max = 0}, {min = 3296, max = 0}, {min = 0, max = 0}, {min = 2, max =
0}, {min = 3, max = 1610612736}, {min = 5257228, max = 1610612736}, {min =
-41152, max = 1610616831}, {min = -0, max = 1610616831}, {min = -41128, max
= 1610616831}, {min = -41100, max = 1610616831}, {min = -41084, max =
1610616831}, {min = -41068, max = 1610616831}, {min = -41052, max =
1610616831}, {min = -41038, max = 1610616831}, {min = 3, max = 536870912}, {min
= 2648160, max = 1610612736}, {min = -41400, max = 1610616831}, {min =
Bug#642153: Confirmed: Qt-related (4.7.2) issue
Thanks to snapshot.debian.org, I can confirm that qtcreator 1.3.1-3 currently in Debian Wheezy Testing can be run successfully with Qt packages up to 4.7.1-2. Starting with Qt packages 4.7.2-1, Qt Creator crashes with a bus error. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: Still the same with gnome-settings-daemon 2.30.2-4
Hi, FWIW amid the reports merged with this one, there is one person using i386 and another using mipsel. I don't know for i386 and mipsel, but here are my investigations for ia64. From the point of view of fixing this in binutils, it would be _very_ helpful to have a collection of object files and e.g. two linker command lines that should produce the same binary but do not. At the moment, a person investigating this has to get to know the gnome-settings-daemon build system and it is hard to debug or pass upstream. Alternatively, if this is a regression than a regression range would be helpful. gnome-settings-daemon first appears (at least on ia64) in Debian 5.0 Lenny. So I started with a fresh Lenny install on a spare HDD. From there, the older binutils package that I can install without breaking the whole system is binutils_2.17cvs20070426-1_ia64. Guess what? This old version already produces a broken gnome-settings-daemon with -z flag passed to the linker, and a working one without the flag :-( For further debugging, I can thus provide the locally rebuilt (with binutils_2.17cvs20070426-1_ia64) gnome-settings-daemon_2.22.2.1-2_ia64.deb binary packages with and without -z flag passed to linker. I've also kept the build directories of these two packages if preferred. As an alternative, I can also provide these packages but from a daily-updated Debian Testing Wheezy install, with up-to-date binutils and gnome-settings-daemon packages if preferred. About the gnome-settings-daemon build system, maybe Josselin can give us a clue? I have no idea how it works. Best regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: Still the same with gnome-settings-daemon 2.30.2-4
Hi, I've looked at the source package: the debian/build script still passes -z defs flags to ld, thus producing a broken binary, as expected :-( Regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638068: [bisected] initramfs-tools generates unbootable initrd.img on IA-64 platform (Itanium)
Hi, does initramfs-tools boot with BUSYBOX=no in initramfs.conf? Well, I don't know! Indeed, with BUSYBOX=no in initramfs.conf, initrd.img generation fails: root@longspeak:/# dpkg-reconfigure linux-image-3.0.0-1-mckinley Running depmod. Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.0.0-1-mckinley /bo ot/vmlinuz-3.0.0-1-mckinley update-initramfs: Generating /boot/initrd.img-3.0.0-1-mckinley mv: cannot stat `/tmp/mkinitramfs_Z30F2f/bin/sh.shared': No such file or directo ry E: /usr/share/initramfs-tools/hooks/klibc failed with return 1. update-initramfs: failed for /boot/initrd.img-3.0.0-1-mckinley with 1. run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.0.0 -1-mckinley.postinst line 774. This is with initramfs-tools 0.99, as currently shipped in Testing. The same error occurs with source code currently in git. according to your aboves statement it might not as the shared klibc dash and not the static dash might end up in the initramfs? see ls /usr/lib/klibc/bin OK, here's where the 199144 bytes bin/sh exec comes from (size matches /usr/lib/klibc/bin/sh exec). Thanks for pointing this out. More on this later... Applying patch proposed in bug #628374 (initramfs-tools: Recent changes to hooks break busybox in initrd) to revert changes on busybox hook doesn't help. Simply reverting commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 from initramfs-tools v0.99 source code doesn't help either as resulting initramfs-tools binaries generate initrd.img failing to boot system with kernel panic, probably because of post-8f8299d9ba017d2a5af853a52be37ee50c89fac2 commits. The problem is still present in current initramfs-tools git repository. are you sure? Well, yes, I'm sure that the generated initramfs is unbootable. That being said, I've bisected the first bad commit. It's also possible that following commits fixed this issue, but other ones make it appear again, maybe with a different root cause. relevant apt source line is: deb http://jenkins.grml.org/debian initramfs-tools main please test that one, thank you. Still unbootable initramfs with this one. And initrd.img creation fails with the same error than with 0.99 and git with BUSYBOX=no in initramfs.conf. However, with BUSYBOX=yes, initrd.img can be generated successfully. If I look at its content, ls -l bin/ gives: -rwxr-xr-x 1 root root 199144 Aug 17 22:05 busybox lrwxrwxrwx 1 root root 7 Aug 17 22:05 sh - busybox Is it expected that bin/busybox in initramfs is in fact a copy of /usr/lib/klibc/bin/sh and not /bin/busybox? Indeed, ls -l on my system gives: -rwxr-xr-x 1 root root 1320720 Jul 25 16:17 /bin/busybox -rwxr-xr-x 1 root root 199144 Jul 27 17:32 /usr/lib/klibc/bin/sh Hope this helps, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638068: [bisected] initramfs-tools generates unbootable initrd.img on IA-64 platform (Itanium)
Package: initramfs-tools Version: 0.99 Severity: grave As stated in this thread http://lists.debian.org/debian-ia64/2011/08/msg1.html, Debian Wheezy Testing cannot be booted at all on IA-64 (current linux-image-3.0.0-1-mckinley in Testing depends on initramfs-tools 0.99, so initramfs-tools cannot be downgraded to previously working 0.98.8). Hence severity set to grave. Last message displayed on console is: [ 17.146492] Freeing unused kernel memory: 1024kB freed Loading, please wait... And then, nothing. Regression has been bisected to commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 (mkinitramfs: copy over on build instead of using symlink tree) from maximilian attems, 2011-02-21 (initramfs-tools v0.99 development cycle). Comparison of last good and first bad generated initrd.img ramdisks show that: - good one has bin/busybox and bin/sh, bin/sh being a soft link on bin/busybox and size of bin/busybox matching size of system /bin/busybox (1320720 bytes) - bad one has no bin/busybox, only bin/sh (executable, not a link) but size (199144 bytes) doesn't match size of system /bin/busybox (1320720 bytes). Indeed, analyzing hook-functions and hooks/busybox source code, it's my understanding that bin/sh should be a copy of system /bin/busybox and thus should have the same size, right? I don't know where this 199144 bytes executable comes from. Applying patch proposed in bug #628374 (initramfs-tools: Recent changes to hooks break busybox in initrd) to revert changes on busybox hook doesn't help. Simply reverting commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 from initramfs-tools v0.99 source code doesn't help either as resulting initramfs-tools binaries generate initrd.img failing to boot system with kernel panic, probably because of post-8f8299d9ba017d2a5af853a52be37ee50c89fac2 commits. The problem is still present in current initramfs-tools git repository. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 18M Aug 16 21:45 /boot/initrd.img-2.6.39-2-mckinley -- /proc/cmdline BOOT_IMAGE=scsi1:/EFI/debian/vmlinuz.old root=UUID=59bf61ca-bdc4-4819-b6c7-5e6f8 057e8be ro -- resume RESUME=UUID=d550ead1-5755-40a6-af3a-07725fe4e688 -- /proc/filesystems ext4 fuseblk -- lsmod Module Size Used by fuse 148263 1 nfsd 580932 2 nfs 667482 0 lockd 148031 2 nfsd,nfs fscache78844 1 nfs auth_rpcgss80673 2 nfsd,nfs nfs_acl 5191 2 nfsd,nfs sunrpc401530 6 nfsd,nfs,lockd,auth_rpcgss,nfs_acl ipv6 667084 36 loop 30718 0 radeon 2088892 2 snd_fm801 35165 2 snd_ac97_codec184761 1 snd_fm801 ac97_bus1838 1 snd_ac97_codec ttm 117516 1 radeon drm_kms_helper 53852 1 radeon snd_pcm 147663 2 snd_fm801,snd_ac97_codec snd_page_alloc 11557 1 snd_pcm snd_tea575x_tuner 8774 1 snd_fm801 videodev 160214 1 snd_tea575x_tuner media 22901 1 videodev drm 318125 4 radeon,ttm,drm_kms_helper i2c_algo_bit 10968 1 radeon fm801_gp4776 0 gameport 15903 2 fm801_gp i2c_core 35751 5 radeon,drm_kms_helper,videodev,drm,i2c_algo_bit power_supply 16323 1 radeon evdev 20535 4 snd_opl3_lib 19238 1 snd_fm801 snd_timer 42224 2 snd_pcm,snd_opl3_lib snd_hwdep 13629 1 snd_opl3_lib snd_mpu401_uart13763 1 snd_fm801 snd_rawmidi40192 1 snd_mpu401_uart snd_seq_device 10749 2 snd_opl3_lib,snd_rawmidi snd 102026 13 snd_fm801,snd_ac97_codec,snd_pcm,snd_opl3_lib,s nd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device soundcore 10343 1 snd ext4 554604 1 mbcache12842 1 ext4 jbd2 118997 1 ext4 crc16 1479 1 ext4 sd_mod 75886 3 crc_t10dif 1420 1 sd_mod usbhid 61155 0 hid 134780 1 usbhid sg 47353 0 sr_mod 32745 0 cdrom 73444 1 sr_mod ata_generic 5671 0 ohci_hcd 53106 0 pata_cmd64x10096 0 libata349825 2 ata_generic,pata_cmd64x mptspi 27375 2 mptscsih 38872 1 mptspi ehci_hcd 91574 0 mptbase 116134 2 mptspi,mptscsih scsi_transport_spi 44772 1 mptspi usbcore 284414 4 usbhid,ohci_hcd,ehci_hcd scsi_mod 252243 7 sd_mod,sg,sr_mod,libata,mptspi,mptscsih,scsi_tra nsport_spi tg3 299933 0 e100 64313 0 mii 8419 1 e100 libphy 36137 1 tg3 -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf #
Bug#537572: Still the same with gnome-settings-daemon 2.30.2-3
Hi, I've looked at the source package: the debian/build script still passes -z defs flags to ld, thus producing a broken binary, as expected :-( Regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622299: Corrupt GL rendering with KMS (r300) enabled on IA-64 platform (Itanium)
Sorry for the delay, Anyway, it would be great if you could report this upstream at http://bugs.freedesktop.org/enter_bug.cgi?product=Mesa , component Drivers/Gallium/r300. The main upstream r300g developer (Marek Olšák) is usually quite responsive to bug reports. Done. See https://bugs.freedesktop.org/show_bug.cgi?id=36608. OK, will do. But... Are you talking about the unaligned accesses or the rendering issue? Well, given the unaligned accesses seem to be gone upstream... :) Sure, but are they gone because of a dedicated fix, os as a side-effect of an other fix in the graphics pipeline... Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622299: Corrupt GL rendering with KMS (r300) enabled on IA-64 platform (Itanium)
Hello Michel, If you pass --with-dri-drivers=r300 to configure, the classic driver Allright, this time it worked :-) I probably misunderstood that the How to build mesa page was only dealing with the Gallium driver. So, back to your initial question ;-) Does the classic driver still work? Kinda. glxgears rendering isn't corrupted as with the Gallium driver, but the system instantly locks up. This is a recurrent problem on IA-64, so the (unknown) root cause (http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg46848.html) is probably still the same. It's noteworthy however that, contrarily to the Gallium driver, both glxinfo and glxgears generate unaligned accesses (http://www.gelato.unsw.edu.au/IA64wiki/UnalignedAccesses) with the classic driver. Hope this helps, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622299: Corrupt GL rendering with KMS (r300) enabled on IA-64 platform (Itanium)
Hello Michel,
If you pass --with-dri-drivers=r300 to configure, the classic driver
should end up in lib/r300_dri.so, as opposed to r300g in
lib/gallium/r300_dri.so . You can override libGL's search path with the
LIBGL_DRIVERS_PATH environment variable, and if you also set
LIBGL_DEBUG=verbose, it prints on stderr where it loads the driver from.
So, something isn't working as expected. If I follow the How to build
mesa page (http://pkg-xorg.alioth.debian.org/howto/build-mesa.html),
there's no r300 classic driver, but classic radeon driver (as can be
read in the Preparing mesa sources section: For r300 (the options
are named radeon), you need:). So, with:
emeric@longspeak:~/mesa.git$ ./configure \
--enable-driglx-direct \
--enable-gallium \
--enable-gles-overlay \
--enable-gles1 \
--enable-gles2 \
--enable-glx-tls \
--with-driver=dri \
--with-dri-driverdir=/usr/lib/dri \
--with-egl-platforms='drm x11' \
--with-state-trackers=egl,glx,dri,vega \
--with-dri-drivers=radeon --enable-gallium-radeon
both the classic and Gallium drivers are built, as emphasized by the
configure output:
prefix: /usr/local
exec_prefix: ${prefix}
libdir: ${exec_prefix}/lib
includedir: ${prefix}/include
OpenGL: yes (ES1: yes ES2: yes)
OpenVG: yes
Driver: dri
OSMesa: no
DRI drivers: radeon
DRI driver dir: /usr/lib/dri
Use XCB: no
Shared dricore: no
GLU: yes
GLw: yes (Motif: no)
glut:yes
EGL: yes
EGL platforms: drm x11
EGL drivers: builtin:egl_glx builtin:egl_dri2 egl_gallium
EGL Gallium STs: $(GL_LIB) $(VG_LIB)
llvm:no
Gallium: yes
Gallium dirs:auxiliary drivers state_trackers
Target dirs: egl dri-r300 dri-swrast
Winsys dirs: sw sw/xlib sw/dri i915/sw radeon/drm
Driver dirs: softpipe failover galahad trace rbug noop
identity svga i915 i965 r300
Trackers dirs: egl glx dri vega
Shared libs: yes
Static libs: no
And indeed, I'm getting both the classic radeon_dri.so driver and
Gallium r300_dri.so driver, right?
emeric@longspeak:~/mesa.git$ ls lib/
egllibGLESv1_CM.so.1.1.0 libglut.so
galliumlibGLESv2.so libglut.so.3
libEGL.so libGLESv2.so.2 libglut.so.3.7.1
libEGL.so.1libGLESv2.so.2.0.0 libGLw.so
libEGL.so.1.0 libGL.so libGLw.so.1
libglapi.solibGL.so.1 libGLw.so.1.0.0
libglapi.so.0 libGL.so.1.2 libOpenVG.so
libglapi.so.0.0.0 libGLU.so libOpenVG.so.1
libGLESv1_CM.solibGLU.so.1libOpenVG.so.1.0.0
libGLESv1_CM.so.1 libGLU.so.1.3.071100 radeon_dri.so
emeric@longspeak:~/mesa.git$ ls lib/gallium/
r300_dri.so swrastg_dri.so
From what I understand, since I passed --enable-gallium-radeon, the
Gallium driver will be used by default.
So, still following the How to build mesa page:
emeric@longspeak:~/mesa.git$ mv lib/gallium/* lib/
emeric@longspeak:~/mesa.git$ export LIBGL_DRIVERS_PATH=lib
emeric@longspeak:~/mesa.git$ LIBGL_DEBUG=verbose glxinfo 21
/dev/null | grep so$
libGL: OpenDriver: trying lib/tls/r300_dri.so
libGL: OpenDriver: trying lib/r300_dri.so
libGL: OpenDriver: trying lib/tls/r300_dri.so
libGL: OpenDriver: trying lib/r300_dri.so
(don't know why I'm getting twice the output)
And glxinfo is rendering through the newly built Gallium driver:
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI R300
OpenGL version string: 2.1 Mesa 7.11-devel (git-6a35cbb)
Now, trying to swith back to the classic driver:
emeric@longspeak:~/mesa.git$ ./configure \
--enable-driglx-direct \
--enable-gallium \
--enable-gles-overlay \
--enable-gles1 \
--enable-gles2 \
--enable-glx-tls \
--with-driver=dri \
--with-dri-driverdir=/usr/lib/dri \
--with-egl-platforms='drm x11' \
--with-state-trackers=egl,glx,dri,vega \
--with-dri-drivers=radeon
(removed --enable-gallium-radeon from the passed options).
Gallium is nevertheless built as can be seen in the configure output:
prefix: /usr/local
exec_prefix: ${prefix}
libdir: ${exec_prefix}/lib
includedir: ${prefix}/include
OpenGL: yes (ES1: yes ES2: yes)
OpenVG: yes
Driver: dri
OSMesa: no
DRI drivers: radeon
DRI driver dir: /usr/lib/dri
Use XCB: no
Bug#622299: Corrupt GL rendering with KMS (r300) enabled on IA-64 platform (Itanium)
Hi, Just finished recompiling mesa git following this guide http://pkg-xorg.alioth.debian.org/howto/build-mesa.html. Everything ran as described, except for the last section (I'm getting no libEGL debug messages with glxgears). Still the same issue however :-( Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622299: Corrupt GL rendering with KMS (r300) enabled on IA-64 platform (Itanium)
Le 14 avril 2011 10:29, Michel Dänzer daen...@debian.org a écrit : Does the classic driver still work? Well, now that I've rebuilt Mesa Git with Gallium support, how do I switch GL rendering back to Mesa classic? I tried recompiling the whole thing, removing --enable-gallium-radeon from ./configure options before rebuilding Mesa Git, but it didn't help. Indeed, LIBGL_DEBUG=verbose glxinfo 21 /dev/null | grep so still complains about missing lib/swrast_dri.so, lib/r300_dri.so and lib/swrastg_dri.so (the last two being normally built when Gallium is enabled!). I even tried replacing --enable-gallium with --disable-gallium but configure thus fails with: error: cannot enable OpenVG without Gallium (although I didn't set --enable-openvg). Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622299: Corrupt GL rendering with KMS (r300) enabled on IA-64 platform (Itanium)
Hi Michel, The r300g driver shipped in current libgl1-mesa-dri only works with KMS, so with that disabled, you're probably getting software rendering. I should have noticed it earlier! You're right, GL rendering with libgl1-mesa-dri 7.7.1-4 is done through r300c driver, whereas it's done through r300g with libgl1-mesa-dri 7.10-4. Checked with glxinfo on my system. If you can build and test upstream Mesa Git, it would be great to know if the problem persists there with the r300g driver and still doesn't affect the classic r300 driver. OK, I'll try it. Is this howto (http://pkg-xorg.alioth.debian.org/howto/build-mesa.html) a good starting point? Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622299: Corrupt GL rendering with KMS (r300) enabled on IA-64 platform (Itanium)
Hi, Version 7.10.2-1 is currently not available for IA-64. However version 7.10.1-1 is, so tested with it (also upgrading related packages). Same issue unfortunately :-( Émeric 2011/4/12 Cyril Brulebois k...@debian.org: severity 622299 important thanks Hi, Émeric Maschino emeric.masch...@gmail.com (11/04/2011): GL rendering is completely garbaged (see attached screenshot of glxgears) and thus unusable when KMS is enabled with libgl1-mesa-dri 7.10-4 in today's Debian Wheezy Testing updates. Disabling KMS fixes the problem. Previous libgl1-mesa-dri 7.7.1-4 doesn't have this issue. Simply reverting libgl1-mesa-dri to 7.7.1-4 (while keeping every other packages up-to-date) by invoking dpkg -i --force-downgrade libgl1-mesa-dri_7.7.1-4_ia64.deb fixes this issue. So, this definitely sounds like a regression introduced with current libgl1-mesa-dri 7.10-4. please check what happens with the version available in sid (7.10.2-1). KiBi. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk2jh7QACgkQeGfVPHR5Nd1CqgCgk4RZKv42zop+CgV4edW/Q80F Iq0AniH66A37tzMpq+ds7F6q7iqiZOgP =Q24H -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620546: apt 0.8.13.1 fixed the problem
Hi, FYI, manually installing apt 0.8.13.1 (dated 2011-04-03) using dpkg -i made apt happy again. Regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620874: binutils: -z defs ld flag breaks gnome-settings-daemon on IA-64
Package: binutils Version: 2.20.1-16 Severity: critical As explained in this post (http://lists.debian.org/debian-ia64/2011/03/msg00017.html), gnome-settings-daemon is broken on IA-64 (Itanium) since release 2.24.1-1 dated 2008-12-30, not because of a source code change, but because of a change in the flags passed to ld by the debian/rules build script of the gnome-settings-daemon source package. Simply removing -Wl,-z,defs from the LDFLAGS of the debian/rules script produces a working gnome-settings-daemon binary. This has been checked with current gnome-settings-daemon-2.30.2-2 and gnome-settings-daemon-2.24.1-1 (first broken release). Cross-testing by adding this flag to gnome-settings-daemon-2.22.2.1-2 (last working release) produces a broken binary, proving that -z defs flag is the culprit. What's unclear to me: - is this issue limited to gnome-settings-daemon or does it reveal something more serious and other packages built with -z defs flag are affected too (hence this bug report)? - if other packages are affected too, is this issue specific to IA-64 or not? From http://www.debian.org/Bugs/Developer#severities, I've set bug severity to critical, as ld breaks an unrelated software (gnome-settings-daemon in the present case). By the way, with currently broken gnome-settings-daemon-2.30.2-2 and gdm3 window manager, CPU power is completely eaten by running instances of gnome-settings-daemon. Even worse, each time a user logs in/off, additional gnome-settings-daemon processes are forked, leading to a completely unusable system. And unfortunately, a standard user doesn't have sufficient permissions to kill the CPU-eating gnome-settings-daemon processes (although this was possible with gdm; but gdm will be dropped in next Debian Wheezy). -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: ia64 Kernel: Linux 2.6.32-5-mckinley (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages binutils depends on: ii libc6.1 2.11.2-11Embedded GNU C Library: Shared lib ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime binutils recommends no packages. Versions of packages binutils suggests: pn binutils-doc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: Problem found; ld issue?
Hi, As explained here (http://lists.debian.org/debian-ia64/2011/03/msg00017.html), this issue isn't due to a code change in gnome-settings-daemon, but to a change in the flags passed to ld by the debian/rules build script of the gnome-settings-daemon source package. Simply removing -Wl,-z,defs from the LDFLAGS of the debian/rules script produces a working gnome-settings-daemon binary. This has been checked with current gnome-settings-daemon-2.30.2-2 and gnome-settings-daemon-2.24.1-1 (first broken release). Cross-testing by adding this flag to gnome-settings-daemon-2.22.2.1-2 (last working release) produces a broken binary, proving that -z defs flag is the culprit. What's unclear to me: - is this ld issue specific to gnome-settings-daemon? In this case, please keep this bug report open as current gnome-settings-daemon 2.30.2-2 is still broken (and I bet that simply removing -Wl,-z,defs from the LDFLAGS of the debian/rules script is not the right way to fix it as all architectures will be affected by this change) - does this ld issue also affect other packages? I've open bug report #620874 to track it in this case (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620874). Regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620874: binutils: -z defs ld flag breaks gnome-settings-daemon on IA-64
Hi, -z defs means to disallow undefined symbols in object files. Are you sure that there is not some undefined symbol in an object file and this is not build system/runtime behavior fallout from that? I know nothing about gnome-settings-daemon code and related software, so can't make any assumption on potential undefined symbol. By the way, with currently broken gnome-settings-daemon-2.30.2-2 and gdm3 window manager, CPU power is completely eaten by running instances of gnome-settings-daemon. Even worse, each time a user logs in/off, additional gnome-settings-daemon processes are forked, leading to a completely unusable system. These are symptoms and do not in themselves sound like something a linker would do. It would be very nice if someone could track down the underlying problem. Sorry if I was unclear. These symptoms only surface with broken gnome-settings-daemon binary. Simply removing the offending -z defs flag from LDFLAGS of the debian/rules build script of the gnome-settings-daemon source package produces a working binary, making these symptoms disappear. Thanks for writing, Thanks for answering :-) Jonathan Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620874: binutils: -z defs ld flag breaks gnome-settings-daemon on IA-64
Hello again, Thanks for your hard work tracking this down, and thanks for bringing it to our attention. I'm going to merge this with the existing gnome-settings-daemon bug, so the problem is tracked in one place. Of course it is possible there is a binutils involved here somewhere. If that turns out to be the case, please feel free to unmerge the bug again and reassign. OK. For completeness about potential unresolved symbols, here's a partial output of fakeroot debian/rules binary of current gnome-settings-daemon 2.30.2-2 source package on my system showing some unresolvable reference to symbols: dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libtyping-break.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libxrandr.so contains an unresolvable reference to symbol XGrabKey: it's probably a plugin. dpkg-shlibdeps: warning: 3 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libkeybindings.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libhousekeeping.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libxrdb.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libclipboard.so contains an unresolvable reference to symbol XGetSelectionOwner: it's probably a plugin. dpkg-shlibdeps: warning: 16 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libmouse.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libbackground.so contains an unresolvable reference to symbol XInternAtom: it's probably a plugin. dpkg-shlibdeps: warning: 3 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libfont.so contains an unresolvable reference to symbol XGetSelectionOwner: it's probably a plugin. dpkg-shlibdeps: warning: 11 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/liba11y-keyboard.so contains an unresolvable reference to symbol XkbUseExtension: it's probably a plugin. dpkg-shlibdeps: warning: 8 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libxsettings.so contains an unresolvable reference to symbol XInternAtom: it's probably a plugin. dpkg-shlibdeps: warning: 12 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libsound.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libkeyboard.so contains an unresolvable reference to symbol XInternAtom: it's probably a plugin. dpkg-shlibdeps: warning: 14 other similar warnings have been skipped (use -v to see them all). Will this help? Cheers, Jonathan Regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608893: Same problem with epiphany-browser 2.30.6-1
Hi,
I don't know if the root cause is the same, but here's the stack trace
I'm recording with current epiphany-browser in Debian Squeeze on an
Itanium workstation.
emeric@longspeak:~$ gdb epiphany-browser
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as ia64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/epiphany-browser...Reading symbols from
/usr/lib/debug/usr/bin/epiphany-browser...done.
(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/epiphany-browser
[Thread debugging using libthread_db enabled]
[New Thread 0x2bf430f0 (LWP 7473)]
[New Thread 0x2cacb0f0 (LWP 7474)]
epiphany-browse(7470): unaligned access to 0x2bf7ac4e,
ip=0x2196eeb0
epiphany-browse(7470): unaligned access to 0x2bf7acb6,
ip=0x2196edb0
epiphany-browse(7470): unaligned access to 0x2bf7ad1e,
ip=0x2196eeb0
epiphany-browse(7470): unaligned access to 0x2bf7ad26,
ip=0x2196eeb0
epiphany-browse(7470): unaligned access to 0x2bf7ad2e,
ip=0x2196eeb0
[New Thread 0x2d85f0f0 (LWP 7475)]
** Message: console message: undefined @0: 1.4450535554832405e-154
[New Thread 0x2e7bf0f0 (LWP 7476)]
[New Thread 0x2efbf0f0 (LWP 7477)]
[New Thread 0x2f8bf0f0 (LWP 7478)]
[New Thread 0x2000147ff0f0 (LWP 7479)]
[New Thread 0x200014fff0f0 (LWP 7480)]
Program received signal SIGSEGV, Segmentation fault.
JSObjectCallAsFunction (ctx=0x2bf79748, object=0x0,
thisObject=value optimized out, argumentCount=1,
arguments=0x6f80d980, exception=0x0)
at ../JavaScriptCore/API/JSObjectRef.cpp:388
388 ../JavaScriptCore/API/JSObjectRef.cpp: No such file or directory.
in ../JavaScriptCore/API/JSObjectRef.cpp
Current language: auto
The current source language is auto; currently c++.
(gdb) thread apply all bt full
Thread 9 (Thread 0x200014fff0f0 (LWP 7480)):
#0 0xa0010721 in __kernel_syscall_via_break ()
No symbol table info available.
#1 0x24677660 in __pthread_cond_timedwait (cond=0x60309ca0,
mutex=0x60110a60, abstime=0x200014ffe6e0)
at pthread_cond_timedwait.c:160
_b7 = 0xa0010a00
_out2 = 11
_r15 = 1246
_retval = value optimized out
_out3 = 2305843009566008976
_out0 = 6917529027644267684
_r8 = value optimized out
_r10 = value optimized out
_out1 = 128
rt = {tv_sec = 0, tv_nsec = 218601523}
futex_val = 11
buffer = {__routine = 0x272166a0, __arg = 0x200014ffe6c0,
__canceltype = -2147352576, __prev = 0x0}
cbuffer = {oldtype = 0, cond = 0x60309ca0,
mutex = 0x60110a60, bc_seq = 0}
result = value optimized out
pshared = 0
err = value optimized out
val = value optimized out
seq = 3
#2 0x242886d0 in g_cond_timed_wait_posix_impl (
cond=0x60309ca0, entered_mutex=0x60110a60,
abs_time=0x200014ffe6f0)
at
/build/buildd-glib2.0_2.24.2-1-ia64-HJZXOu/glib2.0-2.24.2/gthread/gthread-posix.c:242
result = value optimized out
end_time = {tv_sec = 1296086837, tv_nsec = 449181000}
timed_out = value optimized out
__PRETTY_FUNCTION__ = g_cond_timed_wait_posix_impl
#3 0x242bc400 in g_async_queue_pop_intern_unlocked (
queue=0x60110a30, try=0, end_time=0x200014ffe6f0)
at
/build/buildd-glib2.0_2.24.2-1-ia64-HJZXOu/glib2.0-2.24.2/glib/gasyncqueue.c:365
retval = value optimized out
__PRETTY_FUNCTION__ = g_async_queue_pop_intern_unlocked
#4 0x24386130 in g_thread_pool_wait_for_new_task (
data=0x60114f80)
at
/build/buildd-glib2.0_2.24.2-1-ia64-HJZXOu/glib2.0-2.24.2/glib/gthreadpool.c:270
end_time = {tv_sec = 1296086837, tv_usec = 449181}
#5 g_thread_pool_thread_proxy (data=0x60114f80)
at
/build/buildd-glib2.0_2.24.2-1-ia64-HJZXOu/glib2.0-2.24.2/glib/gthreadpool.c:304
task = 0x602ab6a0
pool = 0x60114f80
#6 0x24380d30 in g_thread_create_proxy (data=value optimized out)
at
/build/buildd-glib2.0_2.24.2-1-ia64-HJZXOu/glib2.0-2.24.2/glib/gthread.c:1893
__PRETTY_FUNCTION__ = g_thread_create_proxy
#7 0x2466abc0 in start_thread (arg=0x200014fff0f0)
at pthread_create.c:302
pd = 0x200014fff0f0
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {2305843009566009072,
2305843009290158648, 0, 2674341354693439, 0, 0, 0, 0,
Bug#537572: Still the same with GNOME settings daemon 2.30.2-2
FYI, gnome-settings-daemon 2.30.2-2 available in yesterday's Debian Squeeze updates didn't solve the problem. Cheers, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: Still the same with GNOME settings daemon 2.30.2-1
FYI, gnome-settings-daemon 2.30.2-1 available in Debian Squeeze updates didn't solve the problem. Cheers, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: Still the same with GNOME settings daemon 2.30.1-1
FYI, gnome-settings-daemon 2.30.1-1 available in yesterday's Debian Squeeze updates didn't solve the problem. Cheers, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: Definitely a gnome-settings-daemon issue
Hi, Thanks to the new snapshot.debian.org service (great feature!), I've performed regression testing and have the strong impression that this issue isn't due to D-BUS or GLib at all, but to gnome-settings-daemon. Indeed, starting from my current Squeeze installation and downgrading gnome-settings-daemon to 2.22.2.1-2 (and few mandatory packages too) while keeping current Squeeze dbus, dbus-x11 and libdbus-1-3 1.2.24-1 and dbus-glib 0.86-1 fixed the problem. From this point, simply upgrading gnome-settings-daemon to 2.24.1-1 makes the problem appear again. Downgrading to older D-BUS and/or GLib components (as suggested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537572#10) didn't help either. To summarize, this regression was introduced with gnome-settings-daemon 2.24.1-1 and is still present with current Squeeze gnome-settings-daemon 2.28.1-3. How can I help further? It would be nice if this issue could be fixed in forthcoming GNOME settings daemon 2.30/3.0. Cheers, Emeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: Still the same with GNOME settings daemon 2.28.1-3
FYI, gnome-settings-daemon 2.28.1-3 available in today's Debian Squeeze updates didn't solve the problem. Cheers, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: Still the same problem with D-BUS 1.2.24-1
FYI, D-BUS 1.2.24-1 available in today's Debian Squeeze updates didn't solve the problem. Cheers, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546655: Same problem with libdrm2 2.4.13-1 update
2010/2/2 maximilian attems m...@stro.at: I've bisected this problem to commit f1a2a9b6189f9f5c27672d4d32fec9492c6486b2 (drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings), during kernel 2.6.30 development cycle. please report upstream on bugzilla.kernel.org and let us know the bug nr so that it can be tracked? Done: http://bugzilla.kernel.org/show_bug.cgi?id=15212 checked the latest stable 2.6.32 patches and didn't see a patch, but maybe I overlooked.. You're right, there's no fix at this time. This issue is thus still present in current stable kernel 2.6.32 and development kernel 2.6.33-rc6 (as time of writing). FYI, simply reverting patch drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings enables back DRI on ia64 systems, but I don't think this is the right way to fix this issue ;-) Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546655: Same problem with libdrm2 2.4.13-1 update
2009/11/6 Julien Cristau jcris...@debian.org: My guess would be the kernel, but the best place to find developers who might be able to help you is likely to be the dri-de...@lists.sf.net mailing list (you're probably one of the only people to use graphics on ia64 though). (I asked Dave Airlie on irc when you reported this, he didn't have an idea why the sarea map would be busted) Cheers, Julien This definitely is an issue with the kernel. I've bisected this problem to commit f1a2a9b6189f9f5c27672d4d32fec9492c6486b2 (drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings), during kernel 2.6.30 development cycle. Today's linux-image-2.6.32-trunk-mckinley delivered with Debian Squeeze Testing updates still has this problem, and even yet an other more severe one preventing DRI from working. This last issue has been fixed by Bjorn Helgaas in kernel 2.6.33-rc4 (see http://marc.info/?l=linux-ia64m=126419878611433w=2 for details). At this time, I still don't have an answer about what to do now with commit f1a2a9b6189f9f5c27672d4d32fec9492c6486b2. Simply reverting it? Adding compiler directives to skip it on ia64? Cheers, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: GNOME settings daemon 2.28 didn't solve this issue
FYI, Today's Debian Squeeze gnome-settings-daemon 2.28.1-1+b1 update didn't solve the problem. Regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546655: Same problem with libdrm2 2.4.13-1 update
Hello, OK, I'll try the dri-devel list. Thank you for your time anyway. Émeric My guess would be the kernel, but the best place to find developers who might be able to help you is likely to be the dri-de...@lists.sf.net mailing list (you're probably one of the only people to use graphics on ia64 though). (I asked Dave Airlie on irc when you reported this, he didn't have an idea why the sarea map would be busted) Cheers, Julien
Bug#546655: Same problem with libdrm2 2.4.13-1 update
Hello, I don't know where exactly this problem resides, but just to let you know that Debian Squeeze libdrm2 2.4.13-1 update didn't help. Regards, Émeric
