Repository navigation
mysql2: a text column intermittently reads back as a wrong value (617 for 'hi') with a mysql_native_password user #11341
Description
Found while validating #11335 on perrymaster (Linux x86_64) against a private MySQL 8.0.46, with mysql2 3.24.4. The oracle is Node 26.5.1.
A string column sometimes comes back as the wrong value. SELECT 1 + 1 AS two, 'hi' AS s through mysql2/promise connection.query sometimes prints 2 617 instead of 2 hi.
- It happened in 11 of 15 runs with a
mysql_native_passworduser and 0 of 15 with acaching_sha2_passworduser. Node was correct every time. - It reproduces on main (fcac18a) without the mysql2 segfaults in createConnection on Linux (3.24.4 / 3.23.2, compiled from source) #11335 fix. To get past that crash, I made iconv-lite's
encodings/utf7.jstable usenew Array(256). With that change, main showed the wrong value in 7 of 10 runs. So this is not caused by the mysql2 segfaults in createConnection on Linux (3.24.4 / 3.23.2, compiled from source) #11335 fix. - The rest of the session matched Node in those runs: parameters, transactions, error codes,
Pool, and a pool-connection transaction. - mysql2 builds its row parsers with
generate-function/new Function. Perry runs these in the runtime interpreter (runtime: dynamic code evaluation (new Function) for schema-codegen libs (ajv / fast-json-stringify / find-my-way) — blocks kimi-code #6559), so that is the first place I would look.
Repro:
import mysql from "mysql2/promise";
const c = await mysql.createConnection({ host: "127.0.0.1", port: 43306, user: "perry_native", password: "perry", database: "perry_test" });
const [r] = (await c.query("SELECT 1 + 1 AS two, 'hi' AS s")) as any;
console.log(r[0].two, r[0].s); // node: 2 hi
await c.end();The user was created with CREATE USER 'perry_native'@'%' IDENTIFIED WITH mysql_native_password BY 'perry'. The build was PERRY_NO_AUTO_OPTIMIZE=1, and the program was run in a loop. I have not reduced it further.
Activity
proggeramlug commentedon Sep 26, 2026
This no longer reproduces on current main. Bisected on perrymaster against a live MySQL 8.0.46 with mysql2 3.24.4 and a
mysql_native_passworduser. Every arm carries #11366's patch, because without it mysql2 segfaults at connect.SELECT 1 + 1 AS two, 'hi' AS smatched NodeThe fix lies in the #11297 series ("class captures live in the class environment, not on instances"), in the range cef4301..3f6eb6c. The intermediate commits in that range do not compile on their own, so git bisect cannot narrow it further.
What the wrong value was:
617is exactly whatpacket.parseLengthCodedIntmakes of the byteshi:(0x68-48)*10 + (0x69-48) = 617. So thescolumn was read with the integer reader. The generatedTextRowparser source was correct (result["s"] = packet.readLengthCodedString(fields[1].encoding)), so the wrong method ran at execution time.Before #11297, every class in a CommonJS module body stored its captured outer variables as hidden
__perry_cap_*keys on each instance, and that shifted the instances' layout. That is consistent with a method or slot being resolved to the wrong entry, but I have not proven it.I could not build a package-free regression test:
decodeShort, or recording the generated source) makes the bug disappear on the broken build.Packet/ generated-TextRowshape does not fail on the broken build.While doing this I found a separate latent bug: under some seeded GC schedules, mysql2 throws
TypeError: value is not a functioninCommand.execute. It is filed as #11400.I suggest closing this issue as fixed by #11297.
proggeramlug commentedon Sep 26, 2026
Correction: this is not fixed. On current main (e6ad5f3) the probe reads
2 617in 4 of 10 runs. The build isPERRY_NO_AUTO_OPTIMIZE=1with amysql_native_passworduser, and #11366 is now on main. The bisect in my previous comment found a window, cef4301..3f6eb6c, in which the bug did not show on this program. That is a change in how often it shows, not a fix. I am continuing to investigate.proggeramlug commentedon Sep 26, 2026
I found the cause and the fix is up as #11432. The
VTABLE_ICinline cache matched an entry on the method-name address alone. Thenew Functioninterpreter, which runs mysql2's generated row parser, passes each call's method name in a short-lived buffer. When a freedparseLengthCodedIntbuffer was reused at the same address forreadLengthCodedString, the cache ranparseLengthCodedIntin its place. A debug build confirmed this with a backtrace.fix(runtime): a vtable IC hit also requires the method name bytes to …