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.