Variables out of bounds on 32bit

Even though that particular warning seem pertinent to the microslow patch it may stem from this upstream bug http://bugs.mysql.com/bug.php?id=35346 ?

Hi,

I have seen bugs like this before.

My 5 minute guess as to the nature of this bug:

Some parts of the server was compiled with BIG_TABLES define set,
other parts without... Or at least, when include/my_base.h was read,
the setting of BIG_TABLES was different. So on some files, it is a
32bit quantity, others it is a 64bit quantity... I am surprised it
hasn't lead to a crash because there are some pointers stored in
struct system_variables.

If you're using ccache, clear the cache before building from clean
again by executing "ccache -C"

Regards,
Antony

On 15 Oct 2008, at 18:16, Erik Ljungstrom wrote:

> Even though that particular warning seem pertinent to the microslow
> patch it may stem from this upstream bug
> http://bugs.mysql.com/bug.php?id=35346 ?
>
> --
> Variables out of bounds on 32bit
> https://bugs.launchpad.net/bugs/284123
> You received this bug notification because you are a member of
> OurDelta-
> developers, which is the registrant for OurDelta.
>
> Status in OurDelta - Builds for MySQL: New
>
> Bug description:
> When installing on 32bit Ubuntu Hardy and Debian Etch, the server
> issues a warning about variables that appear to default to 64bit
> integer values. These warnings are not displayed on 64bit hardy and
> etch.
>
> Setting up mysql-server-5.0 (5.0.67-d6ourdelta15) ...
> Stopping MySQL database server: mysqld.
> 081016 17:47:00 [Warning] option 'log_slow_rate_limit': unsigned
> value 18446744073709551615 adjusted to 4294967295
> 081016 17:47:00 [Warning] option 'min_examined_row_limit': unsigned
> value 18446744073709551615 adjusted to 4294967295
> Starting MySQL database server: mysqld.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ourdelta-developers
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~ourdelta-developers
> More help : https://help.launchpad.net/ListHelp

OurDelta builds don't use ccache during compile, so that won't be it.

Sounds look someone needs to delve in and see what happened. I didn't see any recent progress on http://bugs.mysql.com/bug.php?id=35346

Can someone try putting at the start of include/my_base.h

#undef BIG_TABLES
#define BIG_TABLES 1

IMHO, this setting can easily go away as it only really existed for a
world of 32bit file pointers.

Regards,
Antony.

On 15 Oct 2008, at 20:43, Arjen Lentz wrote:

> OurDelta builds don't use ccache during compile, so that won't be it.
>
> Sounds look someone needs to delve in and see what happened. I didn't
> see any recent progress on http://bugs.mysql.com/bug.php?id=35346
>
> --
> Variables out of bounds on 32bit
> https://bugs.launchpad.net/bugs/284123
> You received this bug notification because you are a member of
> OurDelta-
> developers, which is the registrant for OurDelta.
>
> Status in OurDelta - Builds for MySQL: New
>
> Bug description:
> When installing on 32bit Ubuntu Hardy and Debian Etch, the server
> issues a warning about variables that appear to default to 64bit
> integer values. These warnings are not displayed on 64bit hardy and
> etch.
>
> Setting up mysql-server-5.0 (5.0.67-d6ourdelta15) ...
> Stopping MySQL database server: mysqld.
> 081016 17:47:00 [Warning] option 'log_slow_rate_limit': unsigned
> value 18446744073709551615 adjusted to 4294967295
> 081016 17:47:00 [Warning] option 'min_examined_row_limit': unsigned
> value 18446744073709551615 adjusted to 4294967295
> Starting MySQL database server: mysqld.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ourdelta-developers
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~ourdelta-developers
> More help : https://help.launchpad.net/ListHelp

Yeah, the warnings disappear with the above preprocessor directives. Tested with an unpatched 5.0.67 tree though.

Cheers,
Erik

Erik, can you please try with http://ourdelta.org/deb/sources/MySQL-OurDelta-5.0.67.d6-src.tar.gz (non-Sail patched tree) and report back here? Thanks!

Make sure you run BUILD/autorun.sh before running configure and if you want Sphinx included, configure with --with-sphinx-storage-engine. Future builds will be done slightly differently so we first generate a patched source tree including the autorun bit, tarball of that, then stick that into the various build processes. Should be nicer.

Made full report back upstream http://bugs.mysql.com/bug.php?id=35346 also suggesting that bug is upgraded as more serious as it could be the cause of unexplained crashes.

General solution:

BIG_TABLES needs to go away, along with its autoconf m4 rules.

ha_rows should simply be typedef to system's off_t type.

New flag for my_getopt, GET_HAROWS maybe, as its size may vary on different architectures.

Check that cmd line opts which are ha_rows type are correctly using new flag instead of GET_ULONG.

(There was a similar issue years ago which lead to the creation of SHOW_HA_ROWS for system variables)

See also info and tools to check this on platforms at http://ac-archive.sourceforge.net/largefile/

MySQL bug committee has re-triaged, and changed the priority from D3 Medium to D5 Feature Request, i.e. it's been downgraded. Sinisa's comment on the issue notes that it'd be desirable to make the my.cnf params 64bit wide.

Since that may be so, it does not address the actual issue in the compile, thus I suppose we'll move forward and at least apply the quick fix that Antony devised by making sure all files get compiled with BIG_TABLES. That'll make our build safe, just in case.

After discussion, Omer has set it back to open, and others (Tim) acknowledge that it looks like a bug not a feature request and will look at it again. We'll do the patch anyway, but it might also get fixed upstream then...

The OurDelta build with patchset d7 includes Antony's patch for this.
We'll keep the patch in until MySQL decides what to do.

In OurDelta builds from patchset d7.

Tim reports that the mysql bugs team has re-triaged and given internal prio of P2, scheduled to be fixed 5.1 post-GA.