Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL), 11.3(EOL), 11.4
Description
Even after MDEV-26272 was fixed, some problematic use of the macro my_offsetof() remains. This undefined behaviour is not flagged by GCC, but it should be flagged by clang when using cmake -DWITH_UBSAN=ON. I tried to find some examples in the log, but instead I found numerous examples of something else, such as the following:
10.4 832e96deb6f368591dcb35a4fa33b2fd770aa17a |
/mariadb/10.4/sql/sql_select.cc:3863:22: runtime error: applying non-zero offset 4054449126480 to null pointer
|
/mariadb/10.4/sql/sql_select.cc:3309:32: runtime error: applying non-zero offset 944 to null pointer
|
Curiously, the following was not flagged when I ran ./mtr --suite=perfschema:
static inline void copy_events_statements(PFS_events_statements *dest, |
const PFS_events_statements *source) |
{
|
/* Copy all attributes except DIGEST */ |
memcpy(dest, source, my_offsetof(PFS_events_statements, m_digest_storage)); |
|
/* Copy DIGEST */ |
dest->m_digest_storage.copy(& source->m_digest_storage);
|
}
|
Attachments
Issue Links
- is blocked by
-
MDEV-26272 The macro MASTER_INFO_VAR invokes undefined behaviour
- Closed
- relates to
-
MDEV-25454 Make MariaDB server UBSAN safe
- Confirmed