Comments (4)
Thanks for the bug report. The first stacktrace from atos
is garbled, it doesn't make sense.
The second stacktrace does make sense, but looking at the code and I don't see how that could happen.
It uses the tantivy_bitpacker
, which does not use any SIMD code in that path.
Can you run it with a modified version of tantivy? I could push some changes to a branch, to get more context information, when the panic occurs. Is the GH repo public?
from tantivy.
The code you point at is NOT using SIMD. SIMD bitpacking uses a different layout that prevents efficient random access, and we need random access for columns.
Like @PSeitz, I have no clue where it could come from.
There are two calls to BitUnpacker::new
in this file.
The first one happens in deserialization of the existing column. It is probably called as we consume the dyn
Iterator, but I think the stacktrace would have looked different if it was the one hitting.
The second one happens on code that is rather straightforward.
bit_width is obtained via:
let bit_width = buffer.iter().copied().map(compute_num_bits).max().unwrap();
pub fn compute_num_bits(n: u64) -> u8 {
let amplitude = (64u32 - n.leading_zeros()) as u8;
if amplitude <= 64 - 8 {
amplitude
} else {
64
}
}
As far as I can tell, all number exiting this function, and their max, should match the assert.
If it is easy to reproduce, we can add a couple of asserts here and there, and more info on the value triggering the assert.
If you can share the segments and the schema triggering the assert, this would be even more helpful.
Rust 1.78 had an LLVM upgrade so it could even be an actual compiler bug.
Also if you have some kind of compiler cache in your CI? can you try and clean it or disable it and see if your problem gets solved?
from tantivy.
Thanks for getting back. Sorry that the first stack trace is not more helpful. That's just the atos output for a couple of memory addresses from the crash log to see whether bitpacking showed up somewhere.
It all doesn't make sense to me either, so I tried comparing the build environment and the different CPU features was the only one I could spot so far. (But, as far as I understand, SIMD is not involved and even if there were compile time differences, it wouldn't explain the different runtime behavior because of feature detection.)
Now I tried running a CI build again with the old config and got an interesting new permutation of the crash this time (right after running the binary on the command line):
53287 illegal hardware instruction
so it tries running a machine instruction that is not supported by the CPU.
Here's the build config:
rust-toolchain.toml
[toolchain]
channel = "1.76.0"
targets = ["aarch64-apple-darwin", "x86_64-apple-darwin"]
Cargo.toml
[profile.release]
strip = "debuginfo"
opt-level = 3
lto = true
codegen-units = 1
panic = "unwind"
A build with toolchain 1.78.0 and panic = "abort"
as only release profile option has been running stable so far.
Re CI and caching: There should be a fresh Github runner for each run and we don't do any custom caching in the action. For the toolchain setup we've been using this action, then set up cargo make via this action, run cargo clean, and then build via:
command = "cargo"
args = [
"build",
"--release",
"--target",
"aarch64-apple-darwin",
"--locked",
"-p",
"server",
I'll check again the Github actions to see if there could be any effects.
from tantivy.
I couldn't reproduce it any more since we've removed third-party actions from our GitHub CI workflow. (Btw, we've found that the macOS runner by default supports the Rust toolchain, so there's no need for additional setup actions.)
from tantivy.
Related Issues (20)
- Implement "minimum number should match" on BooleanQuery HOT 3
- Flaky Test test_cancel_cpu_intensive_tasks HOT 3
- Does tantivy::IndexWriter support multi-process? HOT 4
- Rayon thread pool abort on panic
- Isolate Aggregations
- parsing simple quote in query doesn't always give a sensible result
- allow escape in query string outside of quotes
- Concurrent commit failed in multi-process environment HOT 1
- Unique field HOT 1
- Track new FxHash Algorithm
- Fix inefficiency on multivalued but sparse column. HOT 1
- Add error handling for invalid CustomOrder in term aggregation
- monotonic mapping broken for `get_docids_for_value_range`
- Possible Codec Between SPARSE and DENSE: CHIMERA HOT 2
- keys should be increasing panic HOT 4
- Merge policy works unexpectedly for uncommitted documents HOT 6
- Tantivy NDCG Benchmarking Information Retrieval (BEIR) HOT 3
- calendar_interval in datehistogram
- more ast optimizations arround boolean queries
- Improve incorrect type handling on columnar
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tantivy.