Re: Random memory corruption with 64-bit SMP 2.6.30-rc4

[Helge Deller <deller@gmx.de>]

John David Anglin wrote:
>> Could you run the entire build with LD_BIND_NOW=3D1 set? Does it crash
>> anywhere else?
> 
> Got a lot further but bash SEGV'd again:
> 
> Program terminated with signal 11, Segmentation fault.
> [New process 14746]
> #0  0x00035ba4 in close_fd_bitmap ()
> (gdb) bt
> #0  0x00035ba4 in close_fd_bitmap ()
> #1  0x00039d08 in ?? ()
> #2  0x000373b8 in execute_command_internal ()
> #3  0x00036d3c in ?? ()
> #4  0x000382a4 in execute_command_internal ()
> #5  0x00073a68 in parse_and_execute ()
> #6  0x0004d840 in command_substitute ()
> #7  0x00051e14 in ?? ()
> #8  0x00053320 in ?? ()
> #9  0x00056fa8 in expand_string_assignment ()
> #10 0x00050f44 in ?? ()
> #11 0x000512fc in ?? ()
> #12 0x00053278 in ?? ()
> #13 0x0003a0a4 in ?? ()
> #14 0x000373b8 in execute_command_internal ()
> #15 0x00038638 in execute_command ()
> #16 0x00038310 in execute_command_internal ()
> #17 0x00073a68 in parse_and_execute ()
> #18 0x00025a1c in ?? ()
> #19 0x000269a8 in main ()
> 
> Restarting, and it crashed again:
> 
> Core was generated by `/bin/sh ./libtool --tag=CXX --mode=compile /home/dave/gnu/gcc/objdir/./gcc/xgcc'.
> Program terminated with signal 11, Segmentation fault.
> [New process 32486]
> #0  0x00000000 in ?? ()
> (gdb) bt
> #0  0x00000000 in ?? ()
> #1  0x000ab3dc in ?? ()
> #2  0x0006e930 in sh_xmalloc ()
> #3  0x0004995c in stop_pipeline ()
> #4  0x00037cec in execute_command_internal ()
> #5  0x00038638 in execute_command ()
> #6  0x00038310 in execute_command_internal ()
> #7  0x00037a60 in execute_command_internal ()
> #8  0x00038638 in execute_command ()
> #9  0x000374c4 in execute_command_internal ()
> #10 0x00037a60 in execute_command_internal ()
> #11 0x00037a60 in execute_command_internal ()
> #12 0x000395f8 in ?? ()
> #13 0x0003a85c in ?? ()
> #14 0x000373b8 in execute_command_internal ()
> #15 0x00038638 in execute_command ()
> #16 0x00038310 in execute_command_internal ()
> #17 0x00037a60 in execute_command_internal ()
> #18 0x00038638 in execute_command ()
> #19 0x000374c4 in execute_command_internal ()
> #20 0x00037a60 in execute_command_internal ()
> #21 0x00038638 in execute_command ()
> #22 0x00038310 in execute_command_internal ()
> ---Type <return> to continue, or q <return> to quit---
> #23 0x00037a60 in execute_command_internal ()
> #24 0x000395f8 in ?? ()
> #25 0x0003a85c in ?? ()
> #26 0x000373b8 in execute_command_internal ()
> #27 0x00038638 in execute_command ()
> #28 0x000374c4 in execute_command_internal ()
> #29 0x00037a60 in execute_command_internal ()
> #30 0x00038638 in execute_command ()
> #31 0x000374c4 in execute_command_internal ()
> #32 0x00038638 in execute_command ()
> #33 0x000279c8 in reader_loop ()
> #34 0x0002751c in main For this(gdb) frame 1
> #1  0x000ab3dc in ()
> (gdb) disass 0x000ab3cc 0x000ab3ec
> Dump of assembler code from 0xab3cc to 0xab3ec:
> 0x000ab3cc:	stw ret0,1c8(r8)
> 0x000ab3d0:	copy r5,r26
> 0x000ab3d4:	b,l 0x798d0,rp
> 0x000ab3d8:	ldi df,r25
> 0x000ab3dc:	b,l 0xab188,r0
> 0x000ab3e0:	copy r3,ret0
> 0x000ab3e4:	ldi -21,ret0
> 0x000ab3e8:	stb ret0,0(r22)
> End of assembler dump
> (gdb) p/x $rp
> $1 = 0xab3df
> (gdb) disass 0x798d0 0x798e0
> Dump of assembler code from 0x798d0 to 0x798e0:
> 0x000798d0:	addil L%5000,dp,r1
> 0x000798d4:	ldw 524(r1),r21
> 0x000798d8:	bv r0(r21)
> 0x000798dc:	ldw 528(r1),r19
> End of assembler dump.
> (gdb) p/x $dp
> $2 = 0xca1c8
> (gdb) p/x $r1
> $3 = 0xcf1c8
> (gdb) p/x $r21
> $4 = 0x0
> (gdb) p/x $r1+0x524
> $5 = 0xcf6ec
> (gdb) x/x 0xcf6ec
> 0xcf6ec:	0x40488250
> (gdb) disass 0x40488250
> Dump of assembler code for function *__GI_memset:
> 0x40488250 <*__GI_memset+0>:	cmpib,>>= 7,r24,0x404882f8 <*__GI_memset+168>
> 0x40488254 <*__GI_memset+4>:	copy r26,r22
> 0x40488258 <*__GI_memset+8>:	extrw,u r25,31,8,r31
> ...

Could it be, that always r21 and r22 are involved?
Maybe we don't restore them correctly after some syscalls like fork / getpwnam...?
Esp. the comment for r21-r22 in arch/parisc/kernel/entry.S:1708 seems interesting:

        /* Register saving semantics for system calls:

           %r1             clobbered by system call macro in userspace
           %r2             saved in PT_REGS by gateway page
           %r3  - %r18     preserved by C code (saved by signal code)
           %r19 - %r20     saved in PT_REGS by gateway page
           %r21 - %r22     non-standard syscall args
                           stored in kernel stack by gateway page
           %r23 - %r26     arg3-arg0, saved in PT_REGS by gateway page
           %r27 - %r30     saved in PT_REGS by gateway page
           %r31            syscall return pointer
         */

Helge