From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9349 invoked by alias); 13 Aug 2008 13:30:00 -0000 Received: (qmail 9339 invoked by uid 22791); 13 Aug 2008 13:29:59 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Aug 2008 13:29:16 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id m7DDTCjY288020 for ; Wed, 13 Aug 2008 13:29:12 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7DDTCG63346552 for ; Wed, 13 Aug 2008 15:29:12 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7DDTCKM022240 for ; Wed, 13 Aug 2008 15:29:12 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m7DDTCWK022235; Wed, 13 Aug 2008 15:29:12 +0200 Message-Id: <200808131329.m7DDTCWK022235@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 13 Aug 2008 15:29:12 +0200 Subject: Re: [patch] nto target: fix null pointer dereference To: aristovski@qnx.com Date: Wed, 13 Aug 2008 13:30:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sources.redhat.com X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00345.txt.bz2 Aleksandar Ristovski wrote: > Ulrich Weigand wrote: > > Can you explain what the situation is that leads to a NULL > > pointer here? > > Your question made me go through the issue again. > > To create inferior, we use spawnp. spawnp will do something like mmap > the binary and that's pretty much it (DT_DEBUG in .dynamic will contain > NULL pointer). > > In procfs_create_inferior we call solib_create_inferior_hook, which will > end up trying to determine loader base by reading inferior's memory at > DT_DEBUG pointer. In our case, before the executable actually started > executing, it will successfully read 0s, because dynamic loader has not > been invoked yet, and the pointer to r_debug structure is not initialized. I see. However, so->lm_info->lm should still be always allocated by the common solib-svr4.c routines (see svr4_current_sos): new->lm_info->l_addr = (CORE_ADDR)-1; new->lm_info->lm_addr = lm; new->lm_info->lm = xzalloc (lmo->link_map_size); The only case where it is not allocated is in svr4_default_sos (which I guess can happen in your case if the loader base is not found). However, there the comment says: /* Nothing will ever check the cached copy of the link map if we set l_addr. */ new->lm_info->l_addr = debug_loader_offset; new->lm_info->lm_addr = 0; new->lm_info->lm = NULL; Note the assumption that is only every used if is not equal to -1. This is also what the solib-svr4.c implementation of LM_ADDR_CHECK does. It seems the main problem is that NTO at some time copied some of the logic from solib-svr4.c, but has not adapted to the changes that were added to that file later on. Not even the definition of struct lm_info matches any more! Maybe a more correct fix would be to mimic the new solib-svr4.c logic and use the l_addr field to cache the load address? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com