https://github.com/zlib-ng/zlib-ng/commit/43dbfd6709fb3a8028430ea30f3da88fbeb3ced9 breaks adler32_neon support for Android arm target

Tombstones here

Build fingerprint: 'Redmi/picasso/picasso:11/RKQ1.200826.002/V<IP_ADDRESS>.RGICNXM:user/release-keys'
Revision: '0'
ABI: 'arm'
Timestamp: 2022-09-11 12:08:04.763957964+0800
Process uptime: 2s
Cmdline: zygote
pid: 2028, tid: 2028, name: main  >>> zygote <<<
uid: 0
signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0xe4e5adb0
r0  e4e5adb0  r1  e87f1098  r2  00006550  r3  00000000
r4  00000000  r5  00000056  r6  00000000  r7  e87f2640
r8  00000000  r9  0000fff1  r10 00000008  r11 000015a8
ip  00000008  sp  ff89e7f0  lr  ff89e828  pc  e4e67f64
backtrace:
#00 pc 00011f64  /system/lib/libz.so (adler32_neon+320) (BuildId: 29a5b7ef6252f153585ea0cb10ea7021)
#01 pc 000171c7  /apex/com.android.art/lib/libdexfile.so (art::DexFile::CalculateChecksum() const+24) (BuildId: 8fb71c781ff03cc731e29bdfeae0c86f)
#02 pc 0001dd5d  /apex/com.android.art/lib/libdexfile.so (art::dex::DexFileVerifier::CheckHeader()+36) (BuildId: 8fb71c781ff03cc731e29bdfeae0c86f)
#03 pc 00024b7f  /apex/com.android.art/lib/libdexfile.so (art::dex::DexFileVerifier::Verify()+18) (BuildId: 8fb71c781ff03cc731e29bdfeae0c86f)
#04 pc 000251dd  /apex/com.android.art/lib/libdexfile.so (art::dex::Verify(art::DexFile const*, unsigned char const*, unsigned int, char const*, bool, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >)+140) (BuildId: 8fb71c781ff03cc731e29bdfeae0c86f)
#05 pc 0001b227  /apex/com.android.art/lib/libdexfile.so (art::DexFileLoader::OpenCommon(unsigned char const, unsigned int, unsigned char const*, unsigned int, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, unsigned int, art::OatDexFile const*, bool, bool, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::unique_ptr<art::DexFileContainer, std::__1::default_deleteart::DexFileContainer >, art::DexFileLoader::VerifyResult)+198) (BuildId: 8fb71c781ff03cc731e29bdfeae0c86f)
#06 pc 00014bc9  /apex/com.android.art/lib/libdexfile.so (art::ArtDexFileLoader::OpenOneDexFileFromZip(art::ZipArchive const&, char const*, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, bool, bool, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, art::DexFileLoaderErrorCode) const+708) (BuildId: 8fb71c781ff03cc731e29bdfeae0c86f)
#07 pc 0001464b  /apex/com.android.art/lib/libdexfile.so (art::ArtDexFileLoader::OpenAllDexFilesFromZip(art::ZipArchive const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, bool, bool, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::vector<std::__1::unique_ptr<art::DexFile const, std::__1::default_delete<art::DexFile const> >, std::__1::allocator<std::__1::unique_ptr<art::DexFile const, std::__1::default_delete<art::DexFile const> > > >) const+142) (BuildId: 8fb71c781ff03cc731e29bdfeae0c86f)
Meanwhile i find that partially revert that commit: See https://github.com/AcmeUI/android_external_zlib-ng/commit/9c79620f2e145861e58146e7ca7134969f9b9e18 does help

This seems alignment-related issue. @KungFuJesus

Where are you seeing alignment issues? Arm has no such alignment requirement but even so the neon implementation of  adler32 does scalar sums until it's aligned to 16 bytes for the loads.

What instruction is 0x320 bytes into the adler32_neon function? It'd be good to know which load is causing your issues. As far as I can tell though everything should be properly aligned to their proper types, including the bytes being summed (despite that not actually being a requirement).

Also interesting is that the address it's faulting on modulo 16 is zero. That means that even widest possible load would be a naturally aligned one. This sigbus makes no sense. Usually you see sigbus on arm by violating natural alignment for scalar types. All of the scalar arguments here are not doing any sort of aliasing with pointers.

@asuka-mio is this reproducible with a debug build? Might it be possible to at least provide a core dump for some post mortem? On paper it seems like this shouldn't be happening unless maybe something lied about the length of a buffer somewhere and nothing verified it.

@asuka-mio is this reproducible with a debug build? Might it be possible to at least provide a core dump for some post mortem? On paper it seems like this shouldn't be happening unless maybe something lied about the length of a buffer somewhere and nothing verified it.

Yes, we can reproduce it just through download the newest android ndk
CC=$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi33-clang ./configure --zlib-compat
make
And ship the libz to device
compile a short test:
#include <stddef.h>
#include <sys/types.h>
#include <zlib.h>
#include <stdlib.h>
int main()
{
size_t len = 8192;
void* buffer = malloc(len);
u_int32_t adler = adler32(0L, Z_NULL, 0);
u_int32_t aadler = adler32(adler, buffer, len);
free(buffer);
return 0;
}
Then compile it $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi33-clang source.c -lz and ship it to device
If we just execute it with normal libz, then nothing happen
But we use LD_PRELOAD=/path/to/shiped/libz , a SIGBUS will trigger
And with this patch applied https://github.com/AcmeUI/android_external_zlib-ng/commit/9c79620f2e145861e58146e7ca7134969f9b9e18 it works well too

@asuka-mio is this reproducible with a debug build? Might it be possible to at least provide a core dump for some post mortem? On paper it seems like this shouldn't be happening unless maybe something lied about the length of a buffer somewhere and nothing verified it.
And certainly, coredump here
core.txt
I rename the extension to upload via github webpage

@KungFuJesus Any idea about resolving it?

Any way you can get me the final binary as well?  I should be able to attach the coredump in gdb and inspect the state of your heap and stack at the time of the SIGBUS to see which load is causing your SIGBUS.
FWIW here's your test binary compiled on an aarch64 with Linux:
[adam@odroid ~]$ gcc -O3 -march=native test.c ~/zlib-ng-install/lib/libz.a -o test.out
[adam@odroid ~]$ ./test.out
[adam@odroid ~]$ echo $?
0

If it's that easy trigger your segfault though something else seems amiss.  Zlib quite recently bumped their API for 1.2.12 and zlib-ng was modified to be compatible with it.  Are you sure you're not LD_PRELOAD'ing over zlib 1.2.11?

Any way you can get me the final binary as well? I should be able to attach the coredump in gdb and inspect the state of your heap and stack at the time of the SIGBUS to see which load is causing your SIGBUS.
FWIW here's your test binary compiled on an aarch64 with Linux:
[adam@odroid ~]$ gcc -O3 -march=native test.c ~/zlib-ng-install/lib/libz.a -o test.out
[adam@odroid ~]$ ./test.out
[adam@odroid ~]$ echo $?
0

If it's that easy trigger your segfault though something else seems amiss. Zlib quite recently bumped their API for 1.2.12 and zlib-ng was modified to be compatible with it. Are you sure you're not LD_PRELOAD'ing over zlib 1.2.11?
One thing you can try is your example directly linked to zlib-ng. Does that crash?

Test program crashs if and only if it access the adler32 function, directly linking it won't trigger that problem
Here is binary files and coredump
files.zip

And I'm sure that something wrong in NEON_accum32 and that's what caused it

And I'm sure that something wrong in NEON_accum32 and that's what caused it

I tried simplify the problem
Try another test
file1: adler32_p.h
/* adler32_p.h -- Private inline functions and macros shared with

           different computation of the Adler-32 checksum

           of a data stream.

Copyright (C) 1995-2011, 2016 Mark Adler
For conditions of distribution and use, see copyright notice in zlib.h
*/

#ifndef ADLER32_P_H
#define ADLER32_P_H
#define BASE 65521U     /* largest prime smaller than 65536 /
#define NMAX 5552
/ NMAX is the largest n such that 255n(n+1)/2 + (n+1)(BASE-1) <= 2^32-1 */
#define DO1(sum1, sum2, buf, i)  {(sum1) += buf[(i)]; (sum2) += (sum1);}
#define DO2(sum1, sum2, buf, i)  {DO1(sum1, sum2, buf, i); DO1(sum1, sum2, buf, i+1);}
#define DO4(sum1, sum2, buf, i)  {DO2(sum1, sum2, buf, i); DO2(sum1, sum2, buf, i+2);}
#define DO8(sum1, sum2, buf, i)  {DO4(sum1, sum2, buf, i); DO4(sum1, sum2, buf, i+4);}
#define DO16(sum1, sum2, buf)    {DO8(sum1, sum2, buf, 0); DO8(sum1, sum2, buf, 8);}
static inline uint32_t adler32_len_1(uint32_t adler, const uint8_t *buf, uint32_t sum2) {
adler += buf[0];
adler %= BASE;
sum2 += adler;
sum2 %= BASE;
return adler | (sum2 << 16);
}
static inline uint32_t adler32_len_16(uint32_t adler, const uint8_t *buf, uint64_t len, uint32_t sum2) {
while (len) {
--len;
adler += buf++;
sum2 += adler;
}
adler %= BASE;
sum2 %= BASE;            / only added so many BASE's /
/ return recombined sums */
return adler | (sum2 << 16);
}
static inline uint32_t adler32_copy_len_16(uint32_t adler, const uint8_t *buf, uint8_t *dst, uint64_t len, uint32_t sum2) {
while (len--) {
*dst = *buf++;
adler += dst++;
sum2 += adler;
}
adler %= BASE;
sum2 %= BASE;            / only added so many BASE's /
/ return recombined sums */
return adler | (sum2 << 16);
}
static inline uint32_t adler32_len_64(uint32_t adler, const uint8_t buf, uint64_t len, uint32_t sum2) {
#ifdef UNROLL_MORE
while (len >= 16) {
len -= 16;
DO16(adler, sum2, buf);
buf += 16;
#else
while (len >= 8) {
len -= 8;
DO8(adler, sum2, buf, 0);
buf += 8;
#endif
}
/ Process tail (len < 16).  */
return adler32_len_16(adler, buf, len, sum2);
}
#endif /* ADLER32_P_H */

file2 source.c:
#include <stddef.h>
#include <string.h>
#include <stdlib.h>
#include <stdint.h>
#include <arm_neon.h>
#include "adler32_p.h"
#if defined(clang) || defined(GNUC)
define ALIGNED_(x) attribute ((aligned(x)))
#elif defined(_MSC_VER)
define ALIGNED_(x) __declspec(align(x))
#endif
/* Minimum of a and b. /
#define MIN(a, b) ((a) > (b) ? (b) : (a))
/ Maximum of a and b. */
#define MAX(a, b) ((a) < (b) ? (b) : (a))
#define vmull_high_u8(a, b) vmull_u8(vget_high_u8(a), vget_high_u8(b))
#define vmlal_high_u8(a, b, c) vmlal_u8(a, vget_high_u8(b), vget_high_u8(c))
#define vmlal_high_u16(a, b, c) vmlal_u16(a, vget_high_u16(b), vget_high_u16(c))
#define vaddw_high_u8(a, b) vaddw_u8(a, vget_high_u8(b))
static void NEON_accum32(uint32_t *s, const uint8_t *buf, uint64_t len) {
static const uint16_t ALIGNED_(16) taps[64] = {
64, 63, 62, 61, 60, 59, 58, 57,
56, 55, 54, 53, 52, 51, 50, 49,
48, 47, 46, 45, 44, 43, 42, 41,
40, 39, 38, 37, 36, 35, 34, 33,
32, 31, 30, 29, 28, 27, 26, 25,
24, 23, 22, 21, 20, 19, 18, 17,
16, 15, 14, 13, 12, 11, 10, 9,
8, 7, 6, 5, 4, 3, 2, 1 };
uint32x4_t adacc = vdupq_n_u32(0);
uint32x4_t s2acc = vdupq_n_u32(0);
uint32x4_t s2acc_0 = vdupq_n_u32(0);
uint32x4_t s2acc_1 = vdupq_n_u32(0);
uint32x4_t s2acc_2 = vdupq_n_u32(0);

adacc = vsetq_lane_u32(s[0], adacc, 0);
s2acc = vsetq_lane_u32(s[1], s2acc, 0);

uint32x4_t s3acc = vdupq_n_u32(0);
uint32x4_t adacc_prev = adacc;

uint16x8_t s2_0, s2_1, s2_2, s2_3;
s2_0 = s2_1 = s2_2 = s2_3 = vdupq_n_u16(0);

uint16x8_t s2_4, s2_5, s2_6, s2_7;
s2_4 = s2_5 = s2_6 = s2_7 = vdupq_n_u16(0);

uint64_t num_iter = len >> 2;
int rem = len & 3;

for (uint64_t i = 0; i < num_iter; ++i) {
    uint8x16x4_t d0_d3 = vld1q_u8_x4(buf);

    /* Unfortunately it doesn't look like there's a direct sum 8 bit to 32
     * bit instruction, we'll have to make due summing to 16 bits first */
    uint16x8x2_t hsum, hsum_fold;
    hsum.val[0] = vpaddlq_u8(d0_d3.val[0]);
    hsum.val[1] = vpaddlq_u8(d0_d3.val[1]);

    hsum_fold.val[0] = vpadalq_u8(hsum.val[0], d0_d3.val[2]);
    hsum_fold.val[1] = vpadalq_u8(hsum.val[1], d0_d3.val[3]);

    adacc = vpadalq_u16(adacc, hsum_fold.val[0]);
    s3acc = vaddq_u32(s3acc, adacc_prev);
    adacc = vpadalq_u16(adacc, hsum_fold.val[1]);

    /* If we do straight widening additions to the 16 bit values, we don't incur
     * the usual penalties of a pairwise add. We can defer the multiplications
     * until the very end. These will not overflow because we are incurring at
     * most 408 loop iterations (NMAX / 64), and a given lane is only going to be
     * summed into once. This means for the maximum input size, the largest value
     * we will see is 255 * 102 = 26010, safely under uint16 max */
    s2_0 = vaddw_u8(s2_0, vget_low_u8(d0_d3.val[0]));
    s2_1 = vaddw_high_u8(s2_1, d0_d3.val[0]);
    s2_2 = vaddw_u8(s2_2, vget_low_u8(d0_d3.val[1]));
    s2_3 = vaddw_high_u8(s2_3, d0_d3.val[1]);
    s2_4 = vaddw_u8(s2_4, vget_low_u8(d0_d3.val[2]));
    s2_5 = vaddw_high_u8(s2_5, d0_d3.val[2]);
    s2_6 = vaddw_u8(s2_6, vget_low_u8(d0_d3.val[3]));
    s2_7 = vaddw_high_u8(s2_7, d0_d3.val[3]);

    adacc_prev = adacc;
    buf += 64;
}

s3acc = vshlq_n_u32(s3acc, 6);

if (rem) {
    uint32x4_t s3acc_0 = vdupq_n_u32(0);
    while (rem--) {
        uint8x16_t d0 = vld1q_u8(buf);
        uint16x8_t adler;
        adler = vpaddlq_u8(d0);
        s2_6 = vaddw_u8(s2_6, vget_low_u8(d0));
        s2_7 = vaddw_high_u8(s2_7, d0);
        adacc = vpadalq_u16(adacc, adler);
        s3acc_0 = vaddq_u32(s3acc_0, adacc_prev);
        adacc_prev = adacc;
        buf += 16;
    }

    s3acc_0 = vshlq_n_u32(s3acc_0, 4);
    s3acc = vaddq_u32(s3acc_0, s3acc);
}

uint16x8x4_t t0_t3 = vld1q_u16_x4(taps);
uint16x8x4_t t4_t7 = vld1q_u16_x4(taps + 32);

s2acc = vmlal_high_u16(s2acc, t0_t3.val[0], s2_0);
s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t0_t3.val[0]), vget_low_u16(s2_0));
s2acc_1 = vmlal_high_u16(s2acc_1, t0_t3.val[1], s2_1);
s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t0_t3.val[1]), vget_low_u16(s2_1));

s2acc = vmlal_high_u16(s2acc, t0_t3.val[2], s2_2);
s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t0_t3.val[2]), vget_low_u16(s2_2));
s2acc_1 = vmlal_high_u16(s2acc_1, t0_t3.val[3], s2_3);
s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t0_t3.val[3]), vget_low_u16(s2_3));

s2acc = vmlal_high_u16(s2acc, t4_t7.val[0], s2_4);
s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t4_t7.val[0]), vget_low_u16(s2_4));
s2acc_1 = vmlal_high_u16(s2acc_1, t4_t7.val[1], s2_5);
s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t4_t7.val[1]), vget_low_u16(s2_5));

s2acc = vmlal_high_u16(s2acc, t4_t7.val[2], s2_6);
s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t4_t7.val[2]), vget_low_u16(s2_6));
s2acc_1 = vmlal_high_u16(s2acc_1, t4_t7.val[3], s2_7);
s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t4_t7.val[3]), vget_low_u16(s2_7));

s2acc = vaddq_u32(s2acc_0, s2acc);
s2acc_2 = vaddq_u32(s2acc_1, s2acc_2);
s2acc = vaddq_u32(s2acc, s2acc_2);

uint32x2_t adacc2, s2acc2, as;
s2acc = vaddq_u32(s2acc, s3acc);
adacc2 = vpadd_u32(vget_low_u32(adacc), vget_high_u32(adacc));
s2acc2 = vpadd_u32(vget_low_u32(s2acc), vget_high_u32(s2acc));
as = vpadd_u32(adacc2, s2acc2);
s[0] = vget_lane_u32(as, 0);
s[1] = vget_lane_u32(as, 1);

}
static void NEON_handle_tail(uint32_t *pair, const uint8_t *buf, uint64_t len) {
unsigned int i;
for (i = 0; i < len; ++i) {
pair[0] += buf[i];
pair[1] += pair[0];
}
}
uint32_t adler32_neon(uint32_t adler, const uint8_t buf, uint64_t len) {
/ split Adler-32 into component sums */
uint32_t sum2 = (adler >> 16) & 0xffff;
adler &= 0xffff;
/* in case user likes doing a byte at a time, keep it fast */
if (len == 1)
    return adler32_len_1(adler, buf, sum2);

/* initial Adler-32 value (deferred check for len == 1 speed) */
if (buf == NULL)
    return 1L;

/* in case short lengths are provided, keep it somewhat fast */
if (len < 16)
    return adler32_len_16(adler, buf, len, sum2);

uint32_t pair[2];
int n = NMAX;
unsigned int done = 0;

/* Split Adler-32 into component sums, it can be supplied by
 * the caller sites (e.g. in a PNG file).
 */
pair[0] = adler;
pair[1] = sum2;

/* If memory is not SIMD aligned, do scalar sums to an aligned
 * offset, provided that doing so doesn't completely eliminate
 * SIMD operation. Aligned loads are still faster on ARM, even
 * though there's no explicit aligned load instruction */
unsigned int align_offset = ((uintptr_t)buf & 15);
unsigned int align_adj = (align_offset) ? 16 - align_offset : 0;

if (align_offset && len >= (16 + align_adj)) {
    NEON_handle_tail(pair, buf, align_adj);
    n -= align_adj;
    done += align_adj;

} else {
    /* If here, we failed the len criteria test, it wouldn't be
     * worthwhile to do scalar aligning sums */
    align_adj = 0;
}

while (done < len) {
    int remaining = (int)(len - done);
    n = MIN(remaining, (done == align_adj) ? n : NMAX);

    if (n < 16)
        break;

    NEON_accum32(pair, buf + done, n >> 4);
    pair[0] %= BASE;
    pair[1] %= BASE;

    int actual_nsums = (n >> 4) << 4;
    done += actual_nsums;
}

/* Handle the tail elements. */
if (done < len) {
    NEON_handle_tail(pair, (buf + done), len - done);
    pair[0] %= BASE;
    pair[1] %= BASE;
}

/* D = B * 65536 + A, see: https://en.wikipedia.org/wiki/Adler-32. */
return (pair[1] << 16) | pair[0];

}
#define adler32 adler32_neon
#define Z_NULL NULL
int main()
{
size_t len = 8192;
void* buffer = malloc(len);
u_int32_t adler = adler32(0L, Z_NULL, 0);
u_int32_t aadler = adler32(adler, buffer, len);
free(buffer);
return 0;
}

Compile it directly: /opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi33-clang source.c
Ship it to device, execute it, crashed

source.zip

If it's not crashing with direct linking it seems very likely to not be an issue with the adler32 function itself but with an API incompatibility.  It seems probable that the change in API is making the function resolution break in strange ways from the global descriptor table from the ELF binary.
We can probably confirm this if you can compile something against vanilla zlib 1.2.12 and then LD_PRELOAD zlib-ng.
Your test binary also seems to be aarch32.  While I probably do have a 32 bit ARM system, I'm sure it doesn't have neon support.  Your crashing load when running objdump on your binary seems to be around here:
   17b44:       eea07b90        vdup.32 q8, r7
   17b48:       e1a0c009        mov     ip, r9
   17b4c:       e3a08000        mov     r8, #0
   17b50:       f4440aef        vst1.64 {d16-d17}, [r4 :128]```

vst1.64 is storing 2 x 64 bit wide stores from registers d16-d17 into the address contained in register 4 (which is presumed to be aligned to a 128 bit boundary, given the :128 hint).  From your stack trace + register printout, that address is in fact 128 bit (16 byte) aligned.  Interesting that the dump here shows the store into r4 and not r0, though it's possible you have some variance in your compilation from that crash that I may not be looking at the proper instruction.  Somewhat interesting is that we don't intentionally generate any stores until the final checksum, so this is very likely a compiler generated register spill.  Given that it assumes it can be aligned, it's probably spilling the `taps` array (aarch32 I would expect to have some register starvation so that makes sense).

Now, why there would be issues with stack alignment here...perhaps that's an android ABI thing?  The address certainly appears to be the proper alignment and you're not seeing crashes when linking directly, which is telling.  You could try removing that "ALIGNED_(16)" macro and that might coincidentally fix your problem but this seems like something stranger is happening.  Can you try linking your test application to zlib 1.2.12 and then LD_PRELOAD'ing the zlib-ng shared lib?  Officially, this method, while it works, is kind of discouraged, especially system-wide.  In particular you're subverting the loader and telling it to load all of the exported functions from the shared library before anything else and hoping that it's API compatible.

Oh my fault, I mistake your meaning, I just do linking and removed the function call, actually regardless of how to link, program only crash when it execute the adler32_neon

Just to double check your use case as close as possible (I'm on aarch64 and using Linux, not android, but perhaps this is a good enough test):
[adam@odroid ~]$ cat test.c
#include <stddef.h>
#include <sys/types.h>
#include <zlib.h>
#include <stdlib.h>

int main()
{
    size_t len = 8192;
    void* buffer = malloc(len);
    u_int32_t adler = adler32(0L, Z_NULL, 0);
    u_int32_t aadler = adler32(adler, buffer, len);
    free(buffer);
    return 0;
}

[adam@odroid blah]$ ls -alh /usr/lib/libz.so.1.2.12
-rwxr-xr-x 1 root root 90K Apr 24 06:07 /usr/lib/libz.so.1.2.12
[adam@odroid blah]$ cd
[adam@odroid ~]$ gcc -O3 -march=native test.c -lz -o test.out
[adam@odroid ~]$ ldd test.out
	linux-vdso.so.1 (0x0000ffffa93be000)
	libz.so.1 => /usr/lib/libz.so.1 (0x0000ffffa9330000)
	libc.so.6 => /usr/lib/libc.so.6 (0x0000ffffa9170000)
	/lib/ld-linux-aarch64.so.1 => /usr/lib/ld-linux-aarch64.so.1 (0x0000ffffa9385000)
[adam@odroid ~]$ LD_PRELOAD=/home/adam/zlib-ng-install/lib/libz.so.1.2.12.zlib-ng ./test.out
[adam@odroid ~]$ echo $?
0

source.zip

This test I extracted the function standalone and it does crashed

[adam@odroid blah]$ cat source.c
#include <stddef.h>
#include <string.h>
#include <stdlib.h>
#include <stdint.h>

#include <arm_neon.h>
#include "adler32_p.h"

#if defined(__clang__) || defined(__GNUC__)
#  define ALIGNED_(x) __attribute__ ((aligned(x)))
#elif defined(_MSC_VER)
#  define ALIGNED_(x) __declspec(align(x))
#endif

/* Minimum of a and b. */
#define MIN(a, b) ((a) > (b) ? (b) : (a))
/* Maximum of a and b. */
#define MAX(a, b) ((a) < (b) ? (b) : (a))

#define vmull_high_u8(a, b) vmull_u8(vget_high_u8(a), vget_high_u8(b))
#define vmlal_high_u8(a, b, c) vmlal_u8(a, vget_high_u8(b), vget_high_u8(c))
#define vmlal_high_u16(a, b, c) vmlal_u16(a, vget_high_u16(b), vget_high_u16(c))
#define vaddw_high_u8(a, b) vaddw_u8(a, vget_high_u8(b))

static void NEON_accum32(uint32_t *s, const uint8_t *buf, uint64_t len) {
    static const uint16_t ALIGNED_(16) taps[64] = {
        64, 63, 62, 61, 60, 59, 58, 57,
        56, 55, 54, 53, 52, 51, 50, 49,
        48, 47, 46, 45, 44, 43, 42, 41,
        40, 39, 38, 37, 36, 35, 34, 33,
        32, 31, 30, 29, 28, 27, 26, 25,
        24, 23, 22, 21, 20, 19, 18, 17,
        16, 15, 14, 13, 12, 11, 10, 9,
        8, 7, 6, 5, 4, 3, 2, 1 };

    uint32x4_t adacc = vdupq_n_u32(0);
    uint32x4_t s2acc = vdupq_n_u32(0);
    uint32x4_t s2acc_0 = vdupq_n_u32(0);
    uint32x4_t s2acc_1 = vdupq_n_u32(0);
    uint32x4_t s2acc_2 = vdupq_n_u32(0);

    adacc = vsetq_lane_u32(s[0], adacc, 0);
    s2acc = vsetq_lane_u32(s[1], s2acc, 0);

    uint32x4_t s3acc = vdupq_n_u32(0);
    uint32x4_t adacc_prev = adacc;

    uint16x8_t s2_0, s2_1, s2_2, s2_3;
    s2_0 = s2_1 = s2_2 = s2_3 = vdupq_n_u16(0);

    uint16x8_t s2_4, s2_5, s2_6, s2_7;
    s2_4 = s2_5 = s2_6 = s2_7 = vdupq_n_u16(0);

    uint64_t num_iter = len >> 2;
    int rem = len & 3;

    for (uint64_t i = 0; i < num_iter; ++i) {
        uint8x16x4_t d0_d3 = vld1q_u8_x4(buf);

        /* Unfortunately it doesn't look like there's a direct sum 8 bit to 32
         * bit instruction, we'll have to make due summing to 16 bits first */
        uint16x8x2_t hsum, hsum_fold;
        hsum.val[0] = vpaddlq_u8(d0_d3.val[0]);
        hsum.val[1] = vpaddlq_u8(d0_d3.val[1]);

        hsum_fold.val[0] = vpadalq_u8(hsum.val[0], d0_d3.val[2]);
        hsum_fold.val[1] = vpadalq_u8(hsum.val[1], d0_d3.val[3]);

        adacc = vpadalq_u16(adacc, hsum_fold.val[0]);
        s3acc = vaddq_u32(s3acc, adacc_prev);
        adacc = vpadalq_u16(adacc, hsum_fold.val[1]);

        /* If we do straight widening additions to the 16 bit values, we don't incur
         * the usual penalties of a pairwise add. We can defer the multiplications
         * until the very end. These will not overflow because we are incurring at
         * most 408 loop iterations (NMAX / 64), and a given lane is only going to be
         * summed into once. This means for the maximum input size, the largest value
         * we will see is 255 * 102 = 26010, safely under uint16 max */
        s2_0 = vaddw_u8(s2_0, vget_low_u8(d0_d3.val[0]));
        s2_1 = vaddw_high_u8(s2_1, d0_d3.val[0]);
        s2_2 = vaddw_u8(s2_2, vget_low_u8(d0_d3.val[1]));
        s2_3 = vaddw_high_u8(s2_3, d0_d3.val[1]);
        s2_4 = vaddw_u8(s2_4, vget_low_u8(d0_d3.val[2]));
        s2_5 = vaddw_high_u8(s2_5, d0_d3.val[2]);
        s2_6 = vaddw_u8(s2_6, vget_low_u8(d0_d3.val[3]));
        s2_7 = vaddw_high_u8(s2_7, d0_d3.val[3]);

        adacc_prev = adacc;
        buf += 64;
    }

    s3acc = vshlq_n_u32(s3acc, 6);

    if (rem) {
        uint32x4_t s3acc_0 = vdupq_n_u32(0);
        while (rem--) {
            uint8x16_t d0 = vld1q_u8(buf);
            uint16x8_t adler;
            adler = vpaddlq_u8(d0);
            s2_6 = vaddw_u8(s2_6, vget_low_u8(d0));
            s2_7 = vaddw_high_u8(s2_7, d0);
            adacc = vpadalq_u16(adacc, adler);
            s3acc_0 = vaddq_u32(s3acc_0, adacc_prev);
            adacc_prev = adacc;
            buf += 16;
        }

        s3acc_0 = vshlq_n_u32(s3acc_0, 4);
        s3acc = vaddq_u32(s3acc_0, s3acc);
    }

    uint16x8x4_t t0_t3 = vld1q_u16_x4(taps);
    uint16x8x4_t t4_t7 = vld1q_u16_x4(taps + 32);

    s2acc = vmlal_high_u16(s2acc, t0_t3.val[0], s2_0);
    s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t0_t3.val[0]), vget_low_u16(s2_0));
    s2acc_1 = vmlal_high_u16(s2acc_1, t0_t3.val[1], s2_1);
    s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t0_t3.val[1]), vget_low_u16(s2_1));

    s2acc = vmlal_high_u16(s2acc, t0_t3.val[2], s2_2);
    s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t0_t3.val[2]), vget_low_u16(s2_2));
    s2acc_1 = vmlal_high_u16(s2acc_1, t0_t3.val[3], s2_3);
    s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t0_t3.val[3]), vget_low_u16(s2_3));

    s2acc = vmlal_high_u16(s2acc, t4_t7.val[0], s2_4);
    s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t4_t7.val[0]), vget_low_u16(s2_4));
    s2acc_1 = vmlal_high_u16(s2acc_1, t4_t7.val[1], s2_5);
    s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t4_t7.val[1]), vget_low_u16(s2_5));

    s2acc = vmlal_high_u16(s2acc, t4_t7.val[2], s2_6);
    s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t4_t7.val[2]), vget_low_u16(s2_6));
    s2acc_1 = vmlal_high_u16(s2acc_1, t4_t7.val[3], s2_7);
    s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t4_t7.val[3]), vget_low_u16(s2_7));

    s2acc = vaddq_u32(s2acc_0, s2acc);
    s2acc_2 = vaddq_u32(s2acc_1, s2acc_2);
    s2acc = vaddq_u32(s2acc, s2acc_2);

    uint32x2_t adacc2, s2acc2, as;
    s2acc = vaddq_u32(s2acc, s3acc);
    adacc2 = vpadd_u32(vget_low_u32(adacc), vget_high_u32(adacc));
    s2acc2 = vpadd_u32(vget_low_u32(s2acc), vget_high_u32(s2acc));
    as = vpadd_u32(adacc2, s2acc2);
    s[0] = vget_lane_u32(as, 0);
    s[1] = vget_lane_u32(as, 1);
}

static void NEON_handle_tail(uint32_t *pair, const uint8_t *buf, uint64_t len) {
    unsigned int i;
    for (i = 0; i < len; ++i) {
        pair[0] += buf[i];
        pair[1] += pair[0];
    }
}

uint32_t adler32_neon(uint32_t adler, const uint8_t *buf, uint64_t len) {
    /* split Adler-32 into component sums */
    uint32_t sum2 = (adler >> 16) & 0xffff;
    adler &= 0xffff;

    /* in case user likes doing a byte at a time, keep it fast */
    if (len == 1)
        return adler32_len_1(adler, buf, sum2);

    /* initial Adler-32 value (deferred check for len == 1 speed) */
    if (buf == NULL)
        return 1L;

    /* in case short lengths are provided, keep it somewhat fast */
    if (len < 16)
        return adler32_len_16(adler, buf, len, sum2);

    uint32_t pair[2];
    int n = NMAX;
    unsigned int done = 0;

    /* Split Adler-32 into component sums, it can be supplied by
     * the caller sites (e.g. in a PNG file).
     */
    pair[0] = adler;
    pair[1] = sum2;

    /* If memory is not SIMD aligned, do scalar sums to an aligned
     * offset, provided that doing so doesn't completely eliminate
     * SIMD operation. Aligned loads are still faster on ARM, even
     * though there's no explicit aligned load instruction */
    unsigned int align_offset = ((uintptr_t)buf & 15);
    unsigned int align_adj = (align_offset) ? 16 - align_offset : 0;

    if (align_offset && len >= (16 + align_adj)) {
        NEON_handle_tail(pair, buf, align_adj);
        n -= align_adj;
        done += align_adj;

    } else {
        /* If here, we failed the len criteria test, it wouldn't be
         * worthwhile to do scalar aligning sums */
        align_adj = 0;
    }

    while (done < len) {
        int remaining = (int)(len - done);
        n = MIN(remaining, (done == align_adj) ? n : NMAX);

        if (n < 16)
            break;

        NEON_accum32(pair, buf + done, n >> 4);
        pair[0] %= BASE;
        pair[1] %= BASE;

        int actual_nsums = (n >> 4) << 4;
        done += actual_nsums;
    }

    /* Handle the tail elements. */
    if (done < len) {
        NEON_handle_tail(pair, (buf + done), len - done);
        pair[0] %= BASE;
        pair[1] %= BASE;
    }

    /* D = B * 65536 + A, see: https://en.wikipedia.org/wiki/Adler-32. */
    return (pair[1] << 16) | pair[0];
}

#define adler32 adler32_neon
#define Z_NULL NULL

int main()
{
    size_t len = 8192;
    void* buffer = malloc(len);
    u_int32_t adler = adler32(0L, Z_NULL, 0);
    u_int32_t aadler = adler32(adler, buffer, len);
    free(buffer);
    return 0;
}[adam@odroid blah]$ gcc -march=native source.c -o test.out -lz
[adam@odroid blah]$ LD_PRELOAD=/home/adam/zlib-ng-install/lib/libz.so.1.2.12.zlib-ng ./test.out
[adam@odroid blah]$ echo $?
0

The -march=native is merely to enable neon at compilation time.  Though, that bit probably isn't strictly necessary with aarch64 since asimd is pretty much implicit, I think.  I'm definitely not seeing a crash.  What version of vanilla zlib are you linking to?  This matters a lot.  You said you see this crash if you link directly to zlib-ng as well?

This test doesn't link to zlib, I just extract the function out

dump.zip
And dumps here

[adam@odroid blah]$ cat source.c
#include <stddef.h>
#include <string.h>
#include <stdlib.h>
#include <stdint.h>

#include <arm_neon.h>
#include "adler32_p.h"

#if defined(__clang__) || defined(__GNUC__)
#  define ALIGNED_(x) __attribute__ ((aligned(x)))
#elif defined(_MSC_VER)
#  define ALIGNED_(x) __declspec(align(x))
#endif

/* Minimum of a and b. */
#define MIN(a, b) ((a) > (b) ? (b) : (a))
/* Maximum of a and b. */
#define MAX(a, b) ((a) < (b) ? (b) : (a))

#define vmull_high_u8(a, b) vmull_u8(vget_high_u8(a), vget_high_u8(b))
#define vmlal_high_u8(a, b, c) vmlal_u8(a, vget_high_u8(b), vget_high_u8(c))
#define vmlal_high_u16(a, b, c) vmlal_u16(a, vget_high_u16(b), vget_high_u16(c))
#define vaddw_high_u8(a, b) vaddw_u8(a, vget_high_u8(b))

static void NEON_accum32(uint32_t *s, const uint8_t *buf, uint64_t len) {
    static const uint16_t ALIGNED_(16) taps[64] = {
        64, 63, 62, 61, 60, 59, 58, 57,
        56, 55, 54, 53, 52, 51, 50, 49,
        48, 47, 46, 45, 44, 43, 42, 41,
        40, 39, 38, 37, 36, 35, 34, 33,
        32, 31, 30, 29, 28, 27, 26, 25,
        24, 23, 22, 21, 20, 19, 18, 17,
        16, 15, 14, 13, 12, 11, 10, 9,
        8, 7, 6, 5, 4, 3, 2, 1 };

    uint32x4_t adacc = vdupq_n_u32(0);
    uint32x4_t s2acc = vdupq_n_u32(0);
    uint32x4_t s2acc_0 = vdupq_n_u32(0);
    uint32x4_t s2acc_1 = vdupq_n_u32(0);
    uint32x4_t s2acc_2 = vdupq_n_u32(0);

    adacc = vsetq_lane_u32(s[0], adacc, 0);
    s2acc = vsetq_lane_u32(s[1], s2acc, 0);

    uint32x4_t s3acc = vdupq_n_u32(0);
    uint32x4_t adacc_prev = adacc;

    uint16x8_t s2_0, s2_1, s2_2, s2_3;
    s2_0 = s2_1 = s2_2 = s2_3 = vdupq_n_u16(0);

    uint16x8_t s2_4, s2_5, s2_6, s2_7;
    s2_4 = s2_5 = s2_6 = s2_7 = vdupq_n_u16(0);

    uint64_t num_iter = len >> 2;
    int rem = len & 3;

    for (uint64_t i = 0; i < num_iter; ++i) {
        uint8x16x4_t d0_d3 = vld1q_u8_x4(buf);

        /* Unfortunately it doesn't look like there's a direct sum 8 bit to 32
         * bit instruction, we'll have to make due summing to 16 bits first */
        uint16x8x2_t hsum, hsum_fold;
        hsum.val[0] = vpaddlq_u8(d0_d3.val[0]);
        hsum.val[1] = vpaddlq_u8(d0_d3.val[1]);

        hsum_fold.val[0] = vpadalq_u8(hsum.val[0], d0_d3.val[2]);
        hsum_fold.val[1] = vpadalq_u8(hsum.val[1], d0_d3.val[3]);

        adacc = vpadalq_u16(adacc, hsum_fold.val[0]);
        s3acc = vaddq_u32(s3acc, adacc_prev);
        adacc = vpadalq_u16(adacc, hsum_fold.val[1]);

        /* If we do straight widening additions to the 16 bit values, we don't incur
         * the usual penalties of a pairwise add. We can defer the multiplications
         * until the very end. These will not overflow because we are incurring at
         * most 408 loop iterations (NMAX / 64), and a given lane is only going to be
         * summed into once. This means for the maximum input size, the largest value
         * we will see is 255 * 102 = 26010, safely under uint16 max */
        s2_0 = vaddw_u8(s2_0, vget_low_u8(d0_d3.val[0]));
        s2_1 = vaddw_high_u8(s2_1, d0_d3.val[0]);
        s2_2 = vaddw_u8(s2_2, vget_low_u8(d0_d3.val[1]));
        s2_3 = vaddw_high_u8(s2_3, d0_d3.val[1]);
        s2_4 = vaddw_u8(s2_4, vget_low_u8(d0_d3.val[2]));
        s2_5 = vaddw_high_u8(s2_5, d0_d3.val[2]);
        s2_6 = vaddw_u8(s2_6, vget_low_u8(d0_d3.val[3]));
        s2_7 = vaddw_high_u8(s2_7, d0_d3.val[3]);

        adacc_prev = adacc;
        buf += 64;
    }

    s3acc = vshlq_n_u32(s3acc, 6);

    if (rem) {
        uint32x4_t s3acc_0 = vdupq_n_u32(0);
        while (rem--) {
            uint8x16_t d0 = vld1q_u8(buf);
            uint16x8_t adler;
            adler = vpaddlq_u8(d0);
            s2_6 = vaddw_u8(s2_6, vget_low_u8(d0));
            s2_7 = vaddw_high_u8(s2_7, d0);
            adacc = vpadalq_u16(adacc, adler);
            s3acc_0 = vaddq_u32(s3acc_0, adacc_prev);
            adacc_prev = adacc;
            buf += 16;
        }

        s3acc_0 = vshlq_n_u32(s3acc_0, 4);
        s3acc = vaddq_u32(s3acc_0, s3acc);
    }

    uint16x8x4_t t0_t3 = vld1q_u16_x4(taps);
    uint16x8x4_t t4_t7 = vld1q_u16_x4(taps + 32);

    s2acc = vmlal_high_u16(s2acc, t0_t3.val[0], s2_0);
    s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t0_t3.val[0]), vget_low_u16(s2_0));
    s2acc_1 = vmlal_high_u16(s2acc_1, t0_t3.val[1], s2_1);
    s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t0_t3.val[1]), vget_low_u16(s2_1));

    s2acc = vmlal_high_u16(s2acc, t0_t3.val[2], s2_2);
    s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t0_t3.val[2]), vget_low_u16(s2_2));
    s2acc_1 = vmlal_high_u16(s2acc_1, t0_t3.val[3], s2_3);
    s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t0_t3.val[3]), vget_low_u16(s2_3));

    s2acc = vmlal_high_u16(s2acc, t4_t7.val[0], s2_4);
    s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t4_t7.val[0]), vget_low_u16(s2_4));
    s2acc_1 = vmlal_high_u16(s2acc_1, t4_t7.val[1], s2_5);
    s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t4_t7.val[1]), vget_low_u16(s2_5));

    s2acc = vmlal_high_u16(s2acc, t4_t7.val[2], s2_6);
    s2acc_0 = vmlal_u16(s2acc_0, vget_low_u16(t4_t7.val[2]), vget_low_u16(s2_6));
    s2acc_1 = vmlal_high_u16(s2acc_1, t4_t7.val[3], s2_7);
    s2acc_2 = vmlal_u16(s2acc_2, vget_low_u16(t4_t7.val[3]), vget_low_u16(s2_7));

    s2acc = vaddq_u32(s2acc_0, s2acc);
    s2acc_2 = vaddq_u32(s2acc_1, s2acc_2);
    s2acc = vaddq_u32(s2acc, s2acc_2);

    uint32x2_t adacc2, s2acc2, as;
    s2acc = vaddq_u32(s2acc, s3acc);
    adacc2 = vpadd_u32(vget_low_u32(adacc), vget_high_u32(adacc));
    s2acc2 = vpadd_u32(vget_low_u32(s2acc), vget_high_u32(s2acc));
    as = vpadd_u32(adacc2, s2acc2);
    s[0] = vget_lane_u32(as, 0);
    s[1] = vget_lane_u32(as, 1);
}

static void NEON_handle_tail(uint32_t *pair, const uint8_t *buf, uint64_t len) {
    unsigned int i;
    for (i = 0; i < len; ++i) {
        pair[0] += buf[i];
        pair[1] += pair[0];
    }
}

uint32_t adler32_neon(uint32_t adler, const uint8_t *buf, uint64_t len) {
    /* split Adler-32 into component sums */
    uint32_t sum2 = (adler >> 16) & 0xffff;
    adler &= 0xffff;

    /* in case user likes doing a byte at a time, keep it fast */
    if (len == 1)
        return adler32_len_1(adler, buf, sum2);

    /* initial Adler-32 value (deferred check for len == 1 speed) */
    if (buf == NULL)
        return 1L;

    /* in case short lengths are provided, keep it somewhat fast */
    if (len < 16)
        return adler32_len_16(adler, buf, len, sum2);

    uint32_t pair[2];
    int n = NMAX;
    unsigned int done = 0;

    /* Split Adler-32 into component sums, it can be supplied by
     * the caller sites (e.g. in a PNG file).
     */
    pair[0] = adler;
    pair[1] = sum2;

    /* If memory is not SIMD aligned, do scalar sums to an aligned
     * offset, provided that doing so doesn't completely eliminate
     * SIMD operation. Aligned loads are still faster on ARM, even
     * though there's no explicit aligned load instruction */
    unsigned int align_offset = ((uintptr_t)buf & 15);
    unsigned int align_adj = (align_offset) ? 16 - align_offset : 0;

    if (align_offset && len >= (16 + align_adj)) {
        NEON_handle_tail(pair, buf, align_adj);
        n -= align_adj;
        done += align_adj;

    } else {
        /* If here, we failed the len criteria test, it wouldn't be
         * worthwhile to do scalar aligning sums */
        align_adj = 0;
    }

    while (done < len) {
        int remaining = (int)(len - done);
        n = MIN(remaining, (done == align_adj) ? n : NMAX);

        if (n < 16)
            break;

        NEON_accum32(pair, buf + done, n >> 4);
        pair[0] %= BASE;
        pair[1] %= BASE;

        int actual_nsums = (n >> 4) << 4;
        done += actual_nsums;
    }

    /* Handle the tail elements. */
    if (done < len) {
        NEON_handle_tail(pair, (buf + done), len - done);
        pair[0] %= BASE;
        pair[1] %= BASE;
    }

    /* D = B * 65536 + A, see: https://en.wikipedia.org/wiki/Adler-32. */
    return (pair[1] << 16) | pair[0];
}

#define adler32 adler32_neon
#define Z_NULL NULL

int main()
{
    size_t len = 8192;
    void* buffer = malloc(len);
    u_int32_t adler = adler32(0L, Z_NULL, 0);
    u_int32_t aadler = adler32(adler, buffer, len);
    free(buffer);
    return 0;
}[adam@odroid blah]$ gcc -march=native source.c -o test.out -lz
[adam@odroid blah]$ LD_PRELOAD=/home/adam/zlib-ng-install/lib/libz.so.1.2.12.zlib-ng ./test.out
[adam@odroid blah]$ echo $?
0

The -march=native is merely to enable neon at compilation time. Though, that bit probably isn't strictly necessary with aarch64 since asimd is pretty much implicit, I think. I'm definitely not seeing a crash. What version of vanilla zlib are you linking to? This matters a lot. You said you see this crash if you link directly to zlib-ng as well?

Yes, directly linking it crashed as well if I called the adler32 function

So I make the adler32 neon impl standalone to test if it will crash
And significantly the same error

That's peculiar. I'm pretty sure our ci has an aarch32 target running neon (on Linux, at least). Does the crash go away if you remove the ALIGNED_(16) macro? There's no technical reason it needs it, it's simply an (probably meaningful on aarch32) optimization. Doing so should remove that alignment hint.
If that's the case, there might be a bug in the clang distributed with NDK.

No, after delete the ALIGNED marco, it triggered a bus error as well

There's no obvious bug here that would trigger this. The loads themselves are of the natural type for a byte and the spills are generated by the compiler.
The only thing I can think of is the 4x load rather than 4 separate discrete loads. I'm fairly certain there's no alignment requirement for that in the arm abi to begin with, but maybe?

I suspect clang is generating an alignment hint regardless at those stores.  Now the address at the sigbus seemed properly aligned so that was weird but:
https://github.com/android/ndk/issues/640
There's at least some evidence that clang excessively decorates with that hint. Which of course will generate a fault if not properly aligned. This is really strange. It's an issue that disappears entirely on aarch64 as that hint I think is non-existent.

Yes, it's a clang specific issue, I tried compile with arm gcc and libc static linked, works well

I suspect clang is generating an alignment hint regardless at those stores. Now the address at the sigbus seemed properly aligned so that was weird but: android/ndk#640
There's at least some evidence that clang excessively decorates with that hint. Which of course will generate a fault if not properly aligned. This is really strange. It's an issue that disappears entirely on aarch64 as that hint I think is non-existent.

Seem that bus error at this line https://github.com/zlib-ng/zlib-ng/blob/ce01b1e41da298334f8214389cc9369540a7560f/arch/arm/adler32_neon.c#L51

Seem that bus error at this line
https://github.com/zlib-ng/zlib-ng/blob/ce01b1e41da298334f8214389cc9369540a7560f/arch/arm/adler32_neon.c#L51

But if we don't use <arm_neon>'s vld1q_u8_x4 vld1q_u16_x4
but the fallback https://github.com/zlib-ng/zlib-ng/blob/ce01b1e41da298334f8214389cc9369540a7560f/fallback_builtins.h#L111
https://github.com/zlib-ng/zlib-ng/blob/ce01b1e41da298334f8214389cc9369540a7560f/fallback_builtins.h#L102
program will pass

Maybe we should not use these builtin functions althouth <arm_neon> have it but override them?

But fact is that my device does support LD4
I tried a small test
#include <alloca.h>
#include <arm_neon.h>
int main()
{
size_t len = 64;
void* buffer = alloca(len);
uint32_t pair[2];
vld1q_u16_x4(buffer);
return 0;
}
programs trigger bus error randomly
Seems vld1q_u16_x4 usage have some alignment requirement and our zlib-ng just not satisfy it

And call vld1q_u16 respectively doesn't have such requirement :
#include <alloca.h>
#include <arm_neon.h>
static inline uint16x8x4_t vld1q_u16_x4__(uint16_t *a) {
uint16x8x4_t ret = (uint16x8x4_t) {{
vld1q_u16(a),
vld1q_u16(a+8),
vld1q_u16(a+16),
vld1q_u16(a+24)}};
return ret;
}
int main()
{
size_t len = 64;
void* buffer = alloca(len);
uint32_t pair[2];
vld1q_u16_x4__(buffer);
return 0;
}
program never fails

@KungFuJesus Any idea?

There's no obvious bug here that would trigger this. The loads themselves are of the natural type for a byte and the spills are generated by the compiler.
The only thing I can think of is the 4x load rather than 4 separate discrete loads. I'm fairly certain there's no alignment requirement for that in the arm abi to begin with, but maybe?

Feel like it just because 4x load have alignment requirement (at least on my environment)

If the alignment is required by Android ABI, maybe we need specific workaround for combination of Android and Clang... I know we have had workarounds for Clang before.

It's unclear if it's a requirement of the Android ABI, the aarch32 ABI, or both.  I can't find any such documentation specifying the need for alignment for a 4x load.  The load in the loop most of the time actually is aligned, except for the case that doing scalar sums to get to alignment would bypass the vectorized function entirely.  Certainly the example with 8k bytes here, this is the case and he's still seeing a crash with it?
If we can find out what is requiring this we can probably surmise a combination in the preprocessor to make these conditions compile to the fallback.  This isn't the only place the 4x wide load is used, though.  It's used in slidehash as well, where we always have guaranteed 16 byte alignment.

It really shouldn't require alignment for a 4x load. It really seems like a compiler bug. Does gcc actually generate the 4x load or does it not have the intrinsic and just use the fallback?

gcc doesn't have such a 4x load intrinsic, just use the fallback

I mean...https://www.google.com/search?q="vld1q_u8_x4"+sigbus&sxsrf=ALiCzsY7uWuymeHoWL1eJw17w-Zspvnq-w%3A1663077828766&ei=xI0gY_6ZLoyp5NoP7M-4SA&ved=0ahUKEwj-i97Z95H6AhWMFFkFHewnDgkQ4dUDCA4&uact=5&oq="vld1q_u8_x4"+sigbus&gs_lcp=Cgdnd3Mtd2l6EAMyCAgAEKIEELADMggIABCiBBCwAzIICAAQogQQsAMyCAgAEKIEELADMggIABCiBBCwA0oECEEYAUoECEYYAFAAWABgogZoAnAAeACAAQCIAQCSAQCYAQDIAQXAAQE&sclient=gws-wiz
0 results.  Are we literally the only people to have seen this?  Something doesn't seem quite right, here.  This crash is on actual hardware and not with a qemu target?

It's unclear if it's a requirement of the Android ABI, the aarch32 ABI, or both. I can't find any such documentation specifying the need for alignment for a 4x load. The load in the loop most of the time actually is aligned, except for the case that doing scalar sums to get to alignment would bypass the vectorized function entirely. Certainly the example with 8k bytes here, this is the case and he's still seeing a crash with it?

As far as I know, only 32-bit Android ABI used both gcc and clang and this is clearly issue with Android ABI versions that already used Clang. The stricter alignment requirement was clearly for backwards compatibility and doesn't make much sense to keep it for 64-bit binaries as the shift from 32-bit to 64-bit addressing model already require rewrite of the ABI.

And vld1qx? for armv7 is supported in clang since https://github.com/llvm/llvm-project/commit/9c40c0ad0ca49a0b4eff20bf85b088daecb0014f

@KungFuJesus I suspect it is combination of using specific Android ABI version as a target for clang and complexity of code. When we confirm the exact line where the alignment exception happens, we need to force compiler to align all variables used in that line. Using the current fallback might be the last solution, as we don't know (yet) if splitting the x4 load to two x2 loads avoids the exception...
I've seen similar issue with 32-bit PowerPC processors using vector instructions.

I feel like this should be a bug filed with NDK.  Why does Google think it can assume any alignment here, let alone 256 bit alignment at this address?  Do newer versions of the NDK distribute newer versions of clang that maybe have this feature removed?

Google has pretty much killed most of Android development in C or C++ with the change to Clang and custom C library... Only applications that are still released are either written in Java or JavaScript.
Although we could blame Google and ask affected zlib-ng users to file another bug report against Android NDK, I'm pessimistic about them fixing anything for the 32-bit ABI.

@asuka-mio could carry a custom patch that forces this to 4x discretized loads I guess, but it seems awfully silly.  The register spills on aarch32 also bothers me a bit.  @dougallj has a better adler32 implementation (leveraging a more direct widening fused multiply add) that myself or him could drop in at any time, but I don't think that really would help all that much with the register pressure situation.  I'm also not entirely sure that instruction exists in armv7.

@asuka-mio could carry a custom patch that forces this to 4x discretized loads I guess, but it seems awfully silly. The register spills on aarch32 also bothers me a bit. @dougallj has a better adler32 implementation (leveraging a more direct widening fused multiply add) that myself or him could drop in at any time, but I don't think that really would help all that much with the register pressure situation. I'm also not entirely sure that instruction exists in armv7.

It's up to us to decide if it's worth adding workaround in the official zlib-ng sources or downstream the patch to third-party port... I usually tag people I think should participate in the discussion and anyone is free to tag more people even if our guidelines say those people have no vote in final decisions because they are not long-time contributors.

I mentioned an NDK bug in this - maybe that will draw some attention from Google NDK people?  I certainly suggest filing an issue on the NDK github repo, this is definitely clang doing something it shouldn't.  I tagged dougallj mostly to properly credit the better adler32 implementation, however he does have some ARM expertise so his input / speculation here could be valuable.

Reminds me of all the issues we have had with Microsoft breaking things... We actually managed to get them fix some of their issues, which is quite an achievement for a project of this size.

@dougallj has a better adler32 implementation (leveraging a more direct widening fused multiply add) that myself or him could drop in at any time, but I don't think that really would help all that much with the register pressure situation. I'm also not entirely sure that instruction exists in armv7.

Yeah, unfortunately my implementation isn't a drop-in replacement, as it requires FEAT_DotProd (which is available in 32-bit code, but not prior to ARMv8.2, optional in 8.2/8.3 and present in ARMv8.4 onwards). If there is a register pressure issue, then I'd imagine switching to a narrower implementation would improve performance.
I don't have much experience with 32-bit ARM, but I agree that the 256-bit alignment looks like a compiler bug (given the intrinsic takes an argument with 8-bit alignment): https://godbolt.org/z/MGq48jcqx

I usually tag people I think should participate in the discussion and anyone is free to tag more people even if our guidelines say those people have no vote in final decisions because they are not long-time contributors.

I'm not looking for a vote, just trying to help out :)

If it's anything like the VNNI implementation was, there was room to overlap 2 running sums.  This version is tracking many more sums to try to maximize overlap but I imagine a version that widens at the same time as the dot prod will probably require much fewer in flight registers.
As far as detecting if available, I'm sure we can make that work with the standard function table + runtime detection, keeping this one for CPUs that lack that capability.

Yeah, I imagine we could make something work.
It looks like A32 has 16 128-bit registers (half as many as A64). My current code uses 16 registers for the accumulators and multipliers/taps – so there aren't registers left over for the data:
        uint8x16x4_t mul = vld1q_u8_x4(MULTIPLIERS);
        uint32x4_t accs[4] = { 0 };
        uint32x4_t sums[4] = { 0 };
        uint32x4_t extras[4] = { 0 };

So I'd change it to avoid spilling if 32-bit ARM is an important target. (On M1 keeping those separate maximises throughput by having separate latency chains, but that's unlikely to make a difference on the 32-bit targets I'm aware of.)

We have google benchmarks that time various buffer lengths through the adler functions.  It's easy to wire up a new implementation to it and we could test it on a variety of Cortex implementations.  It seems likely that breaking data dependency chains is beneficial - that was certainly the case for PowerPC (good lord I had to unroll a lot wider than the max vector with on a G5) and x86.  I imagine with big.LITTLE, the little architectures might need the unrolling to get max throughput.

I'm not looking for a vote, just trying to help out :)

I know... I have been contributor to this project since when the only optimizations were for x86... I started with PowerPC and ARM optimizations while I was still studying the instruction sets, so my knowledge was limited... My primary goal was to add enough code to attract more developers who are more familiar with the different instruction sets.

This breaks support for Raspberry Pi v3b as well.


Javascript "for of" bug with "FormData"

Compiling the following JavaScript code goes really wrong as it doesn't understand what for (var pair of formdata.entries()) is, even in "Remove whitespace" mode:
var formdata = new FormData();

for (var pair of formdata.entries())
{
	console.log(pair[0], pair[1]);
}

It really messes up the code and causes JS errors that crash the code and produces this bug ridden monstrosity for "Whitespace":
var formdata=new FormData;for(var $jscomp$iter$0=$jscomp.makeIterator(formdata.entries()),$jscomp$key$pair=$jscomp$iter$0.next();!$jscomp$key$pair.done;$jscomp$key$pair=$jscomp$iter$0.next()){var pair=$jscomp$key$pair.value;{console.log(pair[0],pair[1])}};
And even worse for "Simple":
var $jscomp=$jscomp||{};$jscomp.scope={};$jscomp.arrayIteratorImpl=function(a){var b=0;return function(){return b<a.length?{done:!1,value:a[b++]}:{done:!0}}};$jscomp.arrayIterator=function(a){return{next:$jscomp.arrayIteratorImpl(a)}};$jscomp.makeIterator=function(a){var b="undefined"!=typeof Symbol&&Symbol.iterator&&a[Symbol.iterator];return b?b.call(a):$jscomp.arrayIterator(a)};
for(var formdata=new FormData,$jscomp$iter$0=$jscomp.makeIterator(formdata.entries()),$jscomp$key$pair=$jscomp$iter$0.next();!$jscomp$key$pair.done;$jscomp$key$pair=$jscomp$iter$0.next()){var pair=$jscomp$key$pair.value;console.log(pair[0],pair[1])};

"Advanced" was also buggy
function a(){var d=b,e=0;return function(){return e<d.length?{done:!1,value:d[e++]}:{done:!0}}}var c,b=(new FormData).entries(),f="undefined"!=typeof Symbol&&Symbol.iterator&&b[Symbol.iterator];c=f?f.call(b):{next:a()};for(var g=c.next();!g.done;g=c.next()){var h=g.value;console.log(h[0],h[1])};
It should return "Whitespace" as:
var formdata=new FormData;for(var pair of formdata.entries()){console.log(pair[0], pair[1])}

"Whitespace" mode output crashing is a known issue: see https://github.com/google/closure-compiler/issues/2007 and https://github.com/google/closure-compiler/issues/3637. Passing --language_out=NO_TRANSPILE should fix this.
For "simple" and "advanced" modes, you may also disable for-of loop transpilation with --language_out=NO_TRANSPILE or any other language mode documented in https://github.com/google/closure-compiler/issues/3637. The compiler defaults are set to transpile ES2015+ features like for-of down to ES5.
The transpiled output looks correct to me though. Did you find a bug in the output (i.e. the output code behaves differently than the input)?

Yes, the output code crashed, something about $jscomp, I can't remember exactly.

Sorry, I meant just the Whitespace code crashed.

I see, in that case I'll close this bug as a duplicate of https://github.com/google/closure-compiler/issues/2007. Please file a new issue if you run into issues with "simple"/"advanced" mode.

The whitespace issue seems to be a duplciate of #2007 (where the default transpilation generates references to transpilation helper code that is not included).  The workaround is to run with --language_out=NO_TRANSPILE or --language_out=ECMASCRIPT_NEXT.  In fact, we might consider changing the default language out to one of those, as it may be a bit surprising that the default behavior is to transpile down to ES5.
@jplevene. was there a separate issue with SIMPLE/ADVANCED? The output code appears to execute correctly in those modes...


Crash on latest Node LTS (22)

When upgrading the dockerfile below from node 20 to node 22, chopsticks crashes.
(node:1) [UNDICI-WS] Warning: WebSockets are experimental, expect them to change at any time.
(Use `node --trace-warnings ...` to show where the warning was created)
node:internal/event_target:1090
  process.nextTick(() => { throw err; });
                           ^

TypeError: Cannot read properties of null (reading 'length')
    at WebSocket.__internal__onSocketMessage (/root/.bun/install/global/node_modules/@polkadot/rpc-provider/cjs/ws/index.js:402:40)
    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:816:20)
    at WebSocket.dispatchEvent (node:internal/event_target:751:26)
    at fireEvent (node:internal/deps/undici/undici:10966:14)
    at websocketMessageReceived (node:internal/deps/undici/undici:10988:7)
    at ByteParser.run (node:internal/deps/undici/undici:11439:17)
    at ByteParser._write (node:internal/deps/undici/undici:11315:14)
    at writeOrBuffer (node:internal/streams/writable:564:12)
    at _write (node:internal/streams/writable:493:10)
    at Writable.write (node:internal/streams/writable:502:10)

Node.js v22.2.0

Repro
Dockerfile
FROM imbios/bun-node:latest-22-alpine

ENV CONFIG_FILE=westend-people.yml

# Install Chopsticks globally
RUN bun install -g<EMAIL_ADDRESS>
# Install curl for healthcheck
RUN apk add --no-cache curl

# Set the working directory in the container
WORKDIR /app

# Copy all potential yaml configs
COPY *.yml ./
COPY *.wasm ./

# Expose port 8000 for health check
EXPOSE 8000

# Update healthcheck to use the configurable port
HEALTHCHECK --interval=10s --timeout=10s --start-period=60s --retries=6 \
  CMD curl -v http://localhost:8000 || exit 1

# Command to run Chopsticks with configurable yaml file and port
CMD chopsticks -c "$CONFIG_FILE"

westend-people.yml
endpoint:
  - wss://westend-people-rpc.polkadot.io
mock-signature-host: true
block: 2956970

please upgrade to 22.3.0 https://github.com/polkadot-js/api/issues/5880#issuecomment-2234987120


Triaging AzDevifiable Azure Samples

@rajeshkamal5050 What are the AzDevifiable Azure Samples? What do we need to do?
Could you provide more information about this issue? Thanks a lot.

Working on it.


Tomcat ssl

Added the https connector for Tomcat and a settings class for custom Tomcat settings

Thanks!


refactor(config): Consistently use kebab-case

This shouldn't change the behavior but makes it safer if

We add new fields where it will matter
Copy/paste these for new structs

I did not change things related to the Index because we are already stuck with that case (whether we want it or not)
Came across this when working on #13540 and almost made the mistake of copying what was already there

The third time we hit this failure?

---- death::kill_cargo_add_never_corrupts_cargo_toml stdout ----
thread 'death::kill_cargo_add_never_corrupts_cargo_toml' panicked at crates\cargo-test-support\src\paths.rs:150:17:
failed to remove "D:\\a\\cargo\\cargo\\target\\tmp\\cit\\t1104\\foo": Os { code: 32, kind: Uncategorized, message: "The process cannot access the file because it is being used by another process." }

kill_cargo_add_never_corrupts_cargo_toml failed also in #13738 and #13740

@bors r+

:pushpin: Commit bb46cce3635f927bf893ac8d7c56b8844cb56fb2 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit bb46cce3635f927bf893ac8d7c56b8844cb56fb2 with merge 8dd6db4f120e7e84d4efc97d63d244e6dc8f3be4...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing 8dd6db4f120e7e84d4efc97d63d244e6dc8f3be4 to master...


when declaring participants the elements are generated twice

from the documentation
sequenceDiagram
    participant John
    participant Alice
    Alice->>John: Hello John, how are you?
    John-->>Alice: Great!

using the live editor this is rendered correctly, but using the CLI i get this

C:\windows\system32\cmd.exe /c (mermaid tmp\test.txt -o C:\RC\tmp)
Num files to execute : 1
ready to execute png: test.txt.png
CONSOLE: [10:13:11 (182)]  Starting rendering diagrams (from line # in "")
CONSOLE: [10:13:11 (182)]  Start On Load before: undefined (from line # in "")
CONSOLE: [10:13:11 (182)]  Initializing mermaidAPI (from line # in "")
CONSOLE: [10:13:11 (182)]  Setting conf  gantt - useWidth (from line # in "")
CONSOLE: [10:13:11 (182)]  Setting config: gantt useWidth to 1200 (from line # in "")
CONSOLE: [10:13:11 (187)]  Adding message from=Alice to=John message=Hello John, how are you? type=0 (from line # in "")
CONSOLE: [10:13:11 (187)]  Adding message from=John to=Alice message=Great! type=1 (from line # in "")
CONSOLE: [10:13:11 (196)]  For line height fix Querying: #mermaidChart0 .actor-line (from line # in "")
saved png: test.txt.png
Hit any key to close this window...

Has anyone figured out what is causing this issue?
I have a very similar issue with IE 11 where the SVG markup is repeated twice, but it works correctly with Chrome and Firefox.

Make sure you don't have white space after the John's participant declaration. They should chop off the white space when registering it, but they don't. So when you create the edge from John, "John " is registered but not "John", so it registers a new one at the end.

there is no whitespace after either participant declaration, so this is not it.

I have the same problem.
Also since I want to activate one off the participants from the beginning, this is leading to issues (since I cannot activate a participant that is not yet created.)
Would be nice if anyone can find what is causing this.

Generated SVG is
<g>     <line id="actor0" x1="75" y1="5" x2="75" y2="531" class="actor-line" stroke-width="0.5px" stroke="#999" />     <rect x="0" y="0" fill="#eaeaea" stroke="#666" width="150" height="65" rx="3" ry="3" class="actor" />     <text x="75" y="32.5" dominant-baseline="central" alignment-baseline="central" class="actor" style="text-anchor: middle;">         <tspan x="75" dy="0">Example Participant         </tspan>     </text> </g>
So it looks like it is a line-feed problem. Switching my input file from
CRLF -> LF
fixed the issue, and I tried to write a quick string.replace fix, but can't get that to work

Try the latest CLI program: https://github.com/mermaidjs/mermaid.cli
Feel free to reopen if you still have this issue.


New pybel breaks indra dependencies in  BEL to Natural Language

The latest version of pybel breaks indra dependencies in  the BEL to Natural Language notebook
pybel.get_version()

'0.14.11-dev'
indra.util.get_version.get_version()

'1.17.0-c8f35a6f7a00e8a6116b707b6a034f57a72f22ae'
pbp = process_pybel_graph(sialic_acid_graph)
pbp.statements

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-17-2420ef54593c> in <module>
----> 1 pbp = process_pybel_graph(sialic_acid_graph)
      2 pbp.statements

~/Projects/Proposals/MARS/Pathogenesis/indra/indra/sources/bel/api.py in process_pybel_graph(graph)
    150     """
    151     bp = PybelProcessor(graph)
--> 152     bp.get_statements()
    153     if bp.annot_manager.failures:
    154         logger.warning('missing %d annotation pairs',

~/Projects/Proposals/MARS/Pathogenesis/indra/indra/sources/bel/processor.py in get_statements(self)
     90             for node_ix, node in enumerate((u_data, v_data)):
     91                 if isinstance(node, dsl.ComplexAbundance):
---> 92                     self._get_enum_complex(u_data, v_data, k, d, node_ix)
     93             subj_activity = _get_activity_condition(d.get(pc.SUBJECT))
     94             obj_activity = _get_activity_condition(d.get(pc.OBJECT))

~/Projects/Proposals/MARS/Pathogenesis/indra/indra/sources/bel/processor.py in _get_enum_complex(self, u_data, v_data, k, edge_data, node_ix)
    187         cplx_agent.bound_conditions = []
    188         agents.append(cplx_agent)
--> 189         ev = self._get_evidence(u_data, v_data, k, edge_data)
    190         stmt = Complex(agents, evidence=[ev])
    191         self.statements.append(stmt)

~/Projects/Proposals/MARS/Pathogenesis/indra/indra/sources/bel/processor.py in _get_evidence(self, u_data, v_data, k, edge_data)
    327         ev_pmid = None
    328         if ev_citation:
--> 329             cit_type = ev_citation[pc.CITATION_DB]
    330             cit_ref = ev_citation[pc.CITATION_IDENTIFIER]
    331             if cit_type == pc.CITATION_TYPES[pc.CITATION_TYPE_PUBMED]:

AttributeError: module 'pybel.constants' has no attribute 'CITATION_DB'

I left a pull request on INDRA to handle the location change of citation_dict which was previously causing an ImportError  on this line in BEL to Natural Language:
from indra.sources.bel.api import process_pybel_graph

It's too bad that the notebooks can't be on continuous integration, or you probably would have caught this bug.

Hi @djinnome, I'd suggest you stay on stable versions of PyBEL that are released on PyPI. I can't support users on the development version, especially right now as v0.15.0 will have some breaking changes (as you've found)


add a function to splice a single drv

And with some changes it should be able to splice a set
Just a test to see it's possible and if adding the origF and untouchedArgs will hurt the performance a lot
Would be useful for splicing attributes that aren't reachable from pkgs
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

iirc ofborg hardly exercises the cross compilation code paths

iirc ofborg hardly exercises the cross compilation code paths

Yeah but there's no change in that because the function isn't used yet
I was concerned about the lib/customisation changes but the perf impact looks neglible

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/frustrations-about-splicing/49607/7


Use lazydocs instead of mkdocs

Added lazydocs and pydocstyle to poetry
Added documentation as docstrings
Deleted generated mkdocs files
Added docs folder to ignored files

Fixes #14 #16

Example how the documentation should be written


Adding retriever for AzureCosmosDB Vector Search

This PR adds the retriever functionality for the Azure Cosmos DB Mongo vCore Vector Search.
https://learn.microsoft.com/en-us/azure/cosmos-db/mongodb/vcore/
https://learn.microsoft.com/en-us/azure/cosmos-db/mongodb/vcore/vector-search
Summary:

Description: Adding a retriever for the AzureCosmosDB Mongo vCore Vector Search
Tag maintainer: @hwchase17

@hwchase17 can you please review and approve this PR?

@baskaryan can you please help merge this PR?

Ping on this thread, @baskaryan or @hwchase17 , can you please help review/merge this PR?

Added a new PR with more enchancements, including this one as well.
https://github.com/langchain-ai/langchain/pull/16856


[Bug]: Jarvide responds to its own message/any other bot's messages

Contact Details
No response
What happened?
A bug happened!
I ran the command jarvide roast @jarvide
so when it sends the embed, it mentions itself, which triggers the jarvide welcome embed
I also tried to get a bot to ping jarvide, and it responded.
Version
Latest
Relevant log output
No response
Code of Conduct

[ ] I agree to follow this project's Code of Conduct & Terms of service

I'm pretty sure this is fixed already here


Reduce the impact of MimeDB on JS size

We are testing http4s for our scala.js browser app and it seems to produce a fairly big increase on the scala.js produced by scala.js. One of the contributors is the very large MimeDB which maybe not needed on the typical frontend app
Should we split MimeDB into jvm and js versions, with the latter having a minimal or empty set of mime types?

If I'm reading this right, it takes ~3 seconds to even parse the output of fastOptJS:

Which makes it sort of unusable for development, as both the re-linking and reloading in the browser take a long time
Vanilla app can be dropped down to 2.5MB with fullOptJS, but it has zero to none http4s logic. But fastOptJS produces a 14MB on an app that has very little apart from http4s itself

Yeah, thanks for this.
So, yeah, time to fix this.

I've PRed a fix upstream in https://github.com/http4s/http4s/pull/6211.


Add mouseMoveEvent, enterEvent and leaveEvent

Depends on https://github.com/kusti8/node-qt-napi/pull/2

Sorry for the wait. Thanks!


Fix Role Validation deployment.toml configuration

$Subject

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/2594795552

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/2594795552
Status: failure

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/2621201661

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/2622274348

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/2623258833

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/2623258833
Status: failure

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/2626921727

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/2626921727
Status: failure

Tests got passed now https://github.com/wso2/product-is/actions/runs/2626921727 eventhough it is shown as failure. Hence merging


Only one url for ddi schema reference is too restrictive (Feedback PROGEDO)

Original report on BitBucket by Taina Jääskeläinen.

From Genevieve Michaud:
I have a small issue with CMV, regarding the very first line of any Document I upload, It pops up an error related to an addtionnal s (https in place of http) in the following string ('ddi:codebook:2_5 https://ddialliance.org/Specification/DDI-Codebook/2.5/XMLSchema/codebook.xsd' is not equal to fixed value 'ddi:codebook:2_5 http://www.ddialliance.org/Specification/DDI-Codebook/2.5/XMLSchema/codebook.xsd' in '/codeBook/@xsi:schemaLocation' (lineNumber: 1). Could this constraint be lowered as a warning? What do you think?
Just copying her comment.

This is a profile issue


Avoid deleting files only on exit in some places

Please have a look at the individual commit messages for the details.

I'll rework this / split into other PRs.


message not sending and cant see them

same as #236

Pls read the previous issues before creating new ones.


add activity stream to task #693

add activity stream to task #693

Merged and modified to avoid some code duplication and fix php 5.3 compatibility (don't use [ and ] for arrays).


Adds analysis for Manticore tool

This PR is dependent on: https://github.com/hashgraph/hedera-json-rpc-relay/pull/2452

Closing in favour of https://github.com/hashgraph/hedera-smart-contracts/pull/729


Added pagination controls to List and Card views.

Description
Added pagination controls to List and Card Views.  Updated List, Card, and Toolbar ngDoc examples to show pagination controls.

Updated ngDoc for List View,  added Pagination Tab, added @param for pageConfig
Updated ngDoc for Card View, added '[ ] Show Pagination' checkbox, added @param for pageConfig
Updated ngDoc for Toolbar

added '[ ] Show Pagination' checkbox.
Pagination controls 'sticky' across switching between List, Card, and Table views
Tested pagination controls across views: setting/clearing filters, selecting items, sorting, changing pageSize, inputing page number, toggling emptystate on/off

Here is the ngDoc examples.
List View ngDoc example:

Card View ngDoc example:

Toolbar ngDoc example:

https://patternfly.atlassian.net/browse/OSUX-118
https://patternfly.atlassian.net/browse/OSUX-119
PR Checklist

[X] Unit tests are included
[X] Screenshots are attached (if there are visual changes in the UI)
[X] A Designer (@beanh66) is assigned as a reviewer (if there are visual changes in the UI)
[X] A CSS rep (@cshinn) is assigned as a reviewer (if there are visual changes in the UI)

Thanks @cdcabrera for the review.  I fixed those issues.  BTW, how did you get that list?  I don't see anything from eslint?

@dtaylor113 Webstorm and code highlighting on those... linter probably missed them because most of them are in comments

Hi, is this ready to be merged?

@cdcabrera Any further comments/issues?


Allow multiple/sectioned bibliographies

The idea of allowing for a bibliography that can be broken down into headings has come up on pandoc-discuss a couple of times (there is a very good thread on it from 2010, and I asked about it in August); it would be extremely useful for the many situations that require lists of resources on a number of topics (see e.g. a course site I made up), annotated bibliographies, or publications that ask items in a bibliography to be categorized in some way (e.g. many historical publications distinguish between primary sources and secondary works).
I hope it's not presumptuous of me to put in a request for this; there are some references to a bibsection capability in https://github.com/jgm/pandoc-citeproc/blob/master/tests/test-citeproc.hs#L34, but I assume these could be removed if there is no intent to implement this. A simpler alternative would be to implement something that works in reverse to the nocite option, omitting the specified items from the reference list, which would at least make it easier to deal with two bibliographies in a paper.

Finally got around to finishing pandoc-multibib. I haven't really tested it yet, but should work OK. You need to make a 'complete' bibliography, and then a number of files with the items you'd like to appear in each section. If something appears in the complete bibliography file but not in one of the sectional bibliographies, then it will still be referenced in-text but won't appear in the final reference list.

It would also be great to section bibliographies, because when there is more than 3 or 4 references, they can not fit in a single slide (beamer / revealjs / whatever)

@dfaligertwood Did this ever get merged in?

@sid-kap It's not a patch for pandoc itself, so wouldn't be included - it's a seperate filter. See the repo linked above. Not sure if it still compiles though - I'll just check for you.

I'm trying to use it, but cannot get it to compile. I know nothing about Haskell, so I struggle a little. If you can make the required changes so that it compiles, I can test it. Thanks!

By the way, is it possible to use \nocite in some way with this filter?

Sorry to bring this up again, but has this been addressed?
It seems like a very common use case and a real blocker for writing papers in md (at least for me).
I believe the hacky scripts were meant to be a temporary workaround until this is supported by citerproc.
If there is a better way to achieve this please let me know. Thanks!

The workaround I use is a LateX file that I use in addition to the md document. It is sufficient for a CV, in which you have to separate journals, conferences, workshops, etc.

is it still possible to use citerproc in that case?
can you provide an example?
Thanks a lot!

I mean I produce the regular document with pandoc, and the bibliography part separately, then merge PDFs. This means I cannot cite the refs in the document. This is the (strong) limitation of this method.

The whole point is to be able to use pandoc support for citing, otherwise I'd rather use latex commands directly in my md file to have biblatex do what I want.
I assume that this is possible, still the syntax would be ugly, which kinda destroys the purpose of not writing this in latex in the first place...
Thanks anyways, hope this gets some attention in the near future.

I think the general approach pandoc-multibib takes is actually a pretty reasonable one, and it seems perfectly reasonable for this special case to be handled using another filter (applied after pandoc-citeproc in the filter chain).  I have not tried pandoc-multibib myself.  If there are problems compiling it, perhaps it needs some updating, or to make it easier for everyone, rewriting as a lua filter.
For reference, here's an example of how pandoc-multibib works.  You specify multiple bibliographies, together with their titles, in addition to a main bibliography.
---
bibliographies:
  - test1.json: First Bibliography
  - test2.json: Second Bibliography
bibliography: test.json
---

[@Shepherd_1961_i3] [@Square_1884_i5]

Presumably the main bibliography would just be the concatenation of the subsidiary ones.
If this functionality were to be included in pandoc-citeproc, it could work in a similar way, but a little more conventently:  if there's no bibliography field in metadata, look for bibliographies and read them all, keeping track of the sources of each item, then use this information at the end to sort the bibliography into sections.
Another approach would be to use the note field of bibliography items to specify the section; then only one bibliography would be needed.  A special convention would have to be adopted, e.g. if note is section=Foo, then the item goes in the section titled Foo.

I agree, both suggestions sound pretty solid.
The before mentioned scripts are pretty old too. As I have no experience with Haskell, I couldn't get them to compile and wasted several hours on this (tried cabal and stack, but always ran into dependency issues).
whenever the solution is to rewrite the scripts or add it to citeproc, I would definitely appreciate some statically compiled binaries of the scripts, so people can use it now.
I just want to write my paper with markdown and be done with it 😭
Thanks!

pandoc-multibib compiles fine for me.
Steps:

clone pandoc-citeproc
get the Haskell 'stack' tool
in the pandoc-citeproc directory, do 'stack install'
then put the pandoc-multibib.hs source in this directory
do stack ghc -- --make pandoc-multibib.hs

You should have pandoc-multibib executable.

I did something similar with a pandoc -> latex+biber -> pdf workflow, using a customised template for the job. Maybe implementing this feature for a pandoc+pandoc-citeproc -> anything workflow could be done in a similar manner.
I specify rules for splitting the bibliography in the metadata block as such:
---
splitbib:
    - title: Primary Sources
      rule:  keyword=primary
    - title: Secondary Sources
      rule:  notkeyword=primary
---

These rules are then handled by the following code in a latex template:
$if(bibliography)$
  $if(biblio-title)$\renewcommand{\bibname}{$biblio-title$}$endif$
  $if(splitbib)$
    \chapter{\bibname}
    $for(splitbib)$
    \section{$splitbib.title$}
    \printbibliography[heading=none,$splitbib.rule$]

    $endfor$
  $else$
    \chapter{\bibname}
    \printbibliography[heading=none]
  $endif$
$endif$

I believe that specifying rules explicitly in metadata is far more flexible than relying only on information contained in bibliography files (as do both approaches discussed so far), since it allows handling the same bibliography differently in different documents.

I've just updated the cabal file for pandoc-multibib, so it should at least now compile without too much fuss. I'm not in academia any more (unless anyone knows of a funded PhD going spare), so I have no particular need for it, but I have free time atm so may do some more work to implement the suggestions of embedded bibliographies and/or auto-concatenation.
I'm not sure how everyone else manages their citation DBs, but w.r.t. pandoc-multibib I used to keep everything in one 'global' zotero DB and then use a json filter to split out primary/secondary sources, hence the architecture.
Just for clarity, pandoc-multibib actually acts as a wrapper around pandoc-citeproc. This does result in some slightly confusing behaviour - specifically, items will not be in the bibliography unless they are cited in the text (or in the nocite key)
Shiro, just for reference - in future if you have issues compiling, just raise an issue on my repo or at me directly?

Oh, I just learned about pandoc-multibib – very cool!
There is now also the multiple-bibliographies Lua filter, which I probably wouldn't have written if I had known about pandoc-multibib back then.

Ah, nice! I think you've used the same method I did, and being lua it doesn't require compilation so is probably the best option for non-techie users.


Support testcode.

[x] Tests added
[x] Passes isort . && black . && flake8
[x] User visible changes (including notable bug fixes) are documented in changelog.rst
[x] New features are documented in the docs

To support testcode, testsetup and testcleanup, I send this PR. c.f. https://www.sphinx-doc.org/en/master/usage/extensions/doctest.html

@keewis Thank you for reviewing! I applied your suggestions.

Sorry, :rst:directive: seems not to work well. Do you have any ideas?

my bad, while rst:directive is the directive, for cross-referencing you need :rst:dir: (see https://www.sphinx-doc.org/en/master/usage/restructuredtext/domains.html#the-restructuredtext-domain)

thanks, @keisuke-umezawa

@keewis Thank you for your help. I will use the latest version.


[tflite] add int8 input/output to label_image

More and more models, such as MobilenetV3's EdgeTPU ones, are using post-training full integer quantization. With this patch, I can get reasonable results.
./label_image_int8 -m mobilenet_edgetpu_224_1.0_int8.tflite
Loaded model mobilenet_edgetpu_224_1.0_int8.tflite
resolved reporter
INFO: Initialized TensorFlow Lite runtime.
invoked
average time: 15.363 ms
0.867188: 653 military uniform
0.0390625: 835 suit
0.015625: 458 bow tie
0.0078125: 907 Windsor tie
0.00390625: 716 pickelhaube

@srjoglekar246 Can you please take a look on this PR? Thanks!

Here are internal failures , can you please check
`In file included from ./third_party/tensorflow/lite/examples/label_image/get_top_n.h:19:
./third_party/tensorflow/lite/examples/label_image/get_top_n_impl.h:33:16: error: unknown type name 'TfLiteType'
TfLiteType input_type) {
^
./third_party/tensorflow/lite/examples/label_image/get_top_n.h:27:16: error: unknown type name 'TfLiteType'
TfLiteType input_type);
^
./third_party/tensorflow/lite/examples/label_image/get_top_n.h:31:69: error: unknown type name 'TfLiteType'
std::vector>, TfLiteType);
^
./third_party/tensorflow/lite/examples/label_image/get_top_n.h:30:15: error: explicit instantiation of 'get_top_n' does not refer to a function template, variable template, member function, member class, or static data member
template void get_top_n(float, int, size_t, float,
^
./third_party/tensorflow/lite/examples/label_image/get_top_n.h:34:33: error: unknown type name 'TfLiteType'
TfLiteType);
^
./third_party/tensorflow/lite/examples/label_image/get_top_n.h:32:15: error: explicit instantiation of 'get_top_n' does not refer to a function template, variable template, member function, member class, or static data member
template void get_top_n(int8_t*, int, size_t, float,
^
./third_party/tensorflow/lite/examples/label_image/get_top_n.h:37:34: error: unknown type name 'TfLiteType'
TfLiteType);
^
./third_party/tensorflow/lite/examples/label_image/get_top_n.h:35:15: error: explicit instantiation of 'get_top_n' does not refer to a function template, variable template, member function, member class, or static data member
template void get_top_n(uint8_t*, int, size_t, float,
^
In file included from ./third_party/tensorflow/lite/examples/label_image/get_top_n.h:19:
./third_party/tensorflow/lite/examples/label_image/get_top_n_impl.h:44:12: error: use of undeclared identifier 'kTfLiteFloat32'
case kTfLiteFloat32:
^
./third_party/tensorflow/lite/examples/label_image/get_top_n_impl.h:47:12: error: use of undeclared identifier 'kTfLiteInt8'
case kTfLiteInt8:
^
./third_party/tensorflow/lite/examples/label_image/get_top_n_impl.h:50:12: error: use of undeclared identifier 'kTfLiteUInt8'
case kTfLiteUInt8:
^
11 errors generated.
./third_party/tensorflow/lite/examples/label_image/get_top_n_impl.h:33:16: error: unknown type name 'TfLiteType'
TfLiteType input_type) {
^
./third_party/tensorflow/lite/examples/label_image/get_top_n_impl.h:44:12: error: use of undeclared identifier 'kTfLiteFloat32'
case kTfLiteFloat32:
^
./third_party/tensorflow/lite/examples/label_image/get_top_n_impl.h:47:12: error: use of undeclared identifier 'kTfLiteInt8'
case kTfLiteInt8:
^
./third_party/tensorflow/lite/examples/label_image/get_top_n_impl.h:50:12: error: use of undeclared identifier 'kTfLiteUInt8'
case kTfLiteUInt8:`

I think we need to add a BUILD dependency on tensorflow/lite/c:common & import common.h for this to BUILD properly using bazel. @freedomtan can you take a look?

@srjoglekar246 I cannot reproduce what @rthadur said on my Mac (with either Python 2 or 3). I'll add the dependency you suggest later anyway.

@yifeif May I know the reason of rollback so that I can fix it?

Thanks for checking @freedomtan! It broke one of the internal address sanitizer test. @srjoglekar246, do you mind working with @freedomtan to get this change in again? Thank you :)


Fix casing in namespaces and files.

We agreed to move to use IoT (capital T) instead of Iot in .NET track2 for package names and namespaces.

What about the directory name? It is still sdk/modelsrepository/Azure.Iot.*

If you want to rename files, it can't just be on case alone. You'll otherwise need to rename it to something different (commit to master) and then do a second rename to IoT.

I made two separate commits and it seems to have done the trick.

What about the directory name? It is still sdk/modelsrepository/Azure.Iot.*

it should be fixed now.

I made two separate commits and it seems to have done the trick.

I'm not sure what is going to happen when you squash and it goes to master though, so keep an eye on it then.

I made two separate commits and it seems to have done the trick.

I'm not sure what is going to happen when you squash and it goes to master though, so keep an eye on it then.

Worked as expected.


Release version 2

It seems like the source in this repository is for a version 2 that has the walk_dir dependency removed. But that version has not been released to crates.io
This is an outdated dependency so its causing duplicates of walk_dir in my dep tree.
Releasing copy_dir version 2 would fix this.
Alternatively, given the inactivity, you might prefer to just mark the crate as unmaintained.

I am happy to take a look at updating the dependencies if the staleness is causing issues for some folks.

Would be much appreciated, thanks :)


Cleaned up the code and added some nice touches!

Replaced multiple style="font-size: 1em"s with a much cleaner looking style tag.
Added the welcome thing from my website
Added some rainbow text

On a completely unrelated note, you should enable GitHub Discussions so that people can discuss more about changes they would add to your website!

BETTER NOT RICKROLL!


[Documentation] Offline Install Instructions: Docker

These instructions are for setting up a persistent instance of the Homebrewery application locally using Docker.
If you intend to develop with Homebrewery, following the Homebrewery application section of this guide is not recommended. Using docker to deploy MongoDB locally for development is not a bad idea at all, however.
Install Docker
Desktop Client (MacOS/Windows)

Mac
Windows

You can set up the docker engine to start on boot via the Docker desktop UI.
Docker Engine

CentOS
Debian
Fedora
RHEL
SLES
Ubuntu

Manage Docker as a non-root user (highly recommended)
Enable Docker to start on boot (highly recommended)
Run Mongo
docker run --name homebrewery-mongodb -d --restart unless-stopped -v mongodata:/data/db -p 27017:27017 mongo:latest

If your distribution is running on an arm device such as a Raspberry Pi, you will need to run the arm-built MongoDB v4.4.
docker run --name homebrewery-mongodb -d --restart unless-stopped -v mongodata:/data/db -p 27017:27017 arm64v8/mongo:4.4

Run Homebrewery
Build Homebrewery Image
git clone https://github.com/naturalcrit/homebrewery.git
cd homebrewery
docker-compose build homebrewery

Set up Configuration
Create the following file at config/docker.json
{
  "host" : "localhost:8000",
  "naturalcrit_url" : "local.naturalcrit.com:8010",
  "secret" : "secret",
  "web_port" : 8000,
  "enable_v3" : true,
  "mongodb_uri": "mongodb://host.docker.internal/homebrewery"
}

Run the Container
# Make sure you run this in the homebrewery directory
docker run --name homebrewery-app -d --restart unless-stopped -e NODE_ENV=docker -v $(pwd)/config/docker.json:/usr/src/app/config/docker.json -p 8000:8000 docker.io/library/homebrewery:latest

Updating the App
Whenever Homebrewery pushes out an update and you want to update your version of the app to include the changes, follow these steps to update the app.
docker rm -f homebrewery-app
cd homebrewery
git pull
docker-compose build homebrewery
docker run --name homebrewery-app -d --restart unless-stopped -e NODE_ENV=docker -v $(pwd)/config/docker.json:/usr/src/app/config/docker.json -p 8000:8000 docker.io/library/homebrewery:latest

Set up Configuration
Create the following file at config/docker.json
{
"host" : "localhost:8000",
"naturalcrit_url" : "local.naturalcrit.com:8010",
"secret" : "secret",
"web_port" : 8000,
"enable_v3" : true,
"mongodb_uri": "mongodb://host.docker.internal/homebrewery"
}

Is there a reason not to include this content in a file inside the install/docker directory, and direct the user to copy it to config/docker.json? Seems to me that doing so would make it simpler for the user to complete the install, as opposed to asking them to create a new text file and copy/paste the required content into it.
Also, don't the Docker and Git commands remain the same across different OS installs? If so, could we put these instructions into an install script?

No particular reason for it, that's a good idea.
And yes we can make a script that runs all this. We'll need to include a check for the architecture to make sure we run the right version of MongoDB.

The MongoDB docker image may not run on older CPUs - those that do not support AVX.
(dc) me@dockerdev:~/git/github/homebrewery$ docker logs b646d75d4a97

WARNING: MongoDB 5.0+ requires a CPU with AVX support, and your current system does not appear to have that!
  see https://jira.mongodb.org/browse/SERVER-54407
  see also https://www.mongodb.com/community/forums/t/mongodb-5-0-cpu-intel-g4650-compatibility/116610/2
  see also https://github.com/docker-library/mongo/issues/485#issuecomment-891991814

I was able to get Homebrewery running in a docker container with the bitnami/mongodb container.  I speculate that the Bitnami container is compiled with different options.
(dc) me@dockerdev:~/git/github/homebrewery$ git diff
diff --git a/docker-compose.yml b/docker-compose.yml
index f74fadc..bdf1a88 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -1,7 +1,7 @@
 version: '2'
 services:
   mongodb:
-    image: mongo:latest
+    image: bitnami/mongodb:latest
     volumes:
       - mongodata:/data/db
   homebrewery:


NullPointerException with PostgreSQL multi-statement CREATE RULE

Which version and edition of Flyway are you using?
Flyway Community Edition 5.2.3 by Boxfuse
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)
Command-line and Java API.
Which database are you using (type & version)?
PostgreSQL 10.4
Which operating system are you using?
Mac OS, Linux.
What did you do?
The following migration
CREATE TABLE bar (id serial);
CREATE TABLE baz (id int, lastactivity int);
CREATE TABLE token (token int);
CREATE RULE foo AS ON UPDATE TO bar DO INSTEAD (UPDATE baz SET lastactivity = 1 WHERE id = 1; UPDATE token SET token = 2);

executed with flyway -X -url=jdbc:postgresql://localhost:5432/test -user=postgres -password= -locations=filesystem:. migrate.
What did you expect to see?
A successfully applied migration as the above syntax is accepted by PostgreSQL.
What did you see instead?
ERROR: Unexpected error
java.lang.NullPointerException
	at org.flywaydb.core.internal.sqlscript.AbstractSqlStatement.stripDelimiter(AbstractSqlStatement.java:98)
	at org.flywaydb.core.internal.sqlscript.AbstractSqlStatement.getSql(AbstractSqlStatement.java:72)
	at org.flywaydb.core.internal.sqlscript.SqlScript.addStatement(SqlScript.java:169)
	at org.flywaydb.core.internal.sqlscript.SqlScript.extractStatements(SqlScript.java:145)
	at org.flywaydb.core.internal.sqlscript.SqlScript.<init>(SqlScript.java:86)
	at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.addMigrations(SqlMigrationResolver.java:140)
	at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.resolveMigrations(SqlMigrationResolver.java:100)
	at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.resolveMigrations(SqlMigrationResolver.java:47)
	at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.collectMigrations(CompositeMigrationResolver.java:136)
	at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.doFindAvailableMigrations(CompositeMigrationResolver.java:118)
	at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.resolveMigrations(CompositeMigrationResolver.java:104)
	at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.resolveMigrations(CompositeMigrationResolver.java:46)
	at org.flywaydb.core.internal.info.MigrationInfoServiceImpl.refresh(MigrationInfoServiceImpl.java:133)
	at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:138)
	at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:126)
	at org.flywaydb.core.internal.jdbc.TransactionTemplate.execute(TransactionTemplate.java:74)
	at org.flywaydb.core.internal.command.DbValidate.validate(DbValidate.java:126)
	at org.flywaydb.core.Flyway.doValidate(Flyway.java:1473)
	at org.flywaydb.core.Flyway.access$100(Flyway.java:82)
	at org.flywaydb.core.Flyway$1.execute(Flyway.java:1361)
	at org.flywaydb.core.Flyway$1.execute(Flyway.java:1353)
	at org.flywaydb.core.Flyway.execute(Flyway.java:1708)
	at org.flywaydb.core.Flyway.migrate(Flyway.java:1353)
	at org.flywaydb.commandline.Main.executeOperation(Main.java:161)
	at org.flywaydb.commandline.Main.main(Main.java:108)

The error disappears if a terminating semicolon is included in the rule. Related to issue #2202. Although the original problem was resolved, the problem reoccurs when using a rule with two statements. This is a regression since version 5.0.7.

Thanks for reporting. Fixed.


feat: Replace redis by valkey

Replace redis instance by valkey

Secret name is kept as redis-credentials for simplicity with current secret
Code package is still redis
Code variable are still REDIS_ADDR and REDIS_PASSWORD to be consistent with package

Monitoring has not been migrated because:

The current exporter image has a lot of vuln (the point of migrating is to reduce the number of vuln)
Metrics are not consumed atm anyway
The PR is probably already big enough

/lgtm
/approve

/lgtm
/approve


Add Possibility to Select Tesseract Extractor in the Web Interface

Is your feature request related to a problem? Please describe.
One cannot choose to extract a document (PDF, images...) using Tesseract, ABBYY, Google Vision or anything else than Pdfminer.
Describe the solution you'd like

Add more options to the dropdown.
Add a dropdown for images as well.
Pretty much like in the config file (Google Vision is missing, by the way).

Current UI allows to select:

PDF Extractors: PdfMiner & PDF.js
OCR's: Tesseract, Abbyy, Google Vision, Amazon Textract & MS Cognitive services