commit c5fd96ebb vs. gcc15 vs. ppcle64 in Fedora

[gsomlo]

Version

commit c5fd96e

On which OS did this happen?

Linux

Reproduction Steps

I maintain yosys in Fedora. With each new release, the source RPM is built for a set of different architectures, including x86_64, aarch64, etc., including ppc64le.

While working on version 51, I noticed that make test fails, only on ppcle64, and only on fedora versions >= 42
(the latter most likely correlated with gcc version 15).

After a bisect, I found the first commit where this happens to be c5fd96e ("macc_v2: Start new cell"), authored by @povik

Attached is the full ppcle64 fedora mock build log illustrating that problem. c5fd96ebb0c9067927bd4df381af92783bb4b547.build.log.txt

Expected Behavior

make test succeeds on all architectures, including ppcle64

Actual Behavior

make test fails on ppcle64, gcc15 (fedora 42 and later)

[KrystalDelusion]

(the latter most likely correlated with gcc version 15).

Ah, looks like we only have CI for gcc-13 or older. And gcc-14 was failing when it was set to gcc-13 as the newest supported. Should probably look into why that was failing.

[gsomlo]

On Wed, Mar 26, 2025 at 03:15:53PM -0700, KrystalDelusion wrote: (the latter most likely correlated with gcc version 15). Ah, looks like we only have CI for gcc-13 or older. And gcc-14 was failing when it was set to gcc-13 as the newest supported. Should probably look into why that was failing.

The weird thing is that (for now) it only fails on (gcc15 AND arch==ppcle64). I.e., it passes all tests (even with gcc15) on x86_64. On one hand, ppcle64 is the "tail wagging the dog" in that I don't know anyone who might really care about the intersection of yosys and that arch... :) OTOH, just because it fails to fail on x86_64, doesn't mean there isn't something subtly wrong and ppcle64 is just an "early warning"...

[KrystalDelusion]

Are you able to retrieve the tests/arch/nanoxplore/meminit.log file? According to the log file you shared that should contain the failure

ERROR: Assertion top.did_read_$check_EN (meminit.v:47.9-47.39) failed.
make[1]: *** [run-test.mk:41: nanoxplore-meminit.ys] Error 1

[KrystalDelusion]

Are you able to test with latest main? We've had a few issues come through from the Debian folks that we've fixed for them, and I wonder if something in there might solve this too.

[gsomlo]

Are you able to retrieve the tests/arch/nanoxplore/meminit.log file?

meminit.log

I'm also going to try building the latest main, but that's going to take a few hours of ppcle64-on-x86 emulation...

[KrystalDelusion]

Oh, nanoxplore-meminit.ys is failing on c5fd96e because the $macc_v2 cell didn't have a model when it was initially added. I would be very surprised if that was the same failure as the v0.51 release. When bisecting try to stick to commits on main, since commits in PRs may be in work in progress and aren't expected to pass CI, whereas main is (although there are still rare cases where main failed on a non-release commits, so may be worth double checking the CI report anyway).

[gsomlo]

When bisecting try to stick to commits on main

I had grabbed main at the time I got the "v0.51 was observed in the wild" notification from the fedora monitoring scripts, and tried to build it. I found c5fd96e to be the first commit failing on ppcle64 between the v051 tag and current main, via bisect.

So yeah, breakage started happening some short time after the v051 release.

I also tried latest main as of 13 hours ago (which had commit ID b913185).

As before, it builds fine on x86_64, but fails a (different this time) test on ppcle64. Here's the build log: b9131853f.build.log and also the log of the failing test: t_mem1.log

EDIT: it's not quite failing the test, as much as the test leads it to coredump on ppcle64...

[KrystalDelusion]

So yeah, breakage started happening some short time after the v051 release.

Gotcha, thanks.

EDIT: it's not quite failing the test, as much as the test leads it to coredump on ppcle64...

That's... odd. Having written it out both before and after the memory_libmap call that is getting the segfault on ppcle64, with both 0.51 and 0.51+85 (b913185). The only difference in the outputs are the names of the auto generated wires/cells because they take the line number of the file they come from (all of the differences here being a few lines later in rtlil.cc). memory_libmap (the command where the fault is thrown) hasn't changed in that time either.

If there was anything between 0.51 and 0.51+85 that could've broken support on an obscure platform, I would've guessed it was #4834 which refactored io handling, rather than #4818 which you originally picked out. Are you able to test e44d1d4? That

EDIT: As I was saying, that should include the complete macc_v2 PR and we can see if it's the same thing failing or not. Alternatively, if you still have access to the compiled b913185 in ppcle64 can you try run tests/various/stat.ys, if that fails then I think there's a good chance that the problem is the io changes.

[KrystalDelusion]

Dang misclick...

[KrystalDelusion]

The

terminate called after throwing an instance of 'std::runtime_error'
  what():  pool<> assert failed.

suggests a failure in hash lib, but that also hasn't changed since before 0.51.

[gsomlo]

attempting to build e44d1d4 on ppcle64 fails with the same error as main, earlier:

...
Passed qlf_k6n10f-t_mem0.ys
Warning: delay target has not been set via SDC or scratchpad; assuming 12 MHz clock.
Warning: Complex async reset for dff `\Q'.
Warning: Resizing cell port TB.uut.data_out from 8 bits to 32 bits.
Warning: Resizing cell port TB.uut.address_in_r from 10 bits to 8 bits.
Warning: Wire TB.\rq_b [7] is used but has no driver.
Warning: Wire TB.\rq_b [6] is used but has no driver.
Warning: Wire TB.\rq_b [5] is used but has no driver.
Warning: Wire TB.\rq_b [4] is used but has no driver.
Warning: Wire TB.\rq_b [3] is used but has no driver.
Warning: Wire TB.\rq_b [2] is used but has no driver.
Warning: Wire TB.\rq_b [1] is used but has no driver.
Warning: Wire TB.\rq_b [0] is used but has no driver.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
make[1]: *** [run-test.mk:71: qlf_k6n10f-t_mem1.ys] Segmentation fault (core dumped)
make[1]: Leaving directory '/builddir/build/BUILD/yosys-0.51-build/yosys/tests/arch/quicklogic/qlf_k6n10f'
...

Here's a(nother?) copy of t_mem1.log

[KrystalDelusion]

That actually appears to be a different error, signal 11/segfault instead of signal6/abort... But both in the same place. Something is going very wrong there. Rather than running the full test suite, are you able to build Yosys (or reuse a previous build you still have it) and run this script:
script.ys

read_verilog << EOF
module double_sync_ram_sdp #(parameter DATA_WIDTH_A=10, ADDRESS_WIDTH_A=16, DATA_WIDTH_B=10, ADDRESS_WIDTH_B=16)
(
    input  wire                        write_enable_a, clk_a,
    input  wire  [DATA_WIDTH_A-1:0]    data_in_a,
    input  wire  [ADDRESS_WIDTH_A-1:0] address_in_r_a, address_in_w_a,
    output wire  [DATA_WIDTH_A-1:0]    data_out_a,

    input  wire                        write_enable_b, clk_b,
    input  wire  [DATA_WIDTH_B-1:0]    data_in_b,
    input  wire  [ADDRESS_WIDTH_B-1:0] address_in_r_b, address_in_w_b,
    output wire  [DATA_WIDTH_B-1:0]    data_out_b
);

    sync_ram_sdp #(
        .DATA_WIDTH(DATA_WIDTH_A),
        .ADDRESS_WIDTH(ADDRESS_WIDTH_A)
    ) a_ram (
    .write_enable(write_enable_a),
    .clk(clk_a),
    .data_in(data_in_a),
    .address_in_r(address_in_r_a),
    .address_in_w(address_in_w_a),
    .data_out(data_out_a)
    );

    sync_ram_sdp #(
        .DATA_WIDTH(DATA_WIDTH_B),
        .ADDRESS_WIDTH(ADDRESS_WIDTH_B)
    ) b_ram (
    .write_enable(write_enable_b),
    .clk(clk_b),
    .data_in(data_in_b),
    .address_in_r(address_in_r_b),
    .address_in_w(address_in_w_b),
    .data_out(data_out_b)
    );

endmodule // double_sync_ram_sdp

module sync_ram_sdp #(parameter DATA_WIDTH=8, ADDRESS_WIDTH=10)
   (input  wire                      clk, write_enable,
    input  wire  [DATA_WIDTH-1:0]    data_in,
    input  wire  [ADDRESS_WIDTH-1:0] address_in_r, address_in_w,
    output wire  [DATA_WIDTH-1:0]    data_out);

  localparam WORD  = (DATA_WIDTH-1);
  localparam DEPTH = (2**ADDRESS_WIDTH-1);

  reg [WORD:0] data_out_r;
  reg [WORD:0] memory [0:DEPTH];

  always @(posedge clk) begin
    if (write_enable)
      memory[address_in_w] <= data_in;
    data_out_r <= memory[address_in_r];
  end

  assign data_out = data_out_r;

endmodule // sync_ram_sdp

EOF
debug synth_quicklogic -family qlf_k6n10f -top double_sync_ram_sdp

I'm not sure if it will work, but could you also try to call it with yosys --trace script.ys

[gsomlo]

Here's the output of yosys script.ys: yosys_script.log

Also, with --trace: yosys_trace_script.log

This is with ppcle64 yosys build from commit e44d1d4.

Thanks for looking into it, much appreciated!

[KrystalDelusion]

That's perfect. Running locally I get

mapping memory double_sync_ram_sdp.b_ram.memory via $__QLF_TDP36K
#X# New IdString '$auto$mem.cc:1619:emulate_read_first$442' with index 1296.
#X# New IdString '$auto$mem.cc:1620:emulate_read_first$443' with index 1297.
#X# New IdString '$auto$mem.cc:1622:emulate_read_first$444' with index 1298.
#X# New IdString '$auto$mem.cc:1623:emulate_read_first$445' with index 1299.
#X# New IdString '$auto$mem.cc:1624:emulate_read_first$446' with index 1300.
#X# New IdString '$auto$mem.cc:1625:emulate_read_first$447' with index 1301.
#X# Connect double_sync_ram_sdp.$auto$mem.cc:1623:emulate_read_first$445.CLK = \clk_b (1)
#X# Connect double_sync_ram_sdp.$auto$mem.cc:1623:emulate_read_first$445.D = $flatten\b_ram.$0$memwr$\memory$<<EOF:54$216_DATA[9:0]$219 (10)
#X# Connect double_sync_ram_sdp.$auto$mem.cc:1623:emulate_read_first$445.Q = $auto$mem.cc:1619:emulate_read_first$442 (10)

compared to your

#X# New IdString '$auto$mem.cc:1619:emulate_read_first$442' with index 1296.
#X# New IdString '$auto$mem.cc:1620:emulate_read_first$443' with index 1297.
#X# New IdString '$auto$mem.cc:1622:emulate_read_first$444' with index 1298.
#X# New IdString '$auto$mem.cc:1623:emulate_read_first$445' with index 1299.
#X# New IdString '$auto$mem.cc:1624:emulate_read_first$446' with index 1300.
#X# New IdString '$auto$mem.cc:1625:emulate_read_first$447' with index 1301.
double free or corruption (!prev)
qemu: uncaught target signal 6 (Aborted) - core dumped

Which tells us that the crash is after mem.cc:1625, and before the module->addDff() call at ff.cc:605 in the ff_data.emit() method call. The most likely place being the call to FfData::remove() in emit().

void FfData::remove() {
	if (cell) {
		remove_init();
		module->remove(cell);
		cell = nullptr;
	}
}

Especially with one of your earlier crashes giving the message

terminate called after throwing an instance of 'std::runtime_error'
  what():  pool<> assert failed.

Which would most likely be in the module->remove(cell) call during cells_.erase(cell->name), which calls do_erase(index, hash), which has the do_assert's that would have thrown that std::runtime_error. The double free or corruption (!prev) is likely also in there somewhere.

The problem with that of course is that the cell in question should be ==nullptr, and if (cell) should evaluate to false and not end up inside of that block. I can even reproduce a segfault locally by changing it to if(cell || true). The question then becomes, does gcc15 in ppcle64 evaluate nullptr==true?

Are you able to change ff.cc:666 to if (cell != nullptr) { and try the script.ys again? I can push a commit with the change if you need.

[gsomlo]

Are you able to change ff.cc:666 to if (cell != nullptr) { and try the script.ys again?

I've just added an extra out-of-tree patch to the rpm build script (i.e., spec file) to do that, and it's currently going through the motions. I'll run the script again when it's done building. We'll also know whether the test(s) affected are still failing or not.

Stay tuned... :)

[gsomlo]

with the patch applied:

• builds fine on x86_64, as before
• fails on ppc64le, as before:

  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  make[1]: *** [run-test.mk:71: qlf_k6n10f-t_mem1.ys] Segmentation fault (core    dumped)
  make[1]: Leaving directory '/builddir/build/BUILD/yosys-0.51-build/yosys/tests/ arch/quicklogic/qlf_k6n10f'
  

• output of yosys script.ys: script1.log
• output of yosys --trace script.ys: script-trace1.log

script.ys still coredumps, which is interesting...

[gsomlo]

I've added gdb to the RPM list of BuildRequires; hopefully I can use it inside the container to wrap yosys script.ys, and get an actual stack trace. I'll follow up here if/when I succeed in that endeavour :)

[gsomlo]

(gdb) run script.ys
Starting program: /builddir/build/BUILD/yosys-build/BUILDROOT/usr/bin/yosys script.ys
warning: Could not trace the inferior process.
warning: ptrace: Function not implemented
During startup program exited with code 127.

turns out, "mock" uses user-mode qemu, which apparently does not support ptrace... :(

[gsomlo]

Here it is: gdb.log

I had to cut'n'paste from the terminal, as script output contained way too much terminal control sequence crap to make sense to the naked eye. As such, I only caught the end of the actual yosys script.ys output before the segfault, but managed to get the gdb bt output.

LMK if there's anything else I should try to collect. Thanks!

EDIT: and here's the bt after running run --trace ./script.ys on the pre-install (non-stripped, with debug-info) version of the yosys binary: gdb-trace.log

[KrystalDelusion]

Okay so it's faulting in TEST double_sync_ram_sdp WITH PARAMS -set ADDRESS_WIDTH_A 10 -set DATA_WIDTH_A 16 -set ADDRESS_WIDTH_B 10 -set DATA_WIDTH_B 16 while trying to assign an initial value of 10'x to the data register ($auto$mem.cc:1619:emulate_read_first$442) during Mem::emulate_read_first(). And it's not picked up earlier because the earlier tests aren't trying to emulate read first behaviour.

More specifically, it happens while looking up the representative SigBit with SigMap (though without more instrumentation it's impossible to know exactly which of the 10 bits is leading to the fault). While trying to find the bit, it triggers a rehash, clearing the current hastable and resizing it. During that resize, it allocates new memory, and then faults while deallocating the old memory.

And there it is, just tested with ASAN

=================================================================
==941807==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7f8b90c43bc0 at pc 0x55a9b66f2c4f bp 0x7ffced6c0050 sp 0x7ffced6c0048
READ of size 8 at 0x7f8b90c43bc0 thread T0
    #0 0x55a9b66f2c4e in __gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int>>>::__normal_iterator(int const* const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/stl_iterator.h:1077:20
    #1 0x55a9b66f2c4e in std::vector<int, std::allocator<int>>::begin() const /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/stl_vector.h:881:16
    #2 0x55a9b66f2c4e in std::vector<int, std::allocator<int>>::empty() const /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/stl_vector.h:1086:16
    #3 0x55a9b66f2c4e in Yosys::hashlib::pool<Yosys::RTLIL::SigBit, Yosys::hashlib::hash_ops<Yosys::RTLIL::SigBit>>::do_hash(Yosys::RTLIL::SigBit const&) const /home/dawn/yosys/./kernel/hashlib.h:845:18
    #4 0x55a9b66f2c4e in Yosys::hashlib::idict<Yosys::RTLIL::SigBit, 0, Yosys::hashlib::hash_ops<Yosys::RTLIL::SigBit>>::at(Yosys::RTLIL::SigBit const&, int) const /home/dawn/yosys/./kernel/hashlib.h:1232:34
    #5 0x55a9b66f2c4e in Yosys::hashlib::mfp<Yosys::RTLIL::SigBit, Yosys::hashlib::hash_ops<Yosys::RTLIL::SigBit>>::find(Yosys::RTLIL::SigBit const&) const /home/dawn/yosys/./kernel/hashlib.h:1359:20
    #6 0x55a9b69218e9 in Yosys::SigMap::apply(Yosys::RTLIL::SigBit&) const /home/dawn/yosys/./kernel/sigtools.h:326:18
    #7 0x55a9b69218e9 in Yosys::SigMap::operator()(Yosys::RTLIL::SigBit) const /home/dawn/yosys/./kernel/sigtools.h:337:3
    #8 0x55a9b69218e9 in Yosys::FfInitVals::set_init(Yosys::RTLIL::SigBit, Yosys::RTLIL::State) /home/dawn/yosys/./kernel/ffinit.h:85:17
    #9 0x55a9b695a423 in Yosys::FfInitVals::set_init(Yosys::RTLIL::SigSpec const&, Yosys::RTLIL::Const) /home/dawn/yosys/./kernel/ffinit.h:111:4
    #10 0x55a9b694a6b5 in Yosys::FfData::emit() /home/dawn/yosys/kernel/ff.cc:552:13
    #11 0x55a9b68ea3f1 in Yosys::Mem::emulate_read_first(Yosys::FfInitVals*) /home/dawn/yosys/kernel/mem.cc:1633:11
    #12 0x55a9b72ebd81 in (anonymous namespace)::MemMapping::emit((anonymous namespace)::MemConfig const&) /home/dawn/yosys/passes/memory/memory_libmap.cc:1996:7
    #13 0x55a9b72d5f1f in (anonymous namespace)::MemoryLibMapPass::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>, Yosys::RTLIL::Design*) /home/dawn/yosys/passes/memory/memory_libmap.cc:2260:10
    #14 0x55a9b6551872 in Yosys::Pass::call(Yosys::RTLIL::Design*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>) /home/dawn/yosys/kernel/register.cc:260:26
    #15 0x55a9b6f7bd2b in (anonymous namespace)::DebugPass::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>, Yosys::RTLIL::Design*) /home/dawn/yosys/passes/cmds/trace.cc:121:4
    #16 0x55a9b6551872 in Yosys::Pass::call(Yosys::RTLIL::Design*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>) /home/dawn/yosys/kernel/register.cc:260:26
    #17 0x55a9b6550a2c in Yosys::Pass::call(Yosys::RTLIL::Design*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>) /home/dawn/yosys/kernel/register.cc:237:2
    #18 0x55a9b676c266 in Yosys::run_frontend(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, Yosys::RTLIL::Design*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*) /home/dawn/yosys/kernel/yosys.cc:754:6
    #19 0x55a9b64b7933 in main /home/dawn/yosys/kernel/driver.cc:541:7
    #20 0x7f8b92c70082 in __libc_start_main /build/glibc-FcRMwW/glibc-2.31/csu/../csu/libc-start.c:308:16
    #21 0x55a9b63c58cd in _start (/home/dawn/yosys/yosys+0xbf78cd) (BuildId: ec404b1993bc0c459c8d3602840bedffe41f1c0e)

Address 0x7f8b90c43bc0 is located in stack of thread T0 at offset 3008 in frame
    #0 0x55a9b72d510f in (anonymous namespace)::MemoryLibMapPass::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>, Yosys::RTLIL::Design*) /home/dawn/yosys/passes/memory/memory_libmap.cc:2184

  This frame has 12 object(s):
    [32, 36) 'hash.i'
    [48, 56) '__dnew.i.i.i'
    [80, 104) 'lib_files' (line 2185)
    [144, 200) 'defines' (line 2186)
    [240, 264) 'opts' (line 2187)
    [304, 328) 'agg.tmp'
    [368, 392) 'lib' (line 2229)
    [432, 456) 'ref.tmp' (line 2231)
    [496, 1216) 'worker' (line 2235)
    [1344, 1368) 'mems' (line 2236)
    [1408, 2376) 'map' (line 2239)
    [2512, 3232) 'ref.tmp177' (line 2262) <== Memory access at offset 3008 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /home/dawn/yosys/./kernel/hashlib.h:845:18 in Yosys::hashlib::pool<Yosys::RTLIL::SigBit, Yosys::hashlib::hash_ops<Yosys::RTLIL::SigBit>>::do_hash(Yosys::RTLIL::SigBit const&) const

Local reproduction*!

*maybe, ASAN is giving the error during the do_hash, as opposed to the do_lookup on the following line that the gdb-trace shows.

[KrystalDelusion]

Reverting #4892 seems to fix the ASAN error.

@widlarizer was there a reason that #4892 rebuilds the indices at the end of the loop, as opposed to moving the MapWorker definition inside of it?

@gsomlo can you test with this patch applied:

diff --git a/passes/memory/memory_libmap.cc b/passes/memory/memory_libmap.cc
index b0d0498ea..b62375e7e 100644
--- a/passes/memory/memory_libmap.cc
+++ b/passes/memory/memory_libmap.cc
@@ -2232,10 +2232,10 @@ struct MemoryLibMapPass : public Pass {
 			if (module->has_processes_warn())
 				continue;
 
-			MapWorker worker(module);
 			auto mems = Mem::get_selected_memories(module);
 			for (auto &mem : mems)
 			{
+				MapWorker worker(module);
 				MemMapping map(worker, mem, lib, opts);
 				int idx = -1;
 				int best = map.logic_cost;
@@ -2258,8 +2258,6 @@ struct MemoryLibMapPass : public Pass {
 					log("using FF mapping for memory %s.%s\n", log_id(module->name), log_id(mem.memid));
 				} else {
 					map.emit(map.cfgs[idx]);
-					// Rebuild indices after modifying module
-					worker = MapWorker(module);
 				}
 			}
 		}

[gsomlo]

@gsomlo can you test with this patch applied:

Built on top of new 0.52 tag with the patch applied. Build succeeds, all checks pass, no segfault on either ppcle64 or x86_64.

That seems to fix the problem, thanks again for looking into it!

[widlarizer]

I'm sure that one person with a powerpc digital synthesis workstation appreciates our hard work :3
jk, UB is bad regardless of observed occurrences. Thanks for the report

[gsomlo]

On Tue, Apr 15, 2025 at 01:54:07AM -0700, Emil J wrote: I'm sure that one person with a powerpc digital synthesis workstation appreciates our hard work :3

Heh, I'm quite comfortable assuming that one person does not even exist, so all the hard work shall remain unappreciated... :P

jk, UB is bad regardless of observed occurrences.

With my Fedora packager hat on, I prefer to look at the mandatory "alternative" architectures on which packages must also be built and tested as a slightly annoying (but likely beneficial in hindsight) "early warning system" for just this kind of thing :)

Thanks for the report

Thank you all for the fix, and for looking after the project overall!