Bug 679906

+++ This bug was initially created as a clone of Bug #672858 +++

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.

--- Additional comment from jakub on 2011-01-26 10:55:05 EST ---

Indeed, pwrite64 isn't hooked on ppc64 (it is on all other Linux targets including ppc32).

// _____(__NR_pwrite64,          sys_pwrite64),           // 180

--- Additional comment from jakub on 2011-01-27 04:27:27 EST ---

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...

--- Additional comment from kvolny on 2011-01-27 08:57:01 EST ---

(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 ...)

--- Additional comment from jakub on 2011-01-28 07:22:27 EST ---

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.