Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Bug: Segmentation Fault During Periodic Read-Only Ladybug Database Reconnection

Aperta
  • Qualcosa non va?
#1,007 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
cpp, python
Ambito
databases

Direzione di ricerca

Start with ladybug/database.py around init_pybind_database, then trace the follower_refresh_loop to _refresh_follower_main_database and _open_main_database. Review the static core dump and logs alongside the repeated read_pool_generation changes and checkpoint/WAL errors. Done means the native crash has a reproducible diagnosis and the reconnect behavior is validated under concurrent checkpoint/WAL activity.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
Ladybug version

main

What operating system are you using?

ubuntu24.04

What happened?

Conclusion: This was not an OOM event. It was a SIGSEGV (segmentation fault) triggered by the LadybugDB native. The most likely cause is a concurrency or lifecycle race between repeatedly reopening the read-only database, closing old connection pools, and concurrent checkpoint/WAL operations.

Key evidence:

  • The log explicitly reports:

    Fatal Python error: Segmentation fault

  • The crashing thread was in:

    ladybug/database.py -> init_pybind_database

    Call chain:

    follower_refresh_loop -> _refresh_follower_main_database -> _open_main_database -> Ladybug Database initialization

    This indicates that the crash occurred in Ladybug’s native/pybind layer, rather than in normal Python application code.

  • The database was repeatedly reconnected, approximately once every 15 seconds. The read_pool_generation increased from 1 to 19. Each refresh performed the following operations:

    1. Opened the same main_ontology.lbug database.
    2. Created 8 read connections.
    3. Switched the active connection pool.
    4. Closed the previous database instance.

  • Before the crash, the log showed database-file concurrency/state errors:

    • Cannot open database in read-only mode while checkpoint is in progress
    • Cannot open file ... main_ontology.lbug.wal: No such file or directory

    These errors indicate that the database was being opened for reading while its files may have been changing due to a checkpoint, WAL removal/rotation, or another process modifying the database.

  • Memory usage did not reach the container limit:

    • cgroup memory limit: 16 GiB
    • Last recorded cgroup usage: approximately 2.31 GiB
    • Process RSS: approximately 1.97 GiB
    • Memory monitor status: normal

    Therefore, this does not resemble a Kubernetes OOM kill. An OOM kill normally results in OOMKilled and exit code 137, while a segmentation fault commonly results in exit code 139.

Most likely failure sequence:

Checkpoint/WAL state changes
        ↓
Read-only database opening fails and triggers retries
        ↓
Repeated open + connection-pool switch + close operations every 15 seconds
        ↓
A thread-safety or resource-lifecycle issue occurs in the Ladybug native layer
        ↓
SIGSEGV / core dump

Based on the current logs, it can be confirmed that the segmentation fault occurred during Ladybug native database initialization. The strongest suspected root cause is frequent read-database reconnection while checkpoint/WAL operations are changing the same database files, causing a thread-safety or resource-release issue in the native layer.

Are there known steps to reproduce?

I’m not sure how to go about fixing this issue. Every time I observe the problem, I only get a static core dump, and I cannot reproduce the failure reliably. As a result, it is unclear where exactly the root cause lies. Could you share some suggestions and troubleshooting ideas? @adsharma

Lingua principale
C++
Stelle
1.8k
Fork
148
Merge medio
14h 57m
PR unite (30g)
124

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di LadybugDB/ladybug

Tutte le issue di LadybugDB/ladybug

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.