Re: Grub2 with sparc64 patches
On 2017-01-24 05:37 PM, Eric Snowberg wrote: > That might be best. Before you do that though, could you turn on the > following debug flag and send me the results: > > grub> set debug=loader > grub> linux /vmlinuz-4.9.0-1-sparc64-smp > > do you get the same error with your smaller kernel? > grub> set debug=loader grub> linux /vmlinuz-4.9.0-1-sparc64-smp loader/sparc64/ieee1275/linux.c:495: Grub lives at phys_start[e402000] phys_end[ee0] error: /memory response buffer exceeded. grub> linux /vmlinuz-4.5.0-2-sparc64-smp loader/sparc64/ieee1275/linux.c:270: Attempting to claim at 0x40004000, size 0x8d0591. error: couldn't allocate physical memory. reboot grub> set debug=loader grub> linux /vmlinuz-4.5.0-2-sparc64-smp loader/sparc64/ieee1275/linux.c:495: Grub lives at phys_start[e402000] phys_end[ee0] error: /memory response buffer exceeded.
Re: Grub2 with sparc64 patches
> On Jan 24, 2017, at 2:06 PM, louis ayotte wrote: > > On 2017-01-24 01:01 PM, Eric Snowberg wrote: > >> How big is your kernel? Will silo boot it? Can you start over and do the >> following: >> >> grub> reboot >> >> You should be back at OBP. Now boot from the disk again and issue: >> >> grub> ls -l / >> >> and send the response? Can you also send a list of all the loaded modules? >> >> grub> lsmod >> >> If you have a rescue iso, it may be easier to boot from it, mount your disk, >> chroot to it, and then generate your missing grub.cfg file with >> grub-mkconfig and then reboot. >> > Before i installed grub it was booting fine with both kernels from SILO > > grub> ls -l / > DIR 20170116171825 lost+found/ > 5143720160122105340 silotftp.b > 6752 20160122105340 isofs.b > 512 20160122105340 first.b > 1024 20160122105340 generic.b > 1024 20160122105340 fd.b > 5376020170116173035 second.b > 800 20160122105340 ieee32.b > 3715429 20160430170110 vmlinuz-4.5.0-2-sparc64-smp > 2314500 20160430170315 System.map-4.5.0-2-sparc64-smp > 3850232 20170116192407 vmlinuz > 512 20160122105340 ultra.b > 17281088 20170116192407 initrd.img > 196 20170116173227 silo.conf > 127403 20160430170315 config-4.5.0-2-sparc64-smp > 7680 20170116173035 old.b > 16280175 20170116191428 initrd.img-4.5.0-2-sparc64-smp > 132748 20170112155237 config-4.9.0-1-sparc64-smp > 3850232 20170112155237 vmlinuz-4.9.0-1-sparc64-smp > 16280175 20170116192407 initrd.img.old > 3715429 20170116192407 vmlinuz.old > DIR 20170123170539 grub/ > 2416201 20170112155237 System.map-4.9.0-1-sparc64-smp > 17281088 20170123004007 initrd.img-4.9.0-1-sparc64-smp > > grub> lsmod > NameRef Count Dependencies > minicmd 1 > ls 1 normal > normal 3 gettext,boot,bufio,crypto,terminal > gzio0 > gettext 4 > boot4 > bufio 4 > crypto 4 > terminal4 > search_fs_uuid 1 > part_sun1 > ext21 fshelp > fshelp 2 > > I might look into the rescue iso later on today That might be best. Before you do that though, could you turn on the following debug flag and send me the results: grub> set debug=loader grub> linux /vmlinuz-4.9.0-1-sparc64-smp do you get the same error with your smaller kernel? > > Thanks
Re: report on debian-9.0-sparc64-NETINST-1.iso with qemu
Hi Adrian,
Thank you for the rapid answer.
> Yes, the latest image is known to have a broken version of debootstrap. I
> should probably remove these images to keep others from using them.
Thanks. I tried again with the older image
https://people.debian.org/~glaubitz/debian-cd/2016-05-04/
1) At the first attempt, with a default partitioning ('/' partition and swap
partition), the installation completed but the installed system could not
boot: "Cannot find /etc/silo.conf".
The reason appears to be that my hard disk is > 1 GB, and the advice from [1]
helped: I could overcome this problem by creating a boot partition at the
beginning of the disk (250 MB in my case, and in ext2, to avoid the warning).
May I suggest that the Debian installer uses such a partitioning scheme by
default? I've seen the Debian 8.6 installer use a separate /boot partition
by default on armhf and s390x. So, it shouldn't be easy to do the same thing
for sparc...?
2) The installed system now boots, either by entering
1/vmlinuz initrd=/initrd.img root=/dev/sda2
at the SILO prompt, or by letting this prompt timeout. However, the boot process
hangs after one minute, after this output:
Starting udev Kernel Device Manager...
[ OK ] Started udev Kernel Device Manager.
[ OK ] Found device /dev/ttyS0.
[ 66.121368] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 66.137222] sr 1:0:0:0: Attached scsi generic sg1 type 5
[ 66.384970] [drm] Initialized drm 1.1.0 20060810
[ 66.726958] [drm] Found bochs VGA, ID 0xb0c5.
[ 66.727424] [drm] Framebuffer size 16384 kB @ 0x1ff0100, mmio @
0x1ff0200.
[ 66.773438] [TTM] Zone kernel: Available graphics memory: 248620 kiB
[ 66.774061] [TTM] Initializing pool allocator
Any idea? Is there a combination of a '-vga' parameter to qemu [2] and some
kernel
parameters [3] (I tried 'console=ttyS0', 'console=/dev/null', 'nofb',
'nomodeset',
'vga=normal') that would make this work?
3) There's a problem with the network interface: It accepts a configuration
through the built-in DHCP server of QEMU, but - as I could see by putting myself
in a chroot environment at the end of the installation - an 'ssh me@10.0.2.2'
cannot connect to the host machine at 10.0.2.2. DNS lookup doesn't work either,
although /etc/resolv.conf contains the correct value 10.0.2.3.
On other platforms this works.
The hardware emulated by QEMU on this platform is
hub 0
\ hub0port1: user.0: index=0,type=user,net=10.0.2.0,restrict=off
\ hub0port0: ne2k_pci.0:
index=0,type=nic,model=ne2k_pci,macaddr=52:54:00:12:34:56
Does anyone happen to know?
Bruno
[1] http://www.justskins.com/forums/fun-installing-debian-in-219272.html
[2] http://wiki.qemu.org/download/qemu-doc.html
[3] http://lxr.free-electrons.com/source/Documentation/kernel-parameters.txt
Re: Grub2 with sparc64 patches
> On Jan 24, 2017, at 1:44 PM, Frans van Berckel wrote: > > Hi Eric, > > On Tue, 2017-01-24 at 09:29 -0700, Eric Snowberg wrote: > >> With a sun/vtoc partition table like you have on a Sun Blade >> 1000. You will need to give it the boot partition (/dev/sda1 in your >> case) along with the —force option. For your system I’d recommend >> doing: >> >> # grub-install --force --skip-fs-probe /dev/sda1 > > Year that does the job. If the workstation starts it takes some extra > time to load Grub. First i see two error's, but they are quick away. > Next the menu is loaded. I can't use the arrow keys for selecting a I > want kernel. But just pressing enter does work. And being able edit a > kernel line does it as well. But again no arrow keys to walk through > the text. Exit with F10 also not functioned but ctrl+x does it well. > > Next the kernel boots well. What's would be the best way to debug and > save the error messages? I think the Sun Blade has a frame buffer. Could you see what is in /etc/default/grub. If it doesn’t contain the following lines, then I would recommend adding them: GRUB_TERMINAL_OUTPUT="console" GRUB_DISABLE_RECOVERY="true" GRUB_PRELOAD_MODULES="iso9660" This will prevent the frame buffer from being used and forces it to use the console. It will also preload the iso9660 module, which helps cover up some known bugs that need to be fixed. Afterwards you will need to regenerate your grub.cfg, with the grub-mkconfig command. See if this helps with the arrow keys. I’m not used to being on this older hardware. > > Thanks, > > Frans van Berckel
Re: Grub2 with sparc64 patches
On 2017-01-24 01:01 PM, Eric Snowberg wrote: > How big is your kernel? Will silo boot it? Can you start over and do the > following: > > grub> reboot > > You should be back at OBP. Now boot from the disk again and issue: > > grub> ls -l / > > and send the response? Can you also send a list of all the loaded modules? > > grub> lsmod > > If you have a rescue iso, it may be easier to boot from it, mount your disk, > chroot to it, and then generate your missing grub.cfg file with grub-mkconfig > and then reboot. > Before i installed grub it was booting fine with both kernels from SILO grub> ls -l / DIR 20170116171825 lost+found/ 5143720160122105340 silotftp.b 6752 20160122105340 isofs.b 512 20160122105340 first.b 1024 20160122105340 generic.b 1024 20160122105340 fd.b 5376020170116173035 second.b 800 20160122105340 ieee32.b 3715429 20160430170110 vmlinuz-4.5.0-2-sparc64-smp 2314500 20160430170315 System.map-4.5.0-2-sparc64-smp 3850232 20170116192407 vmlinuz 512 20160122105340 ultra.b 17281088 20170116192407 initrd.img 196 20170116173227 silo.conf 127403 20160430170315 config-4.5.0-2-sparc64-smp 7680 20170116173035 old.b 16280175 20170116191428 initrd.img-4.5.0-2-sparc64-smp 132748 20170112155237 config-4.9.0-1-sparc64-smp 3850232 20170112155237 vmlinuz-4.9.0-1-sparc64-smp 16280175 20170116192407 initrd.img.old 3715429 20170116192407 vmlinuz.old DIR 20170123170539 grub/ 2416201 20170112155237 System.map-4.9.0-1-sparc64-smp 17281088 20170123004007 initrd.img-4.9.0-1-sparc64-smp grub> lsmod NameRef Count Dependencies minicmd 1 ls 1 normal normal 3 gettext,boot,bufio,crypto,terminal gzio0 gettext 4 boot4 bufio 4 crypto 4 terminal4 search_fs_uuid 1 part_sun1 ext21 fshelp fshelp 2 I might look into the rescue iso later on today Thanks
Re: Grub2 with sparc64 patches
Hi Eric, On Tue, 2017-01-24 at 09:29 -0700, Eric Snowberg wrote: > With a sun/vtoc partition table like you have on a Sun Blade > 1000. You will need to give it the boot partition (/dev/sda1 in your > case) along with the —force option. For your system I’d recommend > doing: > > # grub-install --force --skip-fs-probe /dev/sda1 Year that does the job. If the workstation starts it takes some extra time to load Grub. First i see two error's, but they are quick away. Next the menu is loaded. I can't use the arrow keys for selecting a I want kernel. But just pressing enter does work. And being able edit a kernel line does it as well. But again no arrow keys to walk through the text. Exit with F10 also not functioned but ctrl+x does it well. Next the kernel boots well. What's would be the best way to debug and save the error messages? Thanks, Frans van Berckel
Re: Grub2 with sparc64 patches
> On Jan 24, 2017, at 9:49 AM, louis ayotte wrote: > > On 2017-01-24 10:56 AM, Eric Snowberg wrote: > >> “ls" is one area that has not been completed for SPARC and has many problems. >> >> Try this instead: >> >> grub> ls / >> >> If you see your kernel and initrd, then do something like the following: >> >> grub> linux /vmlinuz-4.8.0-rc8-ATU_final_upstream_v4+ >> root=/dev/mapper/VolGroup-lv_root ro >> grub> initrd /initramfs-4.8.0-rc8-ATU_final_upstream_v4+.img >> grub> boot >> >> > This is what i have done, > > GNU GRUB version 2.02~beta3-3+sparc64 > > Minimal BASH-like line editing is supported. For the first word, TAB > lists possible command completions. Anywhere else TAB lists possible > device or file completions. > > > grub> ls / > lost+found/ silotftp.b isofs.b first.b generic.b fd.b second.b ieee32.b > vmlinuz > -4.5.0-2-sparc64-smp System.map-4.5.0-2-sparc64-smp vmlinuz ultra.b > initrd.img > silo.conf config-4.5.0-2-sparc64-smp boot etc old.b > initrd.img-4.5.0-2-sparc64- > smp config-4.9.0-1-sparc64-smp vmlinuz-4.9.0-1-sparc64-smp > initrd.img.old vmlin > uz.old grub/ System.map-4.9.0-1-sparc64-smp initrd.img-4.9.0-1-sparc64-smp > grub> linux /vmlinuz-4.9.0-1-sparc64-smp > error: /memory response buffer exceeded. How big is your kernel? Will silo boot it? Can you start over and do the following: grub> reboot You should be back at OBP. Now boot from the disk again and issue: grub> ls -l / and send the response? Can you also send a list of all the loaded modules? grub> lsmod If you have a rescue iso, it may be easier to boot from it, mount your disk, chroot to it, and then generate your missing grub.cfg file with grub-mkconfig and then reboot. > grub> initrd /in > Possible files are: > > initrd.img initrd.img-4.5.0-2-sparc64-smp initrd.img.old > initrd.img-4.9.0-1-sparc64-smp > grub> initrd /initrd.img-4.9.0-1-sparc64-smp > error: you need to load the kernel first. > grub> linux /vmlinuz-4.9.0-1-sparc64-smp > error: couldn't allocate physical memory. > grub> linux /vmlinuz-4.9.0-1-sparc64-smp root=/dev/sdb > error: couldn't allocate physical memory. > grub> linux /vmlinuz-4.9.0-1-sparc64-smp root=/dev/sdb ro > error: couldn't allocate physical memory. > grub> linux /vmlinuz-4.9.0-1-sparc64-smp > root=/dev/mapper/Volgroup_lv_root ro > error: couldn't allocate physical memory. > grub> boot > error: you need to load the kernel first. >
Re: Grub2 with sparc64 patches
> On Jan 23, 2017, at 2:38 PM, louis ayotte wrote:
>
>
>
> On 2017-01-23 04:27 PM, John Paul Adrian Glaubitz wrote:
>> I think there is enough documentation for this on the web:
>>
>>> https://www.linux.com/learn/how-rescue-non-booting-grub-2-linux
>>> https://wiki.archlinux.org/index.php/GRUB#Using_the_command_shell
>> Adrian
>>
> T5240, No Keyboard
> Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved.
> OpenBoot 4.33.6, 98080 MB memory available, Serial #83048406.
> Ethernet address 0:14:4f:f3:37:d6, Host ID: 84f337d6.
>
> Boot device: /pci@400/pci@0/pci@8/scsi@0/disk@0,0:a File and args:
> GRUB Loading kernel..
>
> GNU GRUB version 2.02~beta3-3+sparc64
>
> Minimal BASH-like line editing is supported. For the first word, TAB
> lists possible command completions. Anywhere else TAB lists possible
> device or file completions.
>
> grub> set pager=1
> grub> ls
> (ieee1275//iscsi-hba/disk) ERROR: /iscsi-hba: No iscsi-network-bootpath
> property
> (ieee1275/disk6)
> ERROR: /pci@400: Last Trap: Fast Data Access MMU Miss
> {0} ok
>
> Everytime i write "ls" it crashes grub
“ls" is one area that has not been completed for SPARC and has many problems.
Try this instead:
grub> ls /
If you see your kernel and initrd, then do something like the following:
grub> linux /vmlinuz-4.8.0-rc8-ATU_final_upstream_v4+
root=/dev/mapper/VolGroup-lv_root ro
grub> initrd /initramfs-4.8.0-rc8-ATU_final_upstream_v4+.img
grub> boot
Re: Grub2 with sparc64 patches
On 2017-01-24 10:56 AM, Eric Snowberg wrote: > “ls" is one area that has not been completed for SPARC and has many problems. > > Try this instead: > > grub> ls / > > If you see your kernel and initrd, then do something like the following: > > grub> linux /vmlinuz-4.8.0-rc8-ATU_final_upstream_v4+ > root=/dev/mapper/VolGroup-lv_root ro > grub> initrd /initramfs-4.8.0-rc8-ATU_final_upstream_v4+.img > grub> boot > > This is what i have done, GNU GRUB version 2.02~beta3-3+sparc64 Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions. grub> ls / lost+found/ silotftp.b isofs.b first.b generic.b fd.b second.b ieee32.b vmlinuz -4.5.0-2-sparc64-smp System.map-4.5.0-2-sparc64-smp vmlinuz ultra.b initrd.img silo.conf config-4.5.0-2-sparc64-smp boot etc old.b initrd.img-4.5.0-2-sparc64- smp config-4.9.0-1-sparc64-smp vmlinuz-4.9.0-1-sparc64-smp initrd.img.old vmlin uz.old grub/ System.map-4.9.0-1-sparc64-smp initrd.img-4.9.0-1-sparc64-smp grub> linux /vmlinuz-4.9.0-1-sparc64-smp error: /memory response buffer exceeded. grub> initrd /in Possible files are: initrd.img initrd.img-4.5.0-2-sparc64-smp initrd.img.old initrd.img-4.9.0-1-sparc64-smp grub> initrd /initrd.img-4.9.0-1-sparc64-smp error: you need to load the kernel first. grub> linux /vmlinuz-4.9.0-1-sparc64-smp error: couldn't allocate physical memory. grub> linux /vmlinuz-4.9.0-1-sparc64-smp root=/dev/sdb error: couldn't allocate physical memory. grub> linux /vmlinuz-4.9.0-1-sparc64-smp root=/dev/sdb ro error: couldn't allocate physical memory. grub> linux /vmlinuz-4.9.0-1-sparc64-smp root=/dev/mapper/Volgroup_lv_root ro error: couldn't allocate physical memory. grub> boot error: you need to load the kernel first.
Re: Grub2 with sparc64 patches
> On Jan 24, 2017, at 6:34 AM, Frans van Berckel wrote: > > Hi Eric, > > On Mon, 2017-01-23 at 12:38 -0700, Eric Snowberg wrote: > >> Since the T5240 doesn’t support GPT, we have to use blocklists, could >> you try this instead: >> >> # grub-install —force /dev/sdb1 >> >> The following warning can be ignored for now: >> >> Installing for sparc64-ieee1275 platform. >> grub2-install: warning: Embedding is not possible. GRUB can only be >> installed in this setup by using blocklists. However, blocklists are >> UNRELIABLE and their use is discouraged.. >> Installation finished. No error reported. > > On an old Sun Blade 1000, without GPT partition table ... > > # fdisk -l > > Disk /dev/sda: 68.4 GiB, 73407865856 bytes, 143374738 sectors > Geometry: 255 heads, 63 sectors/track, 8922 cylinders > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: sun > > DeviceStart End Sectors Size Id Type Flags > /dev/sda1 0 1048575 1048576 512M 1 Boot > /dev/sda2 1060290 2779244 1718955 839.3M 82 Linux swap u > /dev/sda3 0 143364059 143364060 68.4G 5 Whole disk > /dev/sda4 2779245 73095749 70316505 33.5G 83 Linux native > /dev/sda5 73095750 143364059 70268310 33.5G 83 Linux native > > ... it does this error as well ... > > # grub-install /dev/sda > > Installing for sparc64-ieee1275 platform. > grub-install: warning: Embedding is not possible. GRUB can only be > installed in this setup by using blocklists. However, blocklists are > UNRELIABLE and their use is discouraged.. > grub-install: error: will not proceed with blocklists. > > ... do i need to install it with a force on /dev/sda1 as well? With a sun/vtoc partition table like you have on a Sun Blade 1000. You will need to give it the boot partition (/dev/sda1 in your case) along with the —force option. For your system I’d recommend doing: # grub-install --force --skip-fs-probe /dev/sda1 If you were on a T4 or above that supports GPT and had a partition table like this: Model: LSI MR9361-8i (scsi) Disk /dev/sda: 2995GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End SizeFile system Name Flags 1 1049kB 1075MB 1074MB ext3 2 1075MB 1076MB 1049kB bios_grub 3 1076MB 2995GB 2994GB lvm Then you could do: # grub-install /dev/sda > Question, and how is this gonna remove the silo boot block on disk? This will remove silo’s boot block and replace it with grub's. If you want to go back to silo, just do: silo -r / > > Thanks, > > Frans van Berckel
Re: Grub2 with sparc64 patches
On 01/24/2017 02:34 PM, Frans van Berckel wrote: > On an old Sun Blade 1000, without GPT partition table ... Isn't that sun4u? I think these aren't supported yet. > ... do i need to install it with a force on /dev/sda1 as well? Yes. As Eric said: If your machine doesn't support GPT, you have to use --force. > Question, and how is this gonna remove the silo boot block on disk? Well, I assume GRUB overwrites the SILO bootblock. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Grub2 with sparc64 patches
Hi Eric, On Mon, 2017-01-23 at 12:38 -0700, Eric Snowberg wrote: > Since the T5240 doesn’t support GPT, we have to use blocklists, could > you try this instead: > > # grub-install —force /dev/sdb1 > > The following warning can be ignored for now: > > Installing for sparc64-ieee1275 platform. > grub2-install: warning: Embedding is not possible. GRUB can only be > installed in this setup by using blocklists. However, blocklists are > UNRELIABLE and their use is discouraged.. > Installation finished. No error reported. On an old Sun Blade 1000, without GPT partition table ... # fdisk -l Disk /dev/sda: 68.4 GiB, 73407865856 bytes, 143374738 sectors Geometry: 255 heads, 63 sectors/track, 8922 cylinders Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: sun DeviceStart End Sectors Size Id Type Flags /dev/sda1 0 1048575 1048576 512M 1 Boot /dev/sda2 1060290 2779244 1718955 839.3M 82 Linux swap u /dev/sda3 0 143364059 143364060 68.4G 5 Whole disk /dev/sda4 2779245 73095749 70316505 33.5G 83 Linux native /dev/sda5 73095750 143364059 70268310 33.5G 83 Linux native ... it does this error as well ... # grub-install /dev/sda Installing for sparc64-ieee1275 platform. grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. grub-install: error: will not proceed with blocklists. ... do i need to install it with a force on /dev/sda1 as well? Question, and how is this gonna remove the silo boot block on disk? Thanks, Frans van Berckel
Re: libx11: Issues with Data32/_XData32
Am 24.01.2017 09:18, schrieb Julien Cristau: > On Tue, Jan 24, 2017 at 01:12:23 +, James Clarke wrote: > >> Hi, >> I've been debugging an issue in gtk2-perl causing it to SIGBUS on >> sparc64, and traced it back to what seems to be dodgy code inside >> libx11. One of the tests calls gdk_window_set_opacity, which calls >> XChangeProperty with a pointer to a guint32, cast to char*, with the >> length set to 32 bits as expected. However, this data pointer then gets >> cast to a (long *) on line 83 of ChProp.c when calling Data32. Indeed, >> the definition of Data32 specifies that data is a (long *) on sparc64, >> since LONG64 is defined. This feels very wrong, but in and of itself is >> not too bad (I believe it violates strict aliasing). >> > As discussed on irc this sounds like a gtk bug, fixed by > https://git.gnome.org/browse/gtk+/commit/?id=0e1a424829937abc27780da97a8bf60e81233d6c > for gtk 3. > I have read the page and found that sentence but i believe that it is realy hard to find if you do not know where to look. I would suggest to add a small example to clarify the problem. re, wh
Bug#852401: SIGBUS due to gdk_x11_window_set_opacity on sparc64
Source: gtk+2.0
Version: 2.24.31-1
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Control: affects -1 libgtk2-perl
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=777683
Hi,
Currently, libgtk2-perl crashes in its testsuite in a call to
gdk_x11_window_set_opacity with a SIGBUS. This turns out to be a bug in
GTK+, which was fixed in GTK+3.0 but never backported. Patch attached.
Regards,
James
>From 710f538d68e6f9ca0b2fbe38df3f8ee35ddd0126 Mon Sep 17 00:00:00 2001
From: James Clarke
Date: Tue, 24 Jan 2017 08:35:28 +
Subject: [PATCH] Don't use guint32 with XChangeProperty
Fixes bug 777683.
---
gdk/x11/gdkwindow-x11.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdk/x11/gdkwindow-x11.c b/gdk/x11/gdkwindow-x11.c
index 837f605..887a5ef 100644
--- a/gdk/x11/gdkwindow-x11.c
+++ b/gdk/x11/gdkwindow-x11.c
@@ -5575,7 +5575,7 @@ gdk_window_set_opacity (GdkWindow *window,
gdoubleopacity)
{
GdkDisplay *display;
- guint32 cardinal;
+ gulong cardinal;
g_return_if_fail (GDK_IS_WINDOW (window));
--
2.11.0
Re: libx11: Issues with Data32/_XData32
On Tue, Jan 24, 2017 at 01:12:23 +, James Clarke wrote: > Hi, > I've been debugging an issue in gtk2-perl causing it to SIGBUS on > sparc64, and traced it back to what seems to be dodgy code inside > libx11. One of the tests calls gdk_window_set_opacity, which calls > XChangeProperty with a pointer to a guint32, cast to char*, with the > length set to 32 bits as expected. However, this data pointer then gets > cast to a (long *) on line 83 of ChProp.c when calling Data32. Indeed, > the definition of Data32 specifies that data is a (long *) on sparc64, > since LONG64 is defined. This feels very wrong, but in and of itself is > not too bad (I believe it violates strict aliasing). > As discussed on irc this sounds like a gtk bug, fixed by https://git.gnome.org/browse/gtk+/commit/?id=0e1a424829937abc27780da97a8bf60e81233d6c for gtk 3. Cheers, Julien
