[Maria-developers] innobase/sync0policy.h converts opaque pthread_t to ULINT
Hi,
While trying to build on macOS 10.13.4 with clang 9.1.0 I originally came
across this error:
--
.../storage/innobase/include/sync0policy.h:79:4: error: cannot initialize a
parameter of type 'int64' (aka 'long long') with
an rvalue of type 'os_thread_id_t' (aka '_opaque_pthread_t *')
my_atomic_storelint(_thread_id,
os_thread_get_curr_id());
---
This problem was originally reported in MDEV-15778. Since pthread_t on macOS is
a pointer to a struct named _opaque_pthread_t, the "obvious" solution for this
was to explicitly cast to ULINT which in turn is defined as size_t, fine so
far. Solution was tested in PR#691.
However, upon testing my patch with buildbot, on slave kvm-fulltest2, which is
64bit qemu vm with Ubuntu precise-i386 (32bit) running and gcc compiling in
-march=i686. The above "fix" now yields:
--
/home/buildbot/buildbot/build/mariadb-10.3.6/storage/innobase/include/sync0policy.h:79:4:
error: invalid cast from type ‘os_thread_id_t {aka long unsigned int}’ to type
‘ulint {aka unsigned int}’
---
Now reconsidering more carefully, this looks more serious then initially
thought, posix pthread_t(3) is defined as:
--
POSIX.1 allows an implementation wide freedom in choosing the type used to
represent a thread ID; for example, representation using either an arithmetic
type or a structure is permitted. Therefore, variables of type pthread_t can't
portably be compared using the C equality operator (==); use
pthread_equal(3)instead.
---
So in this particular platform spec, where pthread_t on Linux is defined as
unsigned long int integral type and if LP64 model is used, this implies
pthread_t always being 64bit in either both 32 and 64 arch and trying to
convert to size_t on a 32bit arch will fail.
Now given that the standard particularly states pthread_t as being opaque and
no assumptions should be made in regards to the actual type, not even an
initializer type (which ULINT_UNDEFINED defines as -1), trying to cast
m_thread_id to any other type ( (ULINT) ) either implicitly or explicit is not
portable. Is this a bug that needs fixing or just impossible to handle pthread
id atomically in any other fashion? How about a test case I can run to
confirm/infirm erratic behavior?
Since I don't have access to the particular bb slave instance to check with
sizeof() maybe somebody else can help me here to confirm this? Relevant links
bellow:
https://jira.mariadb.org/browse/MDEV-15778
https://buildbot.askmonty.org/buildbot/builders/kvm-fulltest2/builds/12317/steps/compile/logs/stdio
https://linux.die.net/man/3/pthread_self
https://github.com/MariaDB/server/pull/691
Cheers,
Teodor
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
[Maria-developers] New Foundation Buildbot and Github build status push
Hi all, For the past 6 months we have been working on a new Buildbot deployment at: https://buildbot.mariadb.org Currently we have docker x64 builders for all supported Linux platforms (aptly named quick builders, since they all finish a build + default MTR under 40 minutes): https://buildbot.mariadb.org/#/builders We are working on adding builders for all the other supported targets in the near future as well as acquiring more building power to accommodate for --big and more extensive/complex tests. We are open to donations in that regard. Saved package artifacts can be accessed from any individual build log via the "Download" link or directly from here: https://ci.mariadb.org The configuration and associated documentation can be found in the tools repo: https://github.com/MariaDB/mariadb.org-tools/tree/master/buildbot.mariadb.org We encourage collaboration and are open to pull requests, you can do so for adding new builders, fixing build steps or adjusting the docker images available in the dockerfiles/ sub-directory, etc.. Currently we consider this deployment in beta phase and have enabled Github status push for the main repo for direct code pushes as well as pull requests. The build status shows up in the same Github widget as Travis does and you can follow any individual report to the actual buildbot log via the links. Sample report for a push: https://github.com/MariaDB/server/commits/bb-10.4-statustest Sample PR: https://github.com/MariaDB/server/pull/1034 Reproducing Linux failures are facilitated by the Dockerfiles available in the tool's repo, which are used by the Buildbot master to create the build environment on the docker enabled workers: https://github.com/MariaDB/mariadb.org-tools/tree/master/buildbot.mariadb.org#debugging-build-failures Ideally, any developer should pay attention to these build failures on Github and attempt to fix any issues before merging into the main branches. While in beta, we are trying to weed out environmental or configuration failures too, so please report those as you come by them so we can fix them. The end goal is to enable protected branches, where any individual change has to pass a certain selection of robust tests before merging, which ultimately, would ensure that the MariaDB code is in a releasable state after any individual commit. We welcome feedback, improvement suggestions and any particular questions you might have about the current setup and future plans. We will check-in from time to time as we have more goodness to show. Best regards, Teodor -- Developer, Infra MariaDB Foundation https://mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
