[Bug]: Crashes when try to delete column

[kraai]

What did you do?

1. Created a database with the following schema: CREATE TABLE "test" ("foo" TEXT, "bar" TEXT, FOREIGN KEY("bar") REFERENCES "test"("foo"));.
2. Select the "test" table.
3. Select Modify Table.
4. Select "bar" row.
5. Select Remove.
6. Select Yes.

What did you expect to see?

I expected that the bar column would be removed from the test table.

What did you see instead?

DB Browser for Sqlite crashed.

DB4S Version

3.13.1

What OS are you seeing the problem on?

MacOS

OS version

Tahoe 26.1

Relevant log output

Prevention against duplicate issues

• I have searched for similar issues

[chrisjlocke]

So you add a column which references a column in the same table? That's not how foreign keys work.
Admittedly db4s shouldn't crash but equally you shouldn't be giving it seizures!
A foreign key is meant to reference a column in another table.
db4s is getting awfully confused.

[kraai]

The crash doesn't seem to require a self-referencing foreign key, but rather just a foreign key constraint that refers to the column that's being removed. Removing the c2 column from t1 fails with any of the following schema:

CREATE TABLE t1 (c1, c2, FOREIGN KEY(c2) REFERENCES t2(c3));

CREATE TABLE t1 (c1, c2, FOREIGN KEY(c2) REFERENCES t2(c3));
CREATE TABLE t2 (c3);

CREATE TABLE t1 (c1, c2 REFERENCES t2(c3));

CREATE TABLE t1 (c1, c2 REFERENCES t2(c3));
CREATE TABLE t2 (c3);

With the first two schema, trying to drop the column using the command-line sqlite3 outputs Runtime error: error in table t1 after drop column: unknown column "c2" in foreign key definition.

[kraai]

Here's the top of the backtrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000100023d94 DB Browser for SQLite`bool std::__1::__tree_is_left_child[abi:ne200100]<std::__1::__tree_node_base<void*>*>(__x=0x000000016fdfc6d8) at __tree:109:33
    frame #1: 0x0000000100023d00 DB Browser for SQLite`std::__1::__tree_end_node<std::__1::__tree_node_base<void*>*>* std::__1::__tree_next_iter[abi:ne200100]<std::__1::__tree_end_node<std::__1::__tree_node_base<void*>*>*, std::__1::__tree_node_base<void*>*>(__x=0x000000016fdfc6d8) at __tree:197:11
    frame #2: 0x000000010008a8c4 DB Browser for SQLite`std::__1::__tree_iterator<std::__1::__value_type<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>, std::__1::shared_ptr<sqlb::ForeignKeyClause>>, std::__1::__tree_node<std::__1::__value_type<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>, std::__1::shared_ptr<sqlb::ForeignKeyClause>>, void*>*, long>::operator++[abi:ne200100](this=0x000000016fdf9bb0) at __tree:746:9
    frame #3: 0x000000010007052c DB Browser for SQLite`std::__1::__map_iterator<std::__1::__tree_iterator<std::__1::__value_type<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>, std::__1::shared_ptr<sqlb::ForeignKeyClause>>, std::__1::__tree_node<std::__1::__value_type<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>, std::__1::shared_ptr<sqlb::ForeignKeyClause>>, void*>*, long>>::operator++[abi:ne200100](this=0x000000016fdf9bb0) at map:882:5
    frame #4: 0x00000001001ca350 DB Browser for SQLite`sqlb::Table::removeKeyFromAllConstraints(this=0x000000016fdfc660, key="c2") at sqlitetypes.cpp:524:63

Stepping through the debugger, it is set to container.end() by line 504. The comment on line 515 implies that the return statement on line 517 stops iterating, but it really just returns from the lambda expression. When the process does try to advance the iterator, it crashes because the iterator is already container.end().