| Summary: | dev-db/mysql-5.0.17 broken with hardened | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Markus Ullmann (RETIRED) <jokey> |
| Component: | Current packages | Assignee: | Gentoo Linux MySQL bugs team <mysql-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | hardened |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Markus Ullmann (RETIRED)
2005-12-23 05:05:43 UTC
Here it start fine and respond to connection from the "mysql" client (intended as the program /usr/bin/mysql) maybe you need to rebuild zlib ? feel free to reopen if that does not suffice. No, it didn't.. I also did an emerge -e system, just to make sure but error persists. I downgraded again to 5.0.16-r4 and it works again. Sincerely I've no clue, does "dmesg" or some log tell something more ? I put up the binaries, so you might test if it helps ;) http://www.markus-ullmann.de/gentoo/mysql-test-case.tar.bz2 Every binary in this package is working except mysqld: # ./mysqld ./mysqld: symbol lookup error: ./mysqld: undefined symbol: zlibCompileFlags Could you try emerge with USE="-static debug" ? here it dump the core with an "Illegal instruction.". It's not a good idea securing a system with hardened and then compile stuff static because it destroy some of the hardened security. if it still crash: - try to uncomment "one-thread" option in /etc/mysql/my.cnf - put DEBUG=4 in /etc/conf.d/mysql - grab the startup string of "/etc/init.d/mysql start" i.e. mysqld --... - issue a "ulimit -c unlimited" - run the server with the previous grabbed startup option - wait for a core dumped - run "gdb -c core /usr/sbin/mysqld" (emerge sys-devel/gdb first) - issue a "bt" command, this will show a backtrace hopefully showing someting more ... something more at http://dev.mysql.com/doc/refman/5.0/en/debugging-server.html cheers & good luck, Francesco Will try next year ;) I report results then... Additional comment, on disassembly (gdb) disass $pc-32 $pc+32 Dump of assembler code from 0x13930dce to 0x13930e0e: 0x13930dce: xchg %eax,%ebx 0x13930dcf: sbb %dl,(%ecx) 0x13930dd1: add %al,(%eax) 0x13930dd3: mov %eax,(%edx) 0x13930dd5: call 0x139ee3b3 0x13930dda: mov 0x628(%ebx),%edx 0x13930de0: mov 0xb48(%ebx),%eax 0x13930de6: mov %edx,(%eax) 0x13930de8: mov 0x1460(%ebx),%eax 0x13930dee: cvtss2sd 0xffeefd88(%ebx),%xmm0 0x13930df6: movl $0x6d72662e,(%eax) 0x13930dfc: movb $0x0,0x4(%eax) 0x13930e00: mov 0x183c(%ebx),%eax 0x13930e06: mov %esi,(%eax) 0x13930e08: cvtss2sd 0xfff62424(%ebx),%xmm1 End of assembler dump. <googlesearch> CVTSS2SD--Convert Scalar Single-Precision Floating-Point Value to Scalar Double-Precision Floating-Point Value Description Converts a single-precision floating-point value in the source operand (second operand) to a double-precision floating-point value in the destination operand (first operand). The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register. When the source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register. The result is stored in the low quadword of the destination operand, and the high quadword is left unchanged. </googlesearch> it's normal that CVTSS2SD is there with thise CFLAGS ? Additional comment 2, it's moot say that it finish with an illegal istruction here , realized I've used it on amd thunderbird processor Bug persists on 5.0.18, will do some further checks tomorrow Just to make sure everything is correct, I've completed an emerge -e world so that everything is consistent. Error still there and reproducable on other machines, too, when using intel p4 and cflags/useflags like in my emerge info. I've tested to build without the gentoo-patches and then everything works fine. please attach the "config.log" from the two compiles, need to find out what made the difference. I've got it working now. There seems to be a gcc internal problem when running gcc 3.4., march and mtune set to pentium 4 and PaX address space randomization while building mysql >=5.0.17. When this little kernel feature is enabled, something in the build goes wrong and causes mysql not to find this symbol at startup although there is no error or warning in config.log or output. If this feature is disabled at build time, you can enable it at runtime again and everything works like a charm. While hunting this bug I also came across some mailinglists where weird bugs appear when using this mtune=pentium4 thing. I recently discovered a false positive from stack protector in net-snmp on the same box, too, so I'm sure now that it isn't a real mysql problem. I think this bug is "worksforme" now. Sorry for causing inconvenience. |