Hi, This is my first bug report, hope you get some god out of this. I was recommended to do a bug report: http://forums.gentoo.org/viewtopic-p-3767100.html#3767100 - - - I have problems after upgraded mysql from 4.1.21 to 5.0.26. I got bus error when using mysqldump. I used the: http://www.gentoo.org/doc/en/mysql-upgrading.xml "1. Straight upgrade, suggested for 4.1 => 5.0 migration" guide for upgrade. Netra X1 512 meg ram: linux-2.4.32-sparc-r6 Gentoo 2006.1
Please, don't refer to forums.g.o. when reporting bugs; reopen once you've posted all the relevant information here.
*** Bug 157415 has been marked as a duplicate of this bug. ***
Ok, well you tell me what u need.
In the meanvhile I post some stuff that may be useful: Current kernel: linux-2.4.32-sparc-r6 New mysql: dev-db/mysql-5.0.26-r1 Old mysql: dev-db/mysql-4.1.21 emerge -pv dev-db/mysql [ebuild R ] dev-db/mysql-5.0.26-r1 USE="berkdb latin1 perl ssl -big-tables -cluster -debug -embedded -extraengine -max-idx-128 -minimal (-selinux) -srvdir -static" cat /etc/portage/package.use dev-db/mysql innodb latin1 -utf8 cat /etc/make.conf CFLAGS="-O2 -mcpu=ultrasparc -pipe" CHOST="sparc-unknown-linux-gnu" CXXFLAGS="-O2 -mcpu=ultrasparc -pipe" USE="mysql apache2 maildir authdaemond -ipv6 -X -gtk" #ACCEPT_KEYWORDS="~sparc" I hope you find this relevant information, if not I send you, just tell me that you need. Greets
Here is my --info to: Portage 2.1.1-r2 (default-linux/sparc/sparc64/2006.0/2.4, gcc-3.4.6, glibc-2.3.6-r5, 2.4.32-sparc-r6 sparc64) ================================================================= System uname: 2.4.32-sparc-r6 sparc64 sun4u Gentoo Base System version 1.12.6 Last Sync: Sun, 03 Dec 2006 21:50:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.4.26-r1 ACCEPT_KEYWORDS="sparc" AUTOCLEAN="yes" CBUILD="sparc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=ultrasparc -pipe" CHOST="sparc-unknown-linux-gnu" CONFIG_PROTECT="/etc /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -mcpu=ultrasparc -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.gentoo.se ftp://gentoo.linux.no/pub/gentoo/ http://gentoo.linux.no/ ftp://ftp.uninett.no/pub/linux/Gentoo" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" USE="sparc apache2 arts authdaemond berkdb bitmap-fonts cli cracklib crypt cups dlloader dri eds elibc_glibc emboss encode esd fbcon foomaticdb fortran gcc64 gdbm gif gnome gstreamer gtk2 iconv imlib input_devices_keyboard input_devices_mouse isdnlog jpeg kde kernel_linux libwww mad maildir mikmod motif mpeg mysql ncurses nls ogg opengl oss pam pcre perl png pppd python qt3 readline reflection sdl session spell spl ssl tcpd truetype truetype-fonts type1-fonts userland_GNU video_cards_ati video_cards_dummy video_cards_fbdev video_cards_glint video_cards_mga video_cards_savage video_cards_sisusb video_cards_sunbw2 video_cards_suncg14 video_cards_suncg3 video_cards_suncg6 video_cards_sunffb video_cards_sunleo video_cards_tdfx video_cards_v4l video_cards_voodoo vorbis xml xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
I'm adding sparc CC and reopening. I can reproduce the error easily: fmccor@polylepis SNAKES [20]% mysqldump -A Bus error With Wed Nov 8 13:13:30 2006 >>> dev-db/mysql-5.0.26-r1 On sparc, this is typically indicative of a data alignment problem (on amd64, that mysqldump command works fine).
(And reassigning)
Add sparc CC for real.
Thanx. Works fine on intel cpu to.
(In reply to comment #9) > Thanx. Works fine on intel cpu to. > Yes. It appears to be sparc-specific data alignment problem, regression from mysql-4.1 (where it seems to work for sparc).
sorry I could not add very much to this, also looking in upstream bugzilla don't tell very much. dev-db/mysql-5.0.30 is in the tree, mind to try that one ?
No, I dont have any test server.
Still fails: Mon Dec 11 13:39:55 2006 >>> dev-db/mysql-5.0.30 fmccor@polylepis Log-Lib [45]% mysqldump -A Bus error If it helps, this is what gdb says: Program received signal SIGBUS, Bus error. 0x701acbac in mysql_options () from /usr/lib/mysql/libmysqlclient.so.15 (gdb) bt #0 0x701acbac in mysql_options () from /usr/lib/mysql/libmysqlclient.so.15 #1 0x0001736c in main () ========================== This is almost certainly a data alignment error, and should be "obvious" to upstream since it is a regression from mysql-4, but I do not have the means nor the time to trouble shoot it for them. Reopening: This is a reproducible error in the mysql-5 series.
Diffed mysql-{4.1.21,5.0.30}/libmysqld/client.c and extracted what I think are the relevant parts, without much knowledge of c look like an easy to catch bug, if someone has 5 minutes to loose on this one we can get a patch in portage much sooner. static const char *default_options[]= { "port","socket","compress","password","pipe", "timeout", "user", "init-command", "host", "database", "debug", "return-found-rows", "ssl-key" ,"ssl-cert" ,"ssl-ca" ,"ssl-capath", "character-sets-dir", "default-character-set", "interactive-timeout", "connect-timeout", "local-infile", "disable-local-infile", "replication-probe", "enable-reads-from-master", "repl-parse-query", "ssl-cipher", "max-allowed-packet", "protocol", "shared-memory-base-name", "multi-results", "multi-statements", "multi-queries", "secure-auth", "report-data-truncation", NullS }; [...] void mysql_read_default_options(struct st_mysql_options *options, const char *filename,const char *group) { int argc; char *argv_buff[1],**argv; const char *groups[3]; DBUG_ENTER("mysql_read_default_options"); DBUG_PRINT("enter",("file: %s group: %s",filename,group ? group :"NULL")); argc=1; argv=argv_buff; argv_buff[0]= (char*) "client"; groups[0]= (char*) "client"; groups[1]= (char*) group; groups[2]=0; load_defaults(filename, groups, &argc, &argv); if (argc != 1) /* If some default option */ { char **option=argv; while (*++option) { /* DBUG_PRINT("info",("option: %s",option[0])); */ if (option[0][0] == '-' && option[0][1] == '-') { char *end=strcend(*option,'='); char *opt_arg=0; if (*end) { opt_arg=end+1; *end=0; /* Remove '=' */ } /* Change all '_' in variable name to '-' */ for (end= *option ; *(end= strcend(end,'_')) ; ) *end= '-'; switch (find_type(*option+2,&option_types,2)) { case 1: /* port */ if (opt_arg) options->port=atoi(opt_arg); break; [...] case 30: options->client_flag|= CLIENT_MULTI_RESULTS; break; case 31: case 32: options->client_flag|= CLIENT_MULTI_STATEMENTS | CLIENT_MULTI_RESULTS; break; case 33: /* secure-auth */ options->secure_auth= TRUE; break; case 34: /* report-data-truncation */ options->report_data_truncation= opt_arg ? test(atoi(opt_arg)) : 1; break; default: DBUG_PRINT("warning",("unknown option: %s",option[0])); } } } } free_defaults(argv); DBUG_VOID_RETURN; } [...] int STDCALL mysql_options(MYSQL *mysql,enum mysql_option option, const char *arg) { DBUG_ENTER("mysql_option"); DBUG_PRINT("enter",("option: %d",(int) option)); switch (option) { case MYSQL_OPT_CONNECT_TIMEOUT: mysql->options.connect_timeout= *(uint*) arg; break; case MYSQL_OPT_READ_TIMEOUT: mysql->options.read_timeout= *(uint*) arg; break; [...] /* THE FOLLOWING PART HAS BEEN ADDED SINCE MYSQL-4.1.21 fmccor@polylepis Log-Lib [45]% mysqldump -A Bus error If it helps, this is what gdb says: Program received signal SIGBUS, Bus error. 0x701acbac in mysql_options () from /usr/lib/mysql/libmysqlclient.so.15 (gdb) bt #0 0x701acbac in mysql_options () from /usr/lib/mysql/libmysqlclient.so.15 #1 0x0001736c in main () ========================== This is almost certainly a data alignment error, and should be "obvious" to upstream since it is a regression from mysql-4, but I do not have the means nor the time to trouble shoot it for them. */ [...] case MYSQL_REPORT_DATA_TRUNCATION: mysql->options.report_data_truncation= test(*(my_bool *) arg); break; case MYSQL_OPT_RECONNECT: mysql->reconnect= *(my_bool *) arg; break; case MYSQL_OPT_SSL_VERIFY_SERVER_CERT: if (!arg || test(*(uint*) arg)) mysql->options.client_flag|= CLIENT_SSL_VERIFY_SERVER_CERT; else mysql->options.client_flag&= ~CLIENT_SSL_VERIFY_SERVER_CERT; break; default: DBUG_RETURN(1); } DBUG_RETURN(0); }
Yes, after building with '-g' and playing around some, the error seems to be here: 0x701acc2c in mysql_options (mysql=0x2df18, option=MYSQL_OPT_SSL_VERIFY_SERVER_CERT, arg=0x2deba "") at client.c:2954 which is: 2953 case MYSQL_OPT_SSL_VERIFY_SERVER_CERT: 2954 if (!arg || test(*(uint*) arg)) 2955 mysql->options.client_flag|= CLIENT_SSL_VERIFY_SERVER_CERT; with #0 0x701acc2c in mysql_options (mysql=0x2df18, option=MYSQL_OPT_SSL_VERIFY_SERVER_CERT, arg=0x2deba "") Now, it this case, if I just change the offending line to: if (!arg || test(*(uint*) arg)) --> if (!arg || test(* /*(uint*)*/ arg)) then the 'mysqldump -A' works, but for some reason, there are lots of test(*(unit*)arg) lines around, and I suppose all of them could cause problems. (Note that for *(unit*)arg to work, arg must be aligned to a multiple of 4, but it is not: 0x2deba = 188090, and a quick check shows that 4 * (188090/4) = 188088, so arg is indeed misaligned for *(uint*)arg)
Yes, same here, not working, will go back to 4.1.21 until its fixed.
This was reported by vivo to the mysql-dev mailing-list and also in the bug I just added to the links, we're waiting on a resolution from upstream... Leaving this open for now. Best regards, CHTEKK.
Still happening on 5.0.32...
(In reply to comment #17) > This was reported by vivo to the mysql-dev mailing-list and also in the bug I > just added to the links, we're waiting on a resolution from upstream... Leaving > this open for now. > Best regards, CHTEKK. > Do you know offhand if upstream acknowledges that there is a problem? We can "fix" it easily enough by getting rid of those invalid "*(uint*)" casts (and yes, they are invalid). But I cannot guess whether or not that is in fact a correct solution.
Javi reports this: ================ <fmccor> If I think of any nice solution, I'll pass it on. But it won't be today, because some sort of flu has me pretty much out of commission. <Javi> heh <Javi> managed to make it work <Javi> I removed casts from some files <Javi> sql/client.c <Javi> sql-common/client.c <Javi> mysqldump.c had no *uint casts <Javi> well <Javi> it works ========================= Problem is that if a variable c, say resolves to (char*)c, on sparc you just can't do (*(uint*)c) in place of (*c). That cast is invalid, because the address is most likely misaligned and so you get a bus error. Easy solution is to get rid of the silly (uint*) casts, unless you really need to look at an entire sizeof(uint) amount of data. Then, it is trickier. Obvious fix is to use memcpy or bcopy (whatever you prefer) into a properly aligned variable, then test on that. Problem is that (some versions, at least of) gcc will illegally "optimize" that back to an (uint*) pointer, and you still get the bus error. Bullet proff solution is to do whatever copy you actually need yourself. But (*(uint*)(char*)) sort of stuff has to go. Fix one way or the other is simple, and problem destroys mysqldump, so I'm upping the severity. This sort of bug should have taken no time at all for upstream to fix. After all, they introduced the problem with those (uint*) casts on (char*) variables. Sorry for the frustrated tone, Regards, Ferris
Javi: you modified it, please make a patch of those changes you just made and attach it here?
Javi, I've added you to the CC (I think).
(In reply to comment #17) > This was reported by vivo to the mysql-dev mailing-list and also in the bug I > just added to the links, we're waiting on a resolution from upstream... Leaving > this open for now. > Best regards, CHTEKK. > The fix is trivial (one way or the other), and is critical for sparc. They (upstream) have to get rid of illegal widening on (char*) pointers, because some architectures can't tolerate those things. Can you goose them? As I mentioned previously, for sparc, this is a hard failure, the code is invalid, and our users are grumpy. We know where the failures are, but can only pass them on. Please see Comments #15 on. We can't give a definitive fix, but we know exactly what upstream has done wrong. And to repeat, our users actually (try to) use mysqldump.
Upstream says it is fixed in 5.1.17. I just tested 5.2.3-falcon-alpha(mysqldump ver 10.12) and it looks good but as it's still alpha it my take some time until we can close this one. (5.1 branch is still beta)
Created attachment 114881 [details, diff] uint char pointer casts patch Just three files are patched: libmysqld/client.c, sql/client.c and sql-common/client.c.
Just for the record, this still fails for 5.0.38 (yes, I know upstream says fixed in 5.1.17). How far off is 5.1.17, and is it upward compatible with 5.0.38? If it's a long time coming, or if there are incompatibilities, is it possible to generate a local patch to take care of this in the mean time? I don't know what upstream is proposing, but Javier's patch works for him, at least, and without it, mysqldump does not work at all.
The 5.1 series is beta-level software at best, and it's definetly not entirely compatiable with 5.0 (there's a list of official 'incompatible changes' somewhere). I'll try go port Javier's patch to 5.0.38 for you.
> I'll try go port Javier's patch to 5.0.38 for you. > My patch does work for dev-db/mysql-5.0.38, the hunks do succeed.
(In reply to comment #28) > > I'll try go port Javier's patch to 5.0.38 for you. > > > > My patch does work for dev-db/mysql-5.0.38, the hunks do succeed. > We'll test as soon as your patch is available. Thanks for the quick response.
> > My patch does work for dev-db/mysql-5.0.38, the hunks do succeed. > > > > We'll test as soon as your patch is available. Thanks for the quick response. I meant that the patch that I did submit for version 5.0.34 does already work for 5.0.38 if you apply after epatch (or paludis' patcher) has finished patching. It will show some hunks but will succeed. Cheers.
(In reply to comment #27) > The 5.1 series is beta-level software at best, and it's definetly not entirely > compatiable with 5.0 (there's a list of official 'incompatible changes' > somewhere). > > I'll try go port Javier's patch to 5.0.38 for you. > Comment 29 was really a reply to this: We'll test as soon as the patch is applied to 5.0.38.
(In reply to comment #6) > I'm adding sparc CC and reopening. I can reproduce the error easily: > > fmccor@polylepis SNAKES [20]% mysqldump -A > Bus error > With > Wed Nov 8 13:13:30 2006 >>> dev-db/mysql-5.0.26-r1 > > On sparc, this is typically indicative of a data alignment problem (on amd64, > that mysqldump command works fine). > This seems to be fixed (???) with: Fri May 11 11:49:00 2007 >>> dev-db/mysql-5.0.40 At least, on a couple test systems, I can no longer duplicate it, thus: ============ fmccor@polylepis Snakes [78]% mysqldump -A > /tmp/m fmccor@polylepis Snakes [79]% ============ (And /tmp/m contains what it should.)
Thanks, 5.0.40 in stable soon.
Javler (Javier) also reports this fixed; sparc is finished with this one.
