[MDEV-22863] compilation failure on centos74-amd64-debug Created: 2020-06-10  Updated: 2020-06-11  Resolved: 2020-06-11

Status: Closed
Project: MariaDB Server
Component/s: Compiling
Affects Version/s: 10.5
Fix Version/s: 10.5.4

Type: Bug Priority: Blocker
Reporter: Sergei Golubchik Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
is caused by MDEV-22841 ut_new_get_key_by_file is unnecessari... Closed

 Description    

/home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.5.4/storage/innobase/include/univ.i:553:35: error: conversion to ‘int’ from ‘long unsigned int’ may alter its value [-Werror=conversion]
 
 #define UT_ARR_SIZE(a) (sizeof(a) / sizeof((a)[0]))
 
                                   ^
 
/home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.5.4/storage/innobase/ut/ut0new.cc:250:56: note: in expansion of macro ‘UT_ARR_SIZE’
 
   PSI_MEMORY_CALL(register_memory)("innodb", pfs_info, UT_ARR_SIZE(pfs_info));
 
                                                        ^



 Comments   
Comment by Marko Mäkelä [ 2020-06-11 ]

I cannot repeat this with GCC 8.4.0 or GCC 9.3.0.

GCC 8.4.0 issued a different, totally bogus-looking warning to me:

10.5 d6af055c556a8b2f068c84e73d11fe461b3ad3f3

 
[4/100] Building CXX object storage/innobase/CMakeFiles/innobase.dir/fsp/fsp0space.cc.o
 
In file included from /mariadb/10.5m/storage/innobase/include/mem0mem.h:345,
 
                 from /mariadb/10.5m/storage/innobase/include/fsp0file.h:30,
 
                 from /mariadb/10.5m/storage/innobase/include/fsp0space.h:30,
 
                 from /mariadb/10.5m/storage/innobase/include/fsp0sysspace.h:29,
 
                 from /mariadb/10.5m/storage/innobase/fsp/fsp0space.cc:27:
 
In function ‘char* mem_strdupl(const char*, ulint)’,
 
    inlined from ‘void Tablespace::set_path(const char*, size_t)’ at /mariadb/10.5m/storage/innobase/include/fsp0space.h:91:23,
 
    inlined from ‘dberr_t Tablespace::add_datafile(const char*)’ at /mariadb/10.5m/storage/innobase/fsp/fsp0space.cc:217:11:
 
/mariadb/10.5m/storage/innobase/include/mem0mem.ic:465:34: warning: ‘void* memcpy(void*, const void*, size_t)’ pointer overflow between offset 0 and size [-1, 9223372036854775807] [-Warray-bounds]
 
  return(static_cast<char*>(memcpy(s, str, len)));
 
                            ~~~~~~^~~~~~~~~~~~~

The code in question did check for overflow. (The patch is a no-op, just to highlight where the code was expanded.)

diff --git a/storage/innobase/fsp/fsp0space.cc b/storage/innobase/fsp/fsp0space.cc
 
index 1ed4af86367..4bf4bf97760 100644
 
--- a/storage/innobase/fsp/fsp0space.cc
 
+++ b/storage/innobase/fsp/fsp0space.cc
 
@@ -213,7 +213,7 @@ Tablespace::add_datafile(
 
 	/* If the pathname contains a directory separator, fill the
 
 	m_path member which is the default directory for files in this
 
 	tablespace. Leave it null otherwise. */
 
-	if (dirlen > 0) {
 
+	if (dirlen) {
 
 		set_path(filepath, dirlen);
 
 	}

The problem appears to be a mismatch with the PERFORMANCE_SCHEMA ABI:

typedef void (*register_memory_v1_t)
 
  (const char *category, struct PSI_memory_info_v1 *info, int count);

Why, oh why, int instead of size_t?

Comment by Marko Mäkelä [ 2020-06-11 ]

This was affecting bld-p9-rhel7 as well. And that builder is fixed now. The -Wconversion in GCC 4.8.5 would apparently complain about the sign mismatch between int and size_t.

Generated at Thu Feb 08 09:18:03 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.