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