On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard <r...@debian.org> 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:
> > /<<PKGBUILDDIR>>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4]
> > /<<PKGBUILDDIR>>/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*)&d;
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
