Question 1

/O2 사용 시 정수 곱셈 루프에서 발생하는 MSVC ARM64 C1001 내부 컴파일러 오류를 해결하는 방법

Accepted Answer

이 문제는 Windows 11 ARM64의 MSVC 19.51(toolset 14.51.36231)에서 발생하는 옵티마이저 회귀입니다. /O2 /Ob2 옵션에서 상수로 채워진 벡터를 사용하는 호출자에 static_cast<int>(codes[i]) * codes[i]를 포함하는 루프가 인라인될 때 발생할 수 있습니다.

64비트 곱셈을 강제하여 이 문제를 우회할 수 있습니다:

sum_squared += static_cast<int64_t>(codes[i]) * codes[i];

원래의 8비트 값은 32비트 곱셈 결과를 오버플로우할 수 없으므로 이 방법은 결과를 보존합니다. 다른 우회 방법으로는 루프 앞에 #pragma loop(no_vector)를 추가하거나 루프를 별도의 문으로 분할하는 방법이 있습니다. 이 문제는 MSVC 19.44에서는 재현되지 않습니다.

Question 2

MSVC로 Windows ARM64용 zvec를 빌드할 때 CMake 오류 "Target zvec_ailego is required by zvec_ailego_shared"를 수정하는 방법은 무엇인가요?

Accepted Answer

이 문제는 `src/ailego/CMakeLists.txt`가 `zvec_ailego` 타겟을 생성하기 전에 ARM64의 MSVC에 대해 `return()`을 호출하고 `BUILD_ZVEC_AILEGO_SHARED`가 활성화된 상태로 남아 있기 때문에 zvec 0.5.1에서 발생합니다. 이 문제는 `main`에 병합된 PR #352에서 수정되었습니다.

권장 해결 방법: zvec 의존성을 최신 `main` 또는 PR #352가 포함된 릴리스로 업데이트한 후 다시 구성하세요:

```bat
rmdir /s /q build
cmake -B build -G Ninja ^
  -DCMAKE_SYSTEM_NAME=Windows ^
  -DCMAKE_SYSTEM_PROCESSOR=ARM64 ^
  -DBUILD_C_BINDINGS=ON ^
  -DBUILD_ZVEC_AILEGO_SHARED=ON
cmake --build build
```

zvec 0.5.1을 계속 사용해야 하고 올인원 ailego 공유 라이브러리가 필요하지 않다면, 이를 비활성화하세요:

```bat
cmake -B build -G Ninja ^
  -DCMAKE_SYSTEM_NAME=Windows ^
  -DCMAKE_SYSTEM_PROCESSOR=ARM64 ^
  -DBUILD_C_BINDINGS=ON ^
  -DBUILD_ZVEC_AILEGO_SHARED=OFF
```

또는 PR #352를 백포트하거나 `src/ailego/CMakeLists.txt`를 패치하세요: MSVC ARM64에 대해 무조건 `return()`하지 않고, `cc_library(NAME zvec_ailego ...)` 호출을 유지하며, `-march=armv8-a`와 같은 GCC/Clang 플래그는 MSVC가 아닌 컴파일러에만 적용하세요.

Question 3

Quick caveat: I can't verify the exact behavior of zvec's `context()`/`excludedFileTypes` API, so treat the specifics as a starting hypothesis. That said, a SIGSEGV from a native stack overflow in this kind of call almost always has the same root cause and set of fixes.

## Likely cause

`context()` typically does recursive directory traversal in native code. `excludedFileTypes` filters files *after* visiting them — it doesn't prune the traversal itself. So deep directory nesting or a symlink cycle can recurse the native thread into stack exhaustion before any exclusion ever applies. This produces a SIGSEGV (not a clean `StackOverflowError`), because native code has no overflow check.

## Confirm the diagnosis

Get a backtrace to verify it's unbounded recursion (you'll see the same frame repeated thousands of times):

```bash
ulimit -c unlimited
# reproduce the crash, then:
gdb /path/to/binary core
(gdb) bt
```

Check for symlink loops in the scanned tree:

```bash
find -L . -type l 2>&1 | grep -i "loop\|too many levels"
```

## Fixes, in order of likelihood

1. **Break symlink cycles.** If a symlink points to an ancestor directory, recursive traversal never terminates. Remove the link, or if zvec has a `followSymlinks`-style option, disable it.

2. **Prune directories, not just file types.** `excludedFileTypes` won't stop descent into `node_modules`, `.git`, or deeply nested trees. If the API supports path/directory exclusions (e.g., `excludedPaths`, `excludedDirs`, `maxDepth`), use those to cap recursion.

3. **Raise the stack limit.** As a workaround:

```bash
ulimit -s 16384   # or: ulimit -s unlimited
```

For a systemd service, set `LimitSTACK=16M` in the unit file. Note: this only helps the main thread — worker threads get their stack size from the runtime, so also check runtime-specific flags if applicable (`-Xss4m` for Java/JNI, `--stack-size` for Node, `RUST_MIN_STACK=8388608` for Rust, `threading.stack_size()` for Python).

4. **Flatten the input.** Point `context()` at a shallower root or pass an explicit file list instead of a directory, bypassing native recursion entirely.

5. **Update zvec.** Unbounded recursion in traversal is a genuine library bug — check the issue tracker and changelog. If you're on the latest release, file an issue with the backtrace and a minimal repro; the fix on their side is converting the recursion to an iterative walk with an explicit heap-allocated stack.

If none of the recursion signs show up in the backtrace, the overflow may instead be a single huge stack allocation (large fixed buffer in the native frame) — in that case, only raising the stack limit (fix 3) or a library patch will help.

Accepted Answer

크래시는 `excludedFileTypes`가 수천 개의 `file_id = ... OR ...` 조건자로 확장되고, 네이티브 `sqlengine::QueryNode` 파서가 스택이 오버플로될 때까지 이들을 재귀적으로 처리하기 때문에 발생합니다. 이 문제는 긴 OR 표현식에 대한 처리를 추가한 pull request #694에서 수정되었으며, 다음 릴리스에 포함될 예정입니다. 해당 릴리스가 제공되면 `@zvec/zvec`, Linux x64 바인딩, `@zvec/zvec-grep`을 업그레이드하세요. 예: `npm install @zvec/zvec@latest @zvec/bindings-linux-x64@latest @zvec/zvec-grep@latest`. `@zvec/zvec@0.7.0` 및 `@zvec/zvec-grep@0.2.1`과 같이 영향을 받는 버전에서는 임시 해결 방법으로 `session.context()`에서 `excludedFileTypes`를 생략하고 검색 후 JavaScript에서 제외된 파일 유형을 필터링하거나, 쿼리가 포함하는 파일 수를 줄이세요.

Question 4

IVF `n_iters`가 무시되어 KMeans가 기본 반복 횟수를 사용하는 문제를 해결하는 방법

Accepted Answer

이것은 파라미터 전파(propagation) 버그였습니다: `IVFIndexParam::n_iters`가 IVF 파라미터까지는 전달되었지만 1단계 KMeans/OptKMeans 클러스터러로는 전달되지 않아, 클러스터링이 기본 반복 횟수를 사용했습니다. PR `fix(core): IVF n_iters propagation to clusterer`(issue #729)가 포함된 릴리스로 업그레이드하거나, 소스에서 빌드하는 경우 해당 PR을 cherry-pick하세요. 이 수정은 `n_iters`를 1단계 클러스터링 파라미터로 전달하며, 빌더 파라미터 전파에 대한 회귀 테스트 커버리지도 포함합니다.

Question 5

왜 zvec Collection.optimize()가 upsert 또는 delete 후에 벡터가 누락되거나 잘못된 벡터가 발생하나요?

Accepted Answer

이것은 zvec 0.6.0 및 0.7.0에서 알려진 인덱스 재구축 버그입니다. `optimize()`가 대체된 행을 제거할 때 벡터 파일은 활성 문서 수를 기준으로 재구축되지만, 조회는 여전히 원래 세그먼트 행 ID를 사용합니다. K개의 삭제/덮어쓰기된 행이 있는 경우 마지막 K개의 활성 벡터가 파일 끝을 넘어 읽히게 되고, 이후 문서 ID도 잘못된 벡터에 매핑될 수 있습니다. 일반적인 로그에는 `Read vector failed`, `Failed to fetch vector`, `vector indexer fetch failed`가 포함됩니다.

영향받는 버전에서의 해결 방법:
1. `upsert()` 업데이트 또는 `delete()` 작업을 수행한 후 `Collection.optimize()`를 호출하지 마십시오.
2. `optimize()`가 이미 실행된 경우, 최적화 전에 생성된 백업에서 복원하거나, 동일한 스키마로 새 컬렉션을 생성하고 소스 데이터에서 모든 활성 문서를 다시 upsert하십시오.
3. `preserve vector row mapping when rebuilding indexes with deleted rows` 수정 사항(issue #724에 대한 수정)이 포함된 zvec 릴리스로 업그레이드하십시오. `python -m pip install -U zvec`을 실행한 다음, 릴리스 노트에 해당 수정 사항이 포함되어 있는지 확인하십시오.
4. 업그레이드 후, 이전에 `optimize()`로 인해 손상된 컬렉션을 재구축하거나 다시 가져오십시오. 업그레이드만으로는 이미 잘못된 벡터 매핑이 복구되지 않을 수 있습니다.

`stats.doc_count`와 스칼라 스캔은 벡터 검색에서 누락된 문서도 여전히 보고할 수 있으므로, 스칼라 결과와 벡터를 포함한 `fetch()`를 모두 확인하여 복구를 검증하십시오.

zvec

개요

README 미리보기

FAQ (5)

同类型项目

browser-use

puppeteer

manim

PaddleOCR