Dennis Felsing
Dennis Felsing
> Also, this error should disappear in release mode and simply wrap-around. With [ASan](https://github.com/MaterializeInc/materialize/pull/24888) and release mode this panic is also occurring: https://buildkite.com/materialize/tests/builds/74647#018d6983-9098-4560-9dc2-583a5f307716 ``` thread 'timely:work-1' panicked at /rustc/4cb3beec86178baff601529389306a4949b077ce/library/core/src/ops/arith.rs:760:1: attempt...
Another one in https://buildkite.com/materialize/tests/builds/77062#018df3dc-85d8-46cf-b5f7-aab307423506 ``` thread 'timely:work-1' panicked at src/compute/src/render/reduce.rs:2018:17: attempt to add with overflow stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::panicking::panic 3: ::plus_equals 4: differential_dataflow::difference::vector::::plus_equals 5: differential_dataflow::consolidation::consolidate_updates_from 6:...
I tried running the queries from SQLancer but that didn't cause the panic: https://gist.github.com/def-/67bb918263ff52d71ddcffb8fd429041
This is now happening in production on 0.85.2! ^ So definitely not ARM-specific. Edit: This was just logged, didn't cause a panic.
From SQLancer PQS: https://buildkite.com/materialize/nightlies/builds/6368#018d8b33-d151-4fbe-9beb-8c4da858503c ``` sqlancer-materialized-1 | environmentd: 2024-02-08T23:36:15.603145Z INFO message_command:coord::handle_execute{session="57ddbed7-8de3-40ed-b710-5d893eae103f"}:coord::handle_execute_inner{stmt="CREATE TABLE IF NOT EXISTS t0 (c0 bool)"}:sequence_create_table:coord::catalog_transact_with_side_effects:coord::catalog_transact_with:catalog::transact:catalog::transact_inner: mz_adapter::catalog::state: create table database1.public.t0 (u29) sqlancer-materialized-1 | cluster-u1-replica-u1: 2024-02-08T23:36:15.645090Z INFO mz_persist_client::internal::machine: snapshot...
Yes, SQLancer runs with 4 parallel threads in our testing by default. But that means there are 4 separate databases (`CREATE DATABASE`, not Mz instances), which don't interact with each...
Happened again in Sentry with more information: ``` all dropped_notices entries have `Arc::strong_count(_) == 1`; bad_notices = {(id = t7843026, kind = IndexTooWideForLiteralConstraints, deps = {User(63911), User(63912)}, strong_count = 4),...
Occurred again in [Parallel Workload (rename)](https://buildkite.com/materialize/nightly/builds/8916#019112de-0e7a-42da-8ace-17719f87f7be): ``` thread 'coordinator' panicked at src/adapter/src/catalog.rs:297:13: all dropped_notices entries have `Arc::strong_count(_) == 1`; bad_notices = {(id = t856, kind = IndexAlreadyExists, deps = {User(32),...
I don't think those are the kinds of exceptions that get thrown. MATH_ERREXCEPT is also set for me on macOS, but I never get exceptions/crashes from float calculations.
I don't think there is a way to make rules that can't be gamed in order to get any server accepted as its own community.