invalid pointer pairs are when the length/memory of one string are
intermixed with another.
For comp_err, the end null pointer was compared to soffset within
my_strtoll10. As we didn't need the end position a NULL arg option
was compatble.
For uca-dump, Address Sanitizer raises invalid pointer pair because
argv options (opt) don't have an obvious correlation of having a start
at opt_X.length, even though the lstrncmp makes this true.
The DBUG_ASSERTS of strmov (added MDEV-11752) where incompatible with
pointer-compare. Replaced strmov with static inline version in
m_string.h using memmove that allows overlaps, and being inline allows
the uneeded parts of the implementation to be optimized away.
Despite the JSON spec rfc8259/#section-4
"The names within an object SHOULD be unique"[1], it does happen.
As our sort algorithm has access to both key and value,
if the key matches, sort by the value. The type, and length of
objects, strings, arrays and numbers is easy, so use those as a
first comparision point.
[1] https://www.rfc-editor.org/info/rfc8259/#section-4
a90779098b changed the
interface to the json_valid to take a json_engine_t
so that it could be interupted and so that warnings
could become visible.
On merge from that 10.11 to 11.4 it was discovered
that the ColumnStore engine uses this interface.
Restored the original json_valid function exactly
how ColumnStore expects this and added renamed
the function with json_engine_t to be json_valid_engine.
This follows the same convention as in the commit
756fc6fd9a that was
for json_normalize, that ColumnStore also used.
a90779098b changed the
interface to the json_valid to take a json_engine_t
so that it could be interupted and so that warnings
could become visible.
On merge from that 10.11 to 11.4 it was discovered
that the ColumnStore engine uses this interface.
Restored the original json_valid function exactly
how ColumnStore expects this and added renamed
the function with json_engine_t to be json_valid_engine.
This follows the same convention as in the commit
756fc6fd9a that was
for json_normalize, that ColumnStore also used.
14c16e02b2 changed the
interface for json_normalize to take a json_engine_t so that
there could be some error checking.
Unfortunately ColumnStore depended on this interface.
Restored original interface of json_normalize() and
added a json_normalize_engine() that take as engine as the
argument.
14c16e02b2 changed the
interface for json_normalize to take a json_engine_t so that
there could be some error checking.
Unfortunately ColumnStore depended on this interface.
Restored original interface of json_normalize() and
added a json_normalize_engine() that take as engine as the
argument.
JSON_CONTAINS, JSON_EQUALS, and JSON_OVERLAPS used raw byte-level
comparison (memcmp) for JSON string values, which meant semantically
equivalent strings like "A" and "\u0041" were incorrectly treated
as different.
Fix: add json_string_compare() that decodes Unicode escape sequences
before comparing, and fix json_normalize to produce a canonical form
for strings with escapes so JSON_EQUALS works correctly.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.
Or max_statement_time limit.
Change the json_valid to take a json_engine_t argument.
Adjust the Item_json_valid to have a json_engine_t and
to report an error.
Note this means that invalid json syntax now has a
note on any json error. Raising this to a warning can
cause check constraints of JSON_VALID() to result
in ER_JSON_SYNTAX rather than ER_CONSTRAINT_FAILED
(valided in main.type_json test).
Consequential changes in debug build to json acl
testing validation and unit test having a dummy json_engine_t.
json_normalize also uses the same engine that was
passed as its argument to test json_valid. Because
the character set may have changed, if there's an error
adjust the je->s.c_str pointer. Its only the offset that
is currently used in the error messages anyway so there
may be offset errors depending on the original character
set.
Or max_statement_time limit.
JSON_EQUAL/JSON_NORMALIZE also didn't report warnings
on invalid JSON inputs.
Change the json_normalize function to take a json_engine_t
as a argument and implement the sql/item_jsonfunc.cc calls
to have a json_engine_t.
To the JSON_EQUALS and JSON_NORMALIZE, add error handling
to produce an error when there was one. compare_nested_object,
part of JSON_OVERLAPS, uses a new json_engine and
copies the error/position to the returning function.
json_normalize expects the incoming je structure to have
a valid, or nullptr, killed_ptr, as json_start will reset this.
Issue:
For unknown error numbers, BSD-derived libc (macOS, FreeBSD, ...) formats
"Unknown error: <n>" with a colon, while glibc uses "Unknown error <n>".
my_strerror()'s colon-stripping (MDEV-35578) was gated on __APPLE__ only,
so FreeBSD output diverged from the .result.
Solution:
Normalize by behavior instead of by platform: always strip the colon after
"Unknown error". glibc never emits it, so it is a no-op there, and
macOS/FreeBSD/other BSD libc are all covered without enumeration. This is
what MDEV-35578 already intended ("consistent across the platforms ...
when present"); the __APPLE__ guard was just narrower than that intent.
Runs only in the unknown-error path.
Problem:
my_mb_wc_filename() decodes the my_charset_filename '@HHHH' escape, which
is 5 bytes, but the length guard only required 4 (s[0..3]) before the hex
branch read the 4th hex digit at s[4]. A truncated escape whose end
pointer sits at s+4 (reachable through well_formed_length()/charpos() on a
my_charset_filename string with a tight, non-terminated bound) read one
byte past e.
Fix/Solution:
A 4-byte escape is not valid, so require all 5 bytes up front: s + 5 > e
now returns MY_CS_TOOSMALL5. The read of s[4] keeps the s[3] guard,
because 'e' may be fake (see the strconvert() note above the function):
a NUL-terminated input such as "@00\0" with an over-long end must still
stop at the terminator instead of reading s[4]. Added a strings-t case
covering both the tight-end (MY_CS_TOOSMALL5) and the NUL-terminated
(MY_CS_ILSEQ) truncations.
Problem:
With `div_precision_increment=0`, a division whose quotient rounds
away to zero (e.g. -299/450) produced a decimal with no digit words
(intg=0 and frac=0) while still keeping the sign bit set. That is a
malformed value.
Multiplying such a malformed zero value by another zero reached the
negative-zero check in `decimal_mul`, where there were no digit words
to scan, leading to assertion failure.
Fix:
Fix `do_div_mod`, which produced the malformed zero. `do_div_mod`
already normalizes this case to a canonical zero on the modulo path;
do the same on the division path: when the quotient has no digits
(intg0 = 0 && frac0 = 0) return a correct decimal zero instead of a
digit-less, signed value.
Problem:
When converting a string like '-9223372036854775808' to an integer,
the parsed magnitude (2^63) equals `(ulonglong) LONGLONG_MIN` and is
accepted as valid. The return expression then cast it to signed
(LONGLONG_MIN) and negated it. Negating LONGLONG_MIN is signed integer
overflow, i.e. undefined behaviour.
Fix:
Handle the boundary value explicitly. When the parsed magnitude equals
`(ulonglong) LONGLONG_MIN`, return LONGLONG_MIN directly. Any smaller
magnitude fits in a positive longlong, so the existing cast and
negation stay well defined.
Backport from 11.4 commit - f552febe43
Problem:
When `my_charpos_mb()` is called with pos = end = NULL and the string
has fewer than `length` characters, the `end + 2 - start` return
expression evaluates `end+2`, forming the pointer NULL+2. Offsetting
a null pointer is undefined behavior.
Fix:
Compute the integer difference before adding the offset. The result is
identical but no invalid pointer is ever formed.
Or max_statement_time limit or MAX_DEPTH.
Correct interuptability and depth checking of:
* JSON_CONTAINS
* JSON_CONTAINS_PATH
* JSON_EXISTS
* JSON_EXTRACT
* JSON_KEYS
* ST_GeomFromGeoJSON
Populate in the json library the killed as a specific
error message. As the json library has a killed_ptr
is approprate it handles it.
As json_report_error now processes the killed there's
no need of thd->check_killed().
Verified that the path after every json_scan_next, the
location of checking the killed_ptr, reports errors
correctly.
Backport to 10.6 without JSON_OVERLAPS
The json_engine killed_ptr was of type uchar however the enum
in the server is dependant on the architecture. On big-endian
architectures like IBM Z, retreiving a uchar* retreived the
unmodifed part of the THD->kill enum location and was always 0.
As C++11 allows enums to inherit a type, used uint32_t as the base
class of killed_state type in the server and used uint32_t in the
json library.
reload_acl_and_cache required an expression change to avoid
the compile error:
sql/sql_reload.cc:472:24: error: enumerated and non-enumerated
type in conditional expression [-Werror=enum-conversion]
472 | return result || (thd ? thd->killed : 0);
Added the kill_ptr assignment the following functions can be
killed:
* Item_func_json_depth::val_int
* Item_func_json_type::val_str
* Item_func_json_length::val_int
Item_func_json_array_append::val_str, check_killed() only applied
to json_error: label and not return_null.
Item_func_json_format::val_str(), corresponding to the SQL,
json_compact, json_detailed, json_loose - add debug instrumentation
for the func_json_notembedded test.
MDEV-26726 (fcd345de48) added a json_pause_execution sync point
however the test case used debug_max_statement_time, which doesn't
exist. Fix the sync point name in the test.
This patch to mysqldump is only merged partially:
commit 666ff1db36
Author: Monty <monty@mariadb.org>
Date: Fri May 15 16:39:35 2026 +0300
MDEV-39519 Change mariadb-dump to use SHOW REPLICA STATUS instead of SHOW SLAVE STATUS
The functionality for --dump-slave cannot be merged as the underlying
functionality was removed in this commit:
commit 21c940d599
Author: ParadoxV5 <paradox.ver5@gmail.com>
Date: Thu Dec 4 21:22:20 2025 -0700
MDEV-37146 mariadb-dump: Replace SHOW SLAVE STATUS usage with information_schema.SLAVE_STATUS
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
The json_engine killed_ptr was of type uchar however the enum
in the server is dependant on the architecture. On big-endian
architectures like IBM Z, retreiving a uchar* retreived the
unmodifed part of the THD->kill enum location and was always 0.
As C++11 allows enums to inherit a type, used uint32_t as the base
class of killed_state type in the server and used uint32_t in the
json library.
reload_acl_and_cache required an expression change to avoid
the compile error:
sql/sql_reload.cc:472:24: error: enumerated and non-enumerated
type in conditional expression [-Werror=enum-conversion]
472 | return result || (thd ? thd->killed : 0);
Added the kill_ptr assignment the following functions can be
killed:
* Item_func_json_depth::val_int
* Item_func_json_type::val_str
* Item_func_json_length::val_int
Item_func_json_array_append::val_str, check_killed() only applied
to json_error: label and not return_null.
Item_func_json_overlaps::val_bool ensure check_killed() is called.
Item_func_json_format::val_str(), corresponding to the SQL,
json_compact, json_detailed, json_loose - add debug instrumentation
for the func_json_notembedded test.
MDEV-26726 (fcd345de48) added a json_pause_execution sync point
however the test case used debug_max_statement_time, which doesn't
exist. Fix the sync point name in the test.
Analysis:
When json is being parsed, the step decreases without a out-of-bound check
resulting in failure.
Fix:
Before decreasing the step, check if it will result into out of bound.
json_get_path_start() set p->last_step to p->steps - 1, creating a
pointer before the beginning of the steps[] array. This is undefined
behavior flagged by UBSAN as "index -1 out of bounds for type
json_path_step_t[32]".
Use NULL as the sentinel value instead, and check for NULL in
json_get_path_next() rather than comparing against p->steps.
Backport to 10.6 of commit 4f546897b8.
Additional test case from Rucha Deodhar
Signed-off-by: Varun Deep Saini <varun.23bcs10048@ms.sst.scaler.com>
Signed-off-by: Varun Deep Saini <deepsainivarun@gmail.com>
json_get_path_start() set p->last_step to p->steps - 1, creating a
pointer before the beginning of the steps[] array. This is undefined
behavior flagged by UBSAN as "index -1 out of bounds for type
json_path_step_t[32]".
Use NULL as the sentinel value instead, and check for NULL in
json_get_path_next() rather than comparing against p->steps.
Signed-off-by: Varun Deep Saini <varun.23bcs10048@ms.sst.scaler.com>
Signed-off-by: Varun Deep Saini <deepsainivarun@gmail.com>
Fix multiplication correctly - by truncating long factors before
multiplication. Not both equally, but in a way that minimizes the
error.
Add more multiplication tests to verify that now multiplication
works correctly.
Revert "MDEV-17256 Decimal field multiplication bug." (57898316b6)
It removes zero truncation from decimal_mul() and fixes
reported symptoms.
But reintroduces multiplication bug.
