Description of problem: Fails to build on ARM, failing on bad va_list usage in sql-common/client_plugin.c;add_plugin /builddir/build/BUILD/mysql-5.5.15/sql-common/client_plugin.c: In function 'mysql_client_plugin_init': /builddir/build/BUILD/mysql-5.5.15/sql-common/client_plugin.c:247:5: error: incompatible type for argument 5 of 'add_plugin' /builddir/build/BUILD/mysql-5.5.15/sql-common/client_plugin.c:120:1: note: expected 'va_list' but argument is of type 'int' /builddir/build/BUILD/mysql-5.5.15/sql-common/client_plugin.c: In function 'mysql_client_register_plugin': /builddir/build/BUILD/mysql-5.5.15/sql-common/client_plugin.c:305:5: error: incompatible type for argument 5 of 'add_plugin' /builddir/build/BUILD/mysql-5.5.15/sql-common/client_plugin.c:120:1: note: expected 'va_list' but argument is of type 'int' Version-Release number of selected component (if applicable): mysql-5.5.15-1.fc15 How reproducible: Steps to Reproduce: 1. Try to build on arm, probably other arches as well 2. (do not know why it works on primary arch, should not I think) 3. Actual results: Build failure Expected results: Successful build. Additional info: ARM patches attached. The arm secondary arch needs an koji F15 build with these patches merged to reference as the nvr for the release.
Created attachment 527197 [details] Correct va_list arguments in client_plugin.c add_plugin calls.
Mph. I should think that on most architectures, va_list is going to be a pointer type, and "0" is a reasonable representation of NULL. What kind of type is it on ARM? The proposed patch doesn't excite me at all, because it's going to result in passing uninitialized data to add_plugin, leading at the very least to compiler warnings, and perhaps to indeterminate behavior.
No idea how va_list is actually represented on ARM. It's a GCC builtin type. # 40 "/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.1/include/stdarg.h" 3 4 typedef __builtin_va_list __gnuc_va_list; # 102 "/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.1/include/stdarg.h" 3 4 typedef __gnuc_va_list va_list;
Pretty much the exact same change was committed to maria db in January. http://lists.askmonty.org/pipermail/commits/2011-January/001075.html with a little discussion at https://bugs.launchpad.net/maria/+bug/700982
But yes I agree that it's not good to pass va_args uninitialized. But it's not really used by these plugins is it? I see three possible ways: a) initialize the dummy by using memset memset(&dummy, 0, sizeof(dummy)); b) initialize the dummy with an initializer va_list dummp = {0}; C) Restructure the code slightly so that a va_list can be built using va_start by wrapping the using code in a variadic function. of which alternative c is the more correct but also most intrusive.
Well, (b) is right out since it makes just as many assumptions about the representation of va_list as the existing code does (and in fact will fail on all architectures on which the existing code works). I was thinking about (a) myself. I agree (c) is more work than it's worth.
Filed upstream at http://bugs.mysql.com/bug.php?id=62769
(In reply to comment #0) > The arm secondary arch needs an koji F15 build with these patches merged to > reference as the nvr for the release. I've committed the patch into f15 git, but I'm disinclined to push a build there since it doesn't have any actual effect on the supported architectures. Do you really need a build, or just a commit?
mysql-5.5.16-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/mysql-5.5.16-3.fc16
Thanks. Unfortunately looks like there is some more changes needed. The build is also failing on the perfschema.func_mutex and perfschema.func_file_io test cases.
mysql-5.5.16-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
We tried building mysql-5.5.18-1 on a PandaBoard (ARM-OMAP), but see two test failures in: suite/perfschema/t/func_file_io.test --------------------------------------- SELECT * FROM t1 WHERE id = 1; id b 1 initial value SET @before_count = (SELECT SUM(TIMER_WAIT) FROM performance_schema.events_waits_history_long WHERE (EVENT_NAME = 'wait/io/file/myisam/dfile') AND (OBJECT_NAME LIKE '%t1.MYD')); SELECT IF(@before_count > 0, 'Success', 'Failure') has_instrumentation; has_instrumentation Failure SELECT * FROM t1 WHERE id < 4; id b 1 initial value 2 initial value 3 initial value SET @after_count = (SELECT SUM(TIMER_WAIT) FROM performance_schema.events_waits_history_long WHERE (EVENT_NAME = 'wait/io/file/myisam/dfile') AND (OBJECT_NAME LIKE '%t1.MYD') AND (1 = 1)); SELECT IF((@after_count - @before_count) > 0, 'Success', 'Failure') test_ff1_timed; test_ff1_timed Failure --------------------------------------- All other tests pass. I'm not really sure how to debug this further. The build was done through mock, but we have retained the logs if you need further information. Please let me know if we need to file this as a separate bug.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping