GCC emits 3DNow!-specific instruction for __builtin_prefetch
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gcc |
Invalid
|
Medium
|
|||
gcc-4.1 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Edgy |
Invalid
|
Undecided
|
Unassigned | ||
mysql-dfsg-5.0 (Ubuntu) |
Fix Released
|
Undecided
|
Matthias Klose | ||
Edgy |
Fix Released
|
High
|
Matthias Klose |
Bug Description
Binary package hint: mysql-server-5.0
[update for SRU / mysql part:
The mysql server in the package fails to run on EMT64 hardware due to a misconfiguration in GCC generating a amd64 specific instruction. Work around this in the mysql package by explicitely building for generic x86_64.
debdiff of the proposed fix is attached to this report.
]
I upgraded from Dapper Drake ( amd64) to the Edgy Eft for testing on an SMP Intel Xeon ( em64t ). During the course of the upgrade the mysql package could not successfully configure itself. Whenever the installation scripts tried launching mysqld, it would die immedietly. If I removed the contents of /var/lib/mysql, the daemon would come up and initiliaze itself, but it would always fail to start up if /var/lib/mysql was populated.
The following error was printed to the system logs:
Oct 17 14:31:27 tinman mysqld_safe[30035]: started
Oct 17 14:31:27 tinman mysqld[30038]: mysqld got signal 4;
Oct 17 14:31:27 tinman mysqld[30038]: This could be because you hit a bug. It is also possible that this binary
Oct 17 14:31:27 tinman mysqld[30038]: or one of the libraries it was linked against is corrupt, improperly built,
Oct 17 14:31:27 tinman mysqld[30038]: or misconfigured. This error can also be caused by malfunctioning hardware.
Oct 17 14:31:27 tinman mysqld[30038]: We will try our best to scrape up some info that will hopefully help diagnose
Oct 17 14:31:27 tinman mysqld[30038]: the problem, but since we have already crashed, something is definitely wrong
Oct 17 14:31:27 tinman mysqld[30038]: and this may fail.
Oct 17 14:31:27 tinman mysqld[30038]:
Oct 17 14:31:27 tinman mysqld[30038]: key_buffer_size=0
Oct 17 14:31:27 tinman mysqld[30038]: read_buffer_
Oct 17 14:31:27 tinman mysqld[30038]: max_used_
Oct 17 14:31:27 tinman mysqld[30038]: max_connections=100
Oct 17 14:31:27 tinman mysqld[30038]: threads_connected=0
Oct 17 14:31:27 tinman mysqld[30038]: It is possible that mysqld could use up to
Oct 17 14:31:27 tinman mysqld[30038]: key_buffer_size + (read_buffer_size + sort_buffer_
Oct 17 14:31:27 tinman mysqld[30038]: bytes of memory
Oct 17 14:31:27 tinman mysqld[30038]: Hope that's ok; if not, decrease some variables in the equation.
Oct 17 14:31:27 tinman mysqld[30038]:
Oct 17 14:31:27 tinman mysqld_safe[30045]: ended
Oct 17 14:31:41 tinman /etc/init.
Oct 17 14:31:41 tinman /etc/init.
Oct 17 14:31:41 tinman /etc/init.
Oct 17 14:31:41 tinman /etc/init.
Oct 17 14:31:41 tinman /etc/init.
Oct 17 14:31:41 tinman /etc/init.
I've since downgraded the mysql-server-5.0 package to the -5.0_5.
Changed in mysql-dfsg-5.0: | |
status: | Unconfirmed → Confirmed |
Changed in gcc: | |
status: | Unknown → Rejected |
description: | updated |
Changed in gcc: | |
importance: | Unknown → Medium |
I'm currently trying to build with debugging symbols to see if it might make things a bit more obvious, but mysqld is actually crashing in rec_copy_ prefix_ to_buf( ).
Just for fun I tried running Debian's binary, since it's being built from what appears to be the same codebase with the same patch applied, and it didn't crash.