Segmentation Fault in SQLite Triggered by INSERT with Conflicting ON CONFLICT Clauses

---

Understanding the Segfault in SQLite During Trigger Execution with Conflicting Conflict Resolution Policies

Root Cause: Incorrect Byte-Code Generation for INSERT with Overlapping ON CONFLICT Clauses

The core issue arises when an SQLite database table is defined with both an INTEGER PRIMARY KEY column that includes an ON CONFLICT REPLACE clause and a separate UNIQUE constraint on another column. A trigger that performs an INSERT operation on this table with its own ON CONFLICT (column) DO NOTHING clause can cause a segmentation fault (SEGV) when conflicting rows are encountered during execution. This occurs due to incorrect byte-code generation in SQLite versions 3.35.0 and later, specifically when the INSERT statement within the trigger attempts to resolve conflicts on a column other than the INTEGER PRIMARY KEY. The faulty byte-code leads to a null pointer dereference or assertion failure during the B-tree insertion phase of query execution.

The problem is traced to a change in SQLite’s upsert handling logic introduced in check-in 6b01a24daab1e5bc, which enhanced support for upsert operations but inadvertently created a conflict resolution priority mismatch. When the INTEGER PRIMARY KEY’s ON CONFLICT REPLACE policy overlaps with the trigger’s ON CONFLICT DO NOTHING policy, the byte-code generator fails to properly prioritize or reconcile these clauses. This results in a cursor object (pC->uc.pCursor) being in an invalid state during the sqlite3BtreeInsert operation, triggering a segmentation fault.

---

Contributing Factors: Version-Specific Behavior and Schema Design Antipatterns

1. Version-Specific Behavior Changes:
   Prior to SQLite 3.23.0, the example SQL script generated a syntax error due to stricter parsing of conflicting ON CONFLICT clauses. Between versions 3.23.0 and 3.34.1, the script executed without crashing, though it may have produced unintended results. Starting with version 3.35.0, the introduction of enhanced upsert logic altered the byte-code generation process, leading to the SEGV. This version dependency highlights the importance of understanding how SQLite’s internal query planner and virtual machine (VDBE) handle conflict resolution across releases.

2. Schema Design with Overlapping Conflict Policies:
   The table definition combines an INTEGER PRIMARY KEY ON CONFLICT REPLACE with a UNIQUE constraint on another column. The ON CONFLICT REPLACE clause on the primary key applies to conflicts arising from duplicate primary key values, while the UNIQUE constraint on column a enforces uniqueness on a separate column. The trigger’s INSERT operation explicitly targets conflicts on column a with DO NOTHING, creating ambiguity in how SQLite should handle conflicts that might involve both constraints. This schema design creates a latent conflict resolution hierarchy that SQLite’s byte-code generator does not correctly resolve.

3. Trigger Logic and Recursive Execution:
   The AFTER UPDATE trigger on t1 attempts to insert a new row into the same table using new.c, new.b, and new.a. When the UPDATE statement modifies column b, the trigger fires and executes the INSERT. If the INSERT encounters a conflict on column a, the DO NOTHING clause should suppress the insertion. However, the presence of the ON CONFLICT REPLACE on the primary key introduces a race condition: the primary key’s conflict policy may attempt to replace the existing row, while the DO NOTHING clause attempts to suppress action on the UNIQUE constraint. The byte-code generator fails to account for this overlap, leading to invalid memory access.

---

Resolution: Code Fixes, Schema Refactoring, and Version Mitigation Strategies

Step 1: Apply the Official SQLite Patch
The fix for this issue was introduced in check-in 2f09b51b1ff37bf9, which modifies the byte-code generation logic in insert.c to properly handle overlapping ON CONFLICT clauses. Developers should update their SQLite library to a version that includes this patch. For those building from source, integrating the revised insert.c ensures that the VDBE generates correct instructions when resolving conflicts across multiple constraints.

Step 2: Refactor Schema to Isolate Conflict Resolution Policies
Avoid defining tables where multiple constraints have conflicting ON CONFLICT policies. For example:

• Remove the ON CONFLICT REPLACE from the INTEGER PRIMARY KEY if it is not strictly necessary.
• Use ON CONFLICT clauses consistently across constraints, or ensure they target distinct columns.
• If the primary key must retain ON CONFLICT REPLACE, refactor the trigger’s INSERT to explicitly handle primary key conflicts, even if they are unlikely.

Step 3: Modify Trigger Logic to Avoid Ambiguity
Rewrite the trigger’s INSERT statement to clarify which constraint’s conflict policy takes precedence. For instance:

CREATE TRIGGER c0 AFTER UPDATE ON t1 BEGIN
  INSERT INTO t1 VALUES(new.c, new.b, new.a)
    ON CONFLICT (a) DO NOTHING
    ON CONFLICT (c) DO NOTHING; -- Explicitly handle PK conflicts
END;

This forces the trigger to define conflict resolution for both the primary key (c) and the UNIQUE column (a), eliminating ambiguity.

Step 4: Validate with Debugging Tools
When encountering unexplained segmentation faults in SQLite:

• Compile SQLite with Address Sanitizer (ASAN) to identify memory corruption.
• Use gdb or lldb to capture backtraces and inspect register states at the crash point.
• Enable SQLite’s internal assertion checks (-DSQLITE_DEBUG) to catch logic errors during development.

Step 5: Version-Specific Workarounds
For deployments tied to SQLite 3.35.0–3.37.0 where upgrading is not immediately feasible:

• Disable triggers that perform INSERT/UPDATE operations on tables with conflicting ON CONFLICT clauses.
• Rewrite the trigger to use a temporary table or application-layer conflict resolution.

---

By addressing the byte-code generation flaw, refining schema design practices, and leveraging debugging tools, developers can mitigate this segmentation fault and prevent similar issues in future SQLite deployments.