Comments on: Crashes, complicated edition http://dom.as/2008/08/05/complicated-crashes/ Sat, 17 Dec 2011 20:14:59 +0000 hourly 1 http://wordpress.com/ By: Mark Callaghan http://dom.as/2008/08/05/complicated-crashes/#comment-1331 Tue, 05 Aug 2008 15:47:55 +0000 http://dammit.lt/?p=177#comment-1331 Well, the easy fix didn’t work. We had a few problems with MySQL source and early 4.x versions of gcc. But that was resolved by gcc 4.1. I haven’t touched MySQL 4.0 in a long time. Can I share my favorite support line with you? That problem has been fixed in a recent version, you should upgrade to 5.0.

]]> By: Domas Mituzas http://dom.as/2008/08/05/complicated-crashes/#comment-1330 Tue, 05 Aug 2008 14:58:17 +0000 http://dammit.lt/?p=177#comment-1330 Mark, well, in our case it is actual segfault, not assertion failure.

Processors:
model name : AMD Opteron(tm) Processor 248 (single-core, 2.2ghz)
model name : Quad-Core AMD Opteron(tm) Processor 2356 (quadcore, 2.3ghz)

so it is not some revision range issue (and yes, bug#26081 is epic :)

looking at warnings of course may be interesting…

]]> By: Mark Callaghan http://dom.as/2008/08/05/complicated-crashes/#comment-1329 Tue, 05 Aug 2008 13:26:00 +0000 http://dammit.lt/?p=177#comment-1329 Most of our platform is constant (OS, compiler, MySQL build) but HW is not. We get a crash that only occurs on AMD with 270 listed in /proc/cpuinfo output. The crash is from a checksum mismatch on InnoDB disk block read. What does /proc/cpuinfo list for processor model in your case?

Also, older versions of MySQL and some newer versions of gcc do not like each other. Aliasing optimizations are a possible problem. Look at your compiler warnings and enable more warnings.

]]>