DB Error (create_profile 3) on boot.

[jstenback]

Howdy.

I'm playing around with minimyth here and I've successfully booted both available stable releases, test releases (recent myth trunk versions), and even some minimyth versions that I've successfully built locally. I recently tried to build minimyth with an update mythtv trunk (version 21361) and I get DB errors on startup, which results in mythfrontend segfaulting (or at least I'm assuming the DB errors are the source of the segfault). I also got the same DB errors when using trunk version 21210 (which is also available for download in the latest-trunk directory on minimyth.org).

This is running against a mythtv backend of the same trunk version, and other clients successfully connect, so I'm assuming the backend is ok. The errors I'm getting are as follows:

Code: Select all

Aug 20 00:38:42 10 local0.info mythfrontend: 2009-08-20 00:38:42.111 New DB connection, total: 2
Aug 20 00:38:42 10 local0.info mythfrontend: 2009-08-20 00:38:42.113 Connected to database 'mythconverg' at host: 10.0.0.130
Aug 20 00:38:42 10 local0.info mythfrontend: 2009-08-20 00:38:42.134 DB Error (create_profile 3):
Aug 20 00:38:42 10 local0.info mythfrontend: Query was:
Aug 20 00:38:42 10 local0.info mythfrontend: INSERT INTO displayprofiles VALUES (?, ?, ?, ?)
Aug 20 00:38:42 10 local0.info mythfrontend: Bindings were:
Aug 20 00:38:42 10 local0.info mythfrontend: :DATA=> 0 0, :GRPID=140, :PROFID=499, :VALUE=pref_cmp0
Aug 20 00:38:42 10 local0.info mythfrontend: Driver error was [2/1210]:
Aug 20 00:38:42 10 local0.info mythfrontend: QMYSQL3: Unable to execute statement
Aug 20 00:38:42 10 local0.info mythfrontend: Database error was:
Aug 20 00:38:42 10 local0.info mythfrontend: Incorrect arguments to mysqld_stmt_execute
Aug 20 00:38:42 10 local0.info mythfrontend: 2009-08-20 00:38:42.135 DB Error (create_profile 3):
Aug 20 00:38:42 10 local0.info mythfrontend: Query was:
Aug 20 00:38:42 10 local0.info mythfrontend: INSERT INTO displayprofiles VALUES (?, ?, ?, ?)
Aug 20 00:38:42 10 local0.info mythfrontend: Bindings were:
Aug 20 00:38:42 10 local0.info mythfrontend: :DATA=ffmpeg, :GRPID=140, :PROFID=499, :VALUE=pref_decoder
...

There's 222 errors like that total, with different values. The interesting thing is that I do see the same minimyth frontend successfully writing a few entries into the displayprofiles table, as well as into the displayprofilegroups table, so it's not like the DB connection is completely broken...

Does this ring any bells for anyone? Am I just too close to the bleeding edge here?

--
jst

[jstenback]

Oh, and I forgot to mention that I've seen this earlier with other builds I've attempted to do myself, but not consistently, so I can't figure out what's different between a build I do that works and one that doesn't.

And also, I took the log, transformed the values from it that minimyth failed to set in the db and generated a script to do just that, and on next reboot, it tried to insert the same values again into the db. It's as if it doesn't see values in the db or something.

[Pablo]

I have come across some reports that this might be caused by certain gcc optimizations in some instances. Therefore, it might be informative to know the gcc options used when compiling mysql.

If you compiled MiniMyth from source, then what minimyth.conf.mk options did you use?

If you used one of the MiniMyth binaries, then what was it called exactly?

[jstenback]

Thanks for your reply!

I've so far only ever seen this with builds I done myself AFAICT. I build on a Fedora Core 11 x86_64 box, I've built both 64 and 32 bit binaries and I see the exact same problem. Here's my ~/.minimyth/minimyht.conf.mk:

Code: Select all

mm_HOME                   ?= $(HOME)/minimyth/minimyth-read-only/gar-minimyth
mm_KERNEL_HEADERS_VERSION ?= 2.6.31
mm_KERNEL_VERSION         ?= 2.6.31
mm_MYTH_VERSION           ?= trunk
mm_NFS_ROOT               ?= /minimyth
mm_GRAPHICS               ?= nvidia
mm_GARCH                  ?= x86-64
mm_DISTRIBUTION_RAM       ?= no
mm_DISTRIBUTION_LOCAL     ?= no

I also ran into reports of compiler optimizations causing problems like this. Some claim the problem is caused by optimization bugs in mysqld, others seem to think it's in the qt-mysql driver (libqsqlmysql.so). Just to try, I replaced minimyth's /usr/lib/qt4/plugins/sqldrivers/libqsqlmysql.so with one from my backend, with no change in behavior, same DB errors there. I did the same thing with /usr/lib/mysql/libmysqlclient_r.so.16 and lib/mysql/libmysqlclient.so.16 as well, but no change in functionality. mysqld on the backend is stock Fedora Core 11, version 5.1.36.

Here's some more info about my setup:

My mythtv backend is a Fedora Core 11 box, nothing special. Built mythtv from source, revision 21400 (same version that's specified in mm_MYTH_TRUNK_VERSION when building minimyth). I can successfully run the mythtv frontend on the backend well, no DB errors. I also have a Fedora Core 10 boxe where I also built the same version of mythtv and it too can successfully connect to this backend, no DB errors or anything. So it seems to point to something I'm doing when building minimyth

Any chance you'll be releasing an updated trunk test build any time soon? Then I could at least see if there's a difference between how your builds work and how ones I build myself work.

I'm happy to experiment here, if you can think of anything else I should try, please just let me know.

--
jst

[jstenback]

... and fwiw, the minimyth svn version number is r5335.

[jstenback]

I think I've convinced myself that this is something I only see in 64-bit builds of minimyth. I realized that when I tested the 32-bit builds I had done earlier I forgot one step of the installation and I was actually testing the same 64-bit builds, so it seems this is likely an optimization problem (or whatever it really is) that only shows up in 64-bit builds. I'll keep poking at this and report back if I get more clues about what specifically this could be.

[Pablo]

If you rebuild db/mysql with

Code: Select all

CFLAGS += -fno-strict-aliasing -fwrapv
CXXFLAGS += -fno-strict-aliasing -fwrapv -felide-constructors -fno-rtti -fno-exceptions

added to the package Makefile below the

Code: Select all

include ../../gar.mk

line, then does the problem go away. The reason I ask is that there have been similar/same problems reported to mysql that relate to bugs in libmysql that show up on x86_64 machines when using certain compiler optimizations.
If that does not work, then does using

Code: Select all

CFLAGS += -O0 -fno-strict-aliasing -fwrapv
CXXFLAGS += -O0 -fno-strict-aliasing -fwrapv -felide-constructors -fno-rtti -fno-exceptions

work.

[jstenback]

Hello Pablo,

I updated my minimyth source to a version newer than when you changed this and rebuilt, and now the 64-bit builds appear to be working fine!

Thanks for digging into this!

[Pablo]

Hello Pablo,

I updated my minimyth source to a version newer than when you changed this and rebuilt, and now the 64-bit builds appear to be working fine!

Thanks for digging into this!

I am glad that worked.