Hide Forgot
Description of problem: Trying to run mysqld via valgrind, I'm getting this error: InnoDB: Error: Write to file ./ib_logfile0 failed at offset 0 512. Version-Release number of selected component (if applicable): valgrind-3.5.0-1.el5.ppc64 mysql-5.0.77-4.el5_5.4.ppc64 How reproducible: always Steps to Reproduce: 1. valgrind --workaround-gcc296-bugs=yes /usr/libexec/mysqld Actual results: ==5923== Memcheck, a memory error detector ==5923== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==5923== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==5923== Command: /usr/libexec/mysqld ==5923== --5923-- WARNING: unhandled syscall: 180 --5923-- You may be able to write your own handler. --5923-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --5923-- Nevertheless we consider this a bug. Please report --5923-- it at http://valgrind.org/support/bug_reports.html. 110126 10:43:43 InnoDB: Error: Write to file ./ib_logfile0 failed at offset 0 512. InnoDB: 512 bytes should have been written, only -1 were written. InnoDB: Operating system error number 38. InnoDB: Check that your OS and file system support files of this size. InnoDB: Check also that the disk is not full or a disk quota exceeded. InnoDB: Error number 38 means 'Function not implemented'. InnoDB: Some operating system error numbers are described at InnoDB: http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html 110126 10:43:44InnoDB: Assertion failure in thread 114291200 in file os0file.c line 4026 InnoDB: Failing assertion: ret InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. ==5923== Thread 3: ==5923== Invalid read of size 8 ==5923== at 0x104EA1B4: os_aio_simulated_handle (os0file.c:4026) ==5923== by 0x104AA1DF: fil_aio_wait (fil0fil.c:4131) ==5923== by 0x103E25F7: io_handler_thread (srv0start.c:446) ==5923== by 0x8043AEC0CF: start_thread (in /lib64/libpthread-2.5.so) ==5923== by 0x80438FFEAB: clone (in /lib64/libc-2.5.so) ==5923== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==5923== 110126 10:43:44 - mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=0 read_buffer_size=131072 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 217599 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. ==5923== ==5923== HEAP SUMMARY: ==5923== in use at exit: 23,838,844 bytes in 31,757 blocks ==5923== total heap usage: 44,328 allocs, 12,571 frees, 24,523,417 bytes allocated ==5923== ==5923== LEAK SUMMARY: ==5923== definitely lost: 0 bytes in 0 blocks ==5923== indirectly lost: 0 bytes in 0 blocks ==5923== possibly lost: 20,315,872 bytes in 22,921 blocks ==5923== still reachable: 3,522,972 bytes in 8,836 blocks ==5923== suppressed: 0 bytes in 0 blocks ==5923== Rerun with --leak-check=full to see details of leaked memory ==5923== ==5923== For counts of detected and suppressed errors, rerun with: -v ==5923== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Expected results: normal mysqld startup Additional info: Running /usr/libexec/mysqld without valgrind works as expected.
Indeed, pwrite64 isn't hooked on ppc64 (it is on all other Linux targets including ppc32). // _____(__NR_pwrite64, sys_pwrite64), // 180
BTW, it is surprising that pwrite64 syscall is used on ppc64, glibc pwrite64 definitely uses just pwrite syscall on this architecture. mysqld must be doing something wrong and unportable...
(In reply to comment #2) > BTW, it is surprising that pwrite64 syscall is used on ppc64, glibc pwrite64 > definitely uses just pwrite syscall on this architecture. mysqld must be doing > something wrong and unportable... now I'm really not sure what do you mean - 1) there's a problem with valgrind not supporting pwrite64 AND a problem with mysqld for which a bug should be reported or 2) the valgrind support for pwrite64 isn't necessary, thus no bug in valgrind, just in mysqld, so this bug's component should be switched to mysql? if 1) then please report the new bug for mysql (it makes much more sense if you're the one to do this and provide as much info as possible, because I do not understand the code and a report filed by me saying "there is something wrong" wouldn't be much helpful) if 2) then please switch this bug (and provide the info ...)
Actually there is just pwrite64 syscall and not pwrite syscall on any of the Linux architectures, so this is just a valgrind bug which I'll fix in the next rawhide build.
This is fixed in current fedora, but against 3.6.0, RHEL5 is 3.5.0 based: Fri Jan 28 2011 Jakub Jelinek <jakub> 3.6.0-2 - hook in pwrite64 syscall on ppc64 (#672858)
Sorry, it does not look as though we will be able to fix this problem at this stage of RHEL5's lifecycle, and its old valgrind base.