From owner-freebsd-amd64@FreeBSD.ORG Thu Apr 8 10:36:55 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C70316A4CE for ; Thu, 8 Apr 2004 10:36:55 -0700 (PDT) Received: from mail.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EB4643D31 for ; Thu, 8 Apr 2004 10:36:54 -0700 (PDT) (envelope-from james@jrv.org) Received: from jrv.org (zippy.jrv.org [192.168.3.156]) (authenticated bits=0) by dogfood.jrv.org (8.12.11/8.12.10) with ESMTP id i38BcFso031780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2004 06:38:15 -0500 (CDT) (envelope-from james@jrv.org) Message-ID: <407539A6.4090701@jrv.org> Date: Thu, 08 Apr 2004 06:38:14 -0500 From: "James R. Van Artsalen" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Wemm References: <4073F699.6010402@cri.ensmp.fr> <20040407125532.GA75228@stack.nl> <200404070837.43253.peter@wemm.org> In-Reply-To: <200404070837.43253.peter@wemm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-amd64@freebsd.org Subject: Re: malloc: bug or feature ? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2004 17:36:55 -0000 Peter Wemm wrote: >The SEGV looks suspicious though. I wonder if malloc is trying to put >the junk in without checking if malloc failed. > >Anyway, try "env MALLOC_OPTIONS=aj ./a.out" See 'man malloc.conf' etc >for more info. > > I'm too sleepy to do a good analysis, but a glance I think there's a problem here. Consider the brk() code below. There's one return address then one register on the stack, balanced stack, no problem. But follow the error path if the SYSCALL returns an error: 0000000000409138 <_brk>: 409138: 57 push %rdi 409139: eb 15 jmp 409150 40913b: 90 nop 000000000040913c : 40913c: 57 push %rdi 40913d: 48 89 f8 mov %rdi,%rax 409140: 48 39 05 71 71 10 00 cmp %rax,1077617(%rip) # 5102b8 <.minbrk> 409147: 76 07 jbe 409150 409149: 48 8b 3d 68 71 10 00 mov 1077608(%rip),%rdi # 5102b8 <.minbrk> 0000000000409150 : 409150: 48 c7 c0 11 00 00 00 mov $0x11,%rax 409157: 49 89 ca mov %rcx,%r10 40915a: 0f 05 syscall 40915c: 72 15 jb 409173 40915e: 48 8b 44 24 00 mov 0x0(%rsp,1),%rax 409163: 48 89 05 56 71 10 00 mov %rax,1077590(%rip) # 5102c0 <.curbrk> 40916a: 48 c7 c0 00 00 00 00 mov $0x0,%rax 409171: 5f pop %rdi 409172: c3 retq 0000000000409173 : 409173: e9 ac 03 00 00 jmpq 409524 <.cerror> At this point there is still one reg and one return addr on the stack. What I think goes wrong is that .cerror assumes the top-of-stack is a return address - it just does a RETQ. But we still have %rdi on the stack from brk(). So $pc wanders off into the weeds when RETQ is done. brk() is guilty of going to .cerror without tidying up the stack first. 0000000000409524 <.cerror>: 409524: 50 push %rax 409525: e8 16 00 00 00 callq 409540 <__error_unthreaded> 40952a: 59 pop %rcx 40952b: 48 89 08 mov %rcx,(%rax) 40952e: 48 c7 c0 ff ff ff ff mov $0xffffffffffffffff,%rax 409535: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 40953c: c3 retq 40953d: 90 nop 40953e: 90 nop 40953f: 90 nop 0000000000409540 <__error_unthreaded>: 409540: b8 a8 6a 51 00 mov $0x516aa8,%eax 409545: c3 retq