Hello, On 7/23/19 11:39 PM, László Böszörményi (GCS) wrote: > Control: tags -1 +moreinfo
This is unusual. According to https://www.debian.org/Bugs/Developer#tags the meaning of this tag is "This bug can't be addressed until more information is provided by the submitter. The bug will be closed if the submitter doesn't provide more information in a reasonable (few months) timeframe." > On Tue, Jul 23, 2019 at 11:09 PM Uwe Kleine-König <u...@kleine-koenig.org> > wrote: >> On Tue, Jul 23, 2019 at 09:14:53AM +0000, Uwe Kleine-König wrote: >>> the test suite for rauc (currently in NEW) provokes a Bus error in >>> mksquashfs on sparc64 (tested on kyoto.debian.net in a sid chroot). >>> Reproduction is as follows: >>> >>> install casync dbus dbus-x11 debhelper e2fsprogs faketime grub-common >>> libcurl4-gnutls-dev, libglib2.0-dev, libjson-glib-dev libssl-dev libtool >>> squashfs-tools systemd git >>> >>> git clone https://github.com/rauc/rauc.git >>> sed -i 's/0x73717368$/GUINT32_FROM_LE(0x73717368)/' src/bundle.c >>> sh autogen.sh >>> ./configure >>> make check >>> rm -rf /tmp/rauc-* >>> ./test/bundle.test >>> >>> The last command fails with >>> "rauc:ERROR:test/common.c:339:test_create_bundle: >>> 'create_bundle(bundlename, contentdir, NULL)' should be TRUE" and leaves >>> behind a directory that allows to reproduce the issue: >>> >>> $ rm -f image; mksquashfs /tmp/rauc-*/content image >>> Parallel mksquashfs: Using 32 processors >>> Creating 4.0 filesystem on image, block size 131072. >>> Bus error >> >> The problem is in all_zero from squashfs-tools/mksquashfs.c: >> >> int all_zero(struct file_buffer *file_buffer) >> { >> int i; >> long entries = file_buffer->size / sizeof(long); >> long *p = (long *) file_buffer->data; >> >> for(i = 0; i < entries && p[i] == 0; i++); >> >> if(i == entries) { >> for(i = file_buffer->size & ~(sizeof(long) - 1); >> i < file_buffer->size && file_buffer->data[i] == 0; >> i++); >> >> return i == file_buffer->size; >> } >> >> return 0; >> } >> >> If file_buffer->data isn't a multiple of sizeof(long) the access to p[0] >> traps on sparc. >> >> Replacing that by: >> >> int all_zero(struct file_buffer *file_buffer) >> { >> int i; >> >> for(i = 0; i < file_buffer->size; i++) >> if (file_buffer->data[i] != 0) >> return 0; >> >> return 1; >> } >> >> should fix it. On architectures that fixup unaligned accesses in the >> kernel it is probably even faster. My book about C ("C - A reference manual" by Samuel P. Harbison III and Guy L. Steele Jr.) has: If the alignment requirement for a type S is less stringent than that for type D, then the conversion from a "pointer to type S" to a "pointer to type D" could result in either of two kinds of unexpected behaviour. First, an attempt to use the resulting pointer to fetch or store an object of type D may cause an error, halting the program. Second, either the hardware or the implementation may "adjust" the destination pointer to be valid, usually by forcing it back to the nearest previous valid address. A subsequent conversion back to the original pointer type may not recover the original pointer. So all kind of strange things can happen, it seems sparc64 is the only Architecture in Debian that traps on unaligned accesses, see also https://wiki.debian.org/ArchitectureSpecificsMemo#Alignment Best regards Uwe
signature.asc
Description: OpenPGP digital signature
