ci: add missing egl dep to sanitized ci

[dy-tea]

See CI run on 0c3183c, will wait for it to run to make sure nothing else is missing.

[dy-tea]

 FAIL  [ 392/2701] C:  2042.8 ms, R:   175.930 ms vlib/orm/orm_transaction_test.v
Uninitialized bytes in __interceptor_strcmp at offset 8 inside [0x70200000002c, 9)
==37896==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f2b2ab5dce6 in sqlite3BtreeOpen (/lib/x86_64-linux-gnu/libsqlite3.so.0+0x27ce6) (BuildId: 6c774b53d3a49e2b2e307f6f337cba326a3c447e)
    #1 0x7f2b2abd2cb3  (/lib/x86_64-linux-gnu/libsqlite3.so.0+0x9ccb3) (BuildId: 6c774b53d3a49e2b2e307f6f337cba326a3c447e)
    #2 0x56330c06cc68 in db__sqlite__connect (/tmp/v_1001/tsession_7fa488efc740_01KKA3Z2FB6XNYGBVGQXRMBBXX/391_0/orm_transaction_test+0x1bfc68) (BuildId: 5b1cf226dfc8a8f2e89a16584d9fe04e775144e1)
    #3 0x56330c0706b2 in main__setup_tx_db (/tmp/v_1001/tsession_7fa488efc740_01KKA3Z2FB6XNYGBVGQXRMBBXX/391_0/orm_transaction_test+0x1c36b2) (BuildId: 5b1cf226dfc8a8f2e89a16584d9fe04e775144e1)
    #4 0x56330c07442f in main__test_transaction_callback_commits_on_success (/tmp/v_1001/tsession_7fa488efc740_01KKA3Z2FB6XNYGBVGQXRMBBXX/391_0/orm_transaction_test+0x1c742f) (BuildId: 5b1cf226dfc8a8f2e89a16584d9fe04e775144e1)
    #5 0x56330c09c6e3 in main (/tmp/v_1001/tsession_7fa488efc740_01KKA3Z2FB6XNYGBVGQXRMBBXX/391_0/orm_transaction_test+0x1ef6e3) (BuildId: 5b1cf226dfc8a8f2e89a16584d9fe04e775144e1)
    #6 0x7f2b2a829d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #7 0x7f2b2a829e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #8 0x56330becd514 in _start (/tmp/v_1001/tsession_7fa488efc740_01KKA3Z2FB6XNYGBVGQXRMBBXX/391_0/orm_transaction_test+0x20514) (BuildId: 5b1cf226dfc8a8f2e89a16584d9fe04e775144e1)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/lib/x86_64-linux-gnu/libsqlite3.so.0+0x27ce6) (BuildId: 6c774b53d3a49e2b2e307f6f337cba326a3c447e) in sqlite3BtreeOpen
Exiting

This does not appear to be related :/

Indeed, it happens here too, likely from an orm change: https://github.com/vlang/v/actions/runs/22844849466/job/66258672741

[tankf33der]

@dy-tea - Another piece of evidence of a broken CI, but this time in orm_transaction_test.v — this is a new, fresh file, and before you noticed it, it was breaking all the time.

diff --git a/vlib/orm/orm_transaction_test.v b/vlib/orm/orm_transaction_test.v
index 5ef146528..eebce5b02 100644
--- a/vlib/orm/orm_transaction_test.v
+++ b/vlib/orm/orm_transaction_test.v
@@ -1,4 +1,4 @@
-// vtest build: present_sqlite3?
+// vtest build: present_sqlite3? && !sanitize-memory-clang
 import db.sqlite
 import orm
 

[tankf33der]

@watzon what you think about my comment above?

[JalonSolov]

I think it's better to fix the problem than to just skip the test.

[tankf33der]

I think it's better to fix the problem than to just skip the test.

This line says this is almost impossible. This is false alarm (!).

#0 0x7f2b2ab5dce6 in sqlite3BtreeOpen (/lib/x86_64-linux-gnu/libsqlite3.so.0+0x27ce6) 

The whole downside of msan is that it strictly requires all components to be built with msan, otherwise it guarantees nothing and will just spew false alarms.

[tankf33der]

I think it's better to fix the problem than to just skip the test.

This line says this is almost impossible. This is false alarm (!).

#0 0x7f2b2ab5dce6 in sqlite3BtreeOpen (/lib/x86_64-linux-gnu/libsqlite3.so.0+0x27ce6) 

The whole downside of msan is that it strictly requires all components to be built with msan, otherwise it guarantees nothing and will just spew false alarms.

I've repeated the false alarm in my lab:

This is test file:

#include <stdio.h>
#include <sqlite3.h>

int main() {
    sqlite3 *db;
    char *err = 0;

    sqlite3_open("test.db", &db); 
    const char *sql =
        "CREATE TABLE IF NOT EXISTS users ("
        "  id   INTEGER PRIMARY KEY AUTOINCREMENT,"
        "  name TEXT    NOT NULL,"
        "  age  INTEGER"
        ");"
        "INSERT INTO users (name, age) VALUES ('Alice', 30);"
        "INSERT INTO users (name, age) VALUES ('Bob',   25);";

    sqlite3_exec(db, sql, 0, 0, &err);

    const char *query = "SELECT id, name, age FROM users;";
    sqlite3_stmt *stmt;

    sqlite3_prepare_v2(db, query, -1, &stmt, 0);
    while (sqlite3_step(stmt) == SQLITE_ROW) {
        printf("id=%d  name=%s  age=%d\n",
            sqlite3_column_int (stmt, 0),
            sqlite3_column_text(stmt, 1),
            sqlite3_column_int (stmt, 2));
    }
    sqlite3_finalize(stmt);

    sqlite3_close(db);
    return 0;
}

This is library call with false alarm:

root@lambda:~/sqlite-src-3520000# clang -fsanitize=memory sq3.c -lsqlite3
root@lambda:~/sqlite-src-3520000# ./a.out 
Uninitialized bytes in strlen at offset 0 inside [0x719000000008, 33)
==25213==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f5efa5ec041 in sqlite3Strlen30 (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x103041) (BuildId: add636288837fddd792181d69db1036b3911fbe7)
    #1 0x7f5efa5aea25 in sqlite3PagerOpen (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0xc5a25) (BuildId: add636288837fddd792181d69db1036b3911fbe7)
    #2 0x7f5efa52be0c in sqlite3BtreeOpen (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x42e0c) (BuildId: add636288837fddd792181d69db1036b3911fbe7)
    #3 0x7f5efa5a3a82  (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0xbaa82) (BuildId: add636288837fddd792181d69db1036b3911fbe7)
    #4 0x55d05e4806a8 in main (/root/sqlite-src-3520000/a.out+0xd06a8) (BuildId: 6fbab1c410191b8b85ff8517416554e67b49ef94)
    #5 0x7f5efa1e6f74  (/usr/lib/x86_64-linux-gnu/libc.so.6+0x29f74) (BuildId: c9a199fd28ea54b305ea35a8b25500a79bfe684a)
    #6 0x7f5efa1e7026 in __libc_start_main (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a026) (BuildId: c9a199fd28ea54b305ea35a8b25500a79bfe684a)
    #7 0x55d05e3e3380 in _start (/root/sqlite-src-3520000/a.out+0x33380) (BuildId: 6fbab1c410191b8b85ff8517416554e67b49ef94)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x103041) (BuildId: add636288837fddd792181d69db1036b3911fbe7) in sqlite3Strlen30
Exiting

This is full recompilation of everything under MSan without problems:

root@lambda:~/sqlite-src-3520000# clang -fsanitize=memory sq3.c sqlite3.c 
root@lambda:~/sqlite-src-3520000# ./a.out 
id=1  name=Alice  age=30
id=2  name=Bob  age=25
id=3  name=Alice  age=30
id=4  name=Bob  age=25
id=5  name=Alice  age=30
id=6  name=Bob  age=25
id=7  name=Alice  age=30
id=8  name=Bob  age=25
id=9  name=Alice  age=30
id=10  name=Bob  age=25

[JalonSolov]

So, since it is a failure in sqlite, not in our code, it does indeed make sense to skip that test.

We'll just have to hope they fix sqlite, I suppose.

[JalonSolov]

#26718

[tankf33der]

So, since it is a failure in sqlite, not in our code, it does indeed make sense to skip that test.

We'll just have to hope they fix sqlite, I suppose.

It is absolutely normal behavior for MSan to generate false alarms on shared objects. The entire sanitizer ecosystem, when running, operates within a single memory region and under full (!) control — when a shared object is fed to it, it does not understand the state of the foreign memory region and generates a false alarm. You are confusing ASan with MSan; they operate in different weight categories and cannot be compared. My real hands-on experiment demonstrated this situation, where the same thing simultaneously generates a false alarm and does not generate one.

[JalonSolov]

I'm going to merge this, as this fix is required for other tests to run correctly. Once my PR and the v2 stuff get merged, it should all (hopefully) even out.