Re: unbreaking LibreOffices tests on at least release architectures
On Sat, Jul 22, 2023 at 8:10 AM Rene Engelhard wrote: > > Am 22.07.23 um 14:02 schrieb Andreas Schwab: > > On Jun 18 2023, Rene Engelhard wrote: > > > >> For riscv64 I already pointed that out in the thread starting at > >> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the > >> other architectures there is the mail now. riscv64 is different because > >> the failures are even more big than any other down below and it's actually > >> a new architecture anyway. > > Libreoffice is actually basically working on riscv64. > > Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile > says, though) Be careful of -Os. I test one of my C++ libraries with it in the library's test suite. Based on unexplained crashes with -Os, I believe GCC produces bad code with -Os on occasion. I do not recommend using -Os in production based on my experience. Jeff
Re: [syzbot] [hfs?] WARNING in hfs_write_inode
On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox wrote: > > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote: > > > Then we should delete the HFS/HFS+ filesystems. They're orphaned in > > > MAINTAINERS and if distros are going to do such a damnfool thing, > > > then we must stop them. > > > > Both HFS and HFS+ work perfectly fine. And if distributions or users are so > > sensitive about security, it's up to them to blacklist individual features > > in the kernel. > > > > Both HFS and HFS+ have been the default filesystem on MacOS for 30 years > > and I don't think it's justified to introduce such a hard compatibility > > breakage just because some people are worried about theoretical evil > > maid attacks. > > > > HFS/HFS+ mandatory if you want to boot Linux on a classic Mac or PowerMac > > and I don't think it's okay to break all these systems running Linux. > > If they're so popular, then it should be no trouble to find somebody > to volunteer to maintain those filesystems. Except they've been > marked as orphaned since 2011 and effectively were orphaned several > years before that (the last contribution I see from Roman Zippel is > in 2008, and his last contribution to hfs was in 2006). One data point may help.. I've been running Linux on an old PowerMac and an old Intel MacBook since about 2014 or 2015 or so. I have needed the HFS/HFS+ filesystem support for about 9 years now (including that "blessed" support for the Apple Boot partition). There's never been a problem with Linux and the Apple filesystems. Maybe it speaks to the maturity/stability of the code that already exists. The code does not need a lot of attention nowadays. Maybe the orphaned status is the wrong metric to use to determine removal. Maybe a better metric would be installation base. I.e., how many users use the filesystem. Jeff
Re: unbreaking LibreOffices tests on at least release architectures
On Mon, Jun 19, 2023 at 11:50 PM Rene Engelhard wrote: > > Am 20.06.23 um 00:03 schrieb Jeffrey Walton: > > > > You can usually uncover them by building the package with CFLAGS=" ... > > -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... > > ". The UBsan sanitizer operates on real data. There are no false > > positives. > > I'd personally assume this isn't UB since upstream builds with UBsan for > testing (admittedly not on mipsel, though). But once can investigate here... Yeah, there's a caveat: you have to have complete self tests. If the project lacks complete self tests, then you may not uncover the bug. You can run the program in production with a sanitizer build. It may uncover cases that were lacking in the test cases. And it's unfortunate some arches lack Asan and UBsan support. They are such powerful tools. Sometimes you can tease-out the UB on a different arch. Sometimes you can't. Jeff
Re: unbreaking LibreOffices tests on at least release architectures
On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard wrote: > > Hi, > > Am 19.06.23 um 23:19 schrieb Adrian Bunk: > > On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: > >> ... > >> I won't be of much help here unfortunately, except > >> maybe testing patches, but then again there's porterboxes > >> ... > > You are the only one who could realistically debug many of these. > > > > E.g. on armel it says: > >Fatal exception: Signal 6 > >Stack: > >/<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] > >/<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] > > > > /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] > >/lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] > >/lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] > >Aborted (core dumped) > > > > Fixing something like this would involve generating a backtrace, > > and then you are likely the only person in Debian who could tell > > what is actually going on there. > > Not really. > > > There are likely also build or debug tricks you know that a porter would > > not know. > > True, I can help with those if needed. > > (As I already pointed out for zelenka, though it's basically setting > some variables in rules) > > > Debugging something like this is only feasible with reasonable effort if > > a porter who knows the port with its caveats debugs it together with a > > package maintainer who knows the internals of the package. > > I didn't say I was not helping, I said I am of no help if it comes to > actually fix it if it involves architecture knowledge. > > [...] > > > For such a complex package I would expect 32bit breakage in every > > release if upstream no longer tests on 32bit. > Indeed, though at least for 32bit *build* issues they keep fixing them > if I report them. > > The pragmatic option would be to run only a smoketest for build success > > on architectures not tested by upstream. > > And have Format->Character in Impress crash with Bus error like on > mipsel? That doesn't sound too good for basic quality. > > There is a "smoketest" but it does just basic start. open, close stuff. > Not even basic usage. Related, bus errors are usually due to unaligned data accesses. Programmers casting from one type to another when when they shouldn't, like: typedef unsigned char byte; ... byte buffer[32]; readBuffer(buffer); double d = *(double *)buffer; That is undefined behavior because a byte buffer is a byte buffer, and it is not a double. That can result in a bus error on some platforms. You may get lucky and the byte buffer may be aligned for double. Or it may not be. In contrast, this would be Ok because the byte buffer is really a double object: typedef unsigned char byte; ... double d; byte* buffer = (bytes*) readBuffer(buffer); double dd = *(double *)buffer; You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. You don't need to be a porter to build and run with sanitizers. However, you do need an arch-specific machine. Or possibly a Debian chroot. Jeff
