Rick Thomas wrote...
> Can you give us some more details?
In general I'm somewhat reluctant since first conclusions are usually
wrong and I certainly don't want to create noise at the wrong place.
So I'd rather debug a little longer until I can identify the real
cause, and create a patch to prove I was right. So yesterday I would
wrongly have blamed openssl, now it rather looks like pcre3. Which
still might not be true.
But since I'm rather busy today doing other things, here are the bits
if you want to take over:
> 1) Which debian (stable/testing/sid)?
> 2) Which packages?
> 3) Which G4 boxes?
This is Debian stretch, package is syslog-ng 3.7.3-3, box is a
PowerMac G4 running a "7410, altivec supported" CPU.
Rebuild syslog-ng, you should see four errors in the test suite, the
first being
| PASS: lib/transport/tests/test_aux_data
| ../../test-driver: line 107: 77989 Illegal instruction "$@" > $log_file 2>&1
This is triggered by ./lib/logproto/tests/test_logproto, started
without any parameters.
Using gdb you will encounter SIGILL in the libcrypt initialization,
that's ok, openssl probes the CPU capabilities (see above). Second
time it's something like
| #0 0xb7faf008 in ?? ()
| #1 0x0fc42a38 in ?? () from /lib/powerpc-linux-gnu/libpcre.so.3
| #2 0x0fc67c20 in ?? () from /lib/powerpc-linux-gnu/libpcre.so.3
where disassemble shows different instructions when tried again, it's
either "mflr" or "mr". Next step would be to identify where the actual
instruction comes from and how the code path is triggered. Also big
question why this doesn't happen more often.
The package used to build with 3.7.3-1 back in July, the changes in
syslog-ng are minimal, and nothing obvious in pcre3 (was 2:8.38-3.1,
now it's 2:8.39-2).
Godspeed, and please share any findings so I can focus on other
issues.
Christoph
Attachment:
signature.asc
Description: Digital signature