Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!txtfeed1.tudelft.nl!tudelft.nl!txtfeed2.tudelft.nl!amsnews11.chello.com!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.008 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'python.': 0.04; 'python': 0.08; 'dict': 0.09; 'fatal': 0.09; 'to:addr:comp.lang.python': 0.09; 'error:': 0.10; 'debugging': 0.13; 'intermediate': 0.15; 'advice,': 0.16; 'allocates': 0.16; 'cached,': 0.16; 'pinpoint': 0.16; 'url:hg': 0.16; 'valgrind': 0.16; 'cc:addr:python-list': 0.16; 'wrote:': 0.18; 'issue.': 0.19; 'cc:no real name:2**0': 0.20; 'memory': 0.21; 'dec': 0.22; 'header:In-Reply-To:1': 0.22; 'dictionary': 0.23; 'worst': 0.23; 'cc:2**0': 0.24; 'received:74.125.82.174': 0.24; 'up.': 0.25; 'sat,': 0.25; 'tests': 0.25; 'code': 0.25; 'helpful': 0.26; "i'm": 0.26; 'tried': 0.27; 'url:mailman': 0.28; 'message-id:@mail.gmail.com': 0.28; 'compile': 0.29; 'cc:addr:python.org': 0.29; 'error': 0.29; 'pm,': 0.29; 'enabled,': 0.30; 'further?': 0.30; "i've": 0.31; 'does': 0.32; 'pure': 0.32; 'url:listinfo': 0.32; "isn't": 0.33; 'object': 0.33; '17,': 0.34; 'allocation': 0.34; 'routine': 0.34; 'stuck': 0.34; 'received:74.125.82': 0.35; 'issue': 0.35; 'url:python': 0.36; 'similar': 0.36; 'two': 0.37; 'but': 0.37; 'received:74.125': 0.37; 'received:google.com': 0.37; 'think': 0.37; 'using': 0.38; 'somewhat': 0.38; 'getting': 0.38; 'url:org': 0.39; 'should': 0.39; 'plain': 0.39; 'help': 0.39; '2011': 0.61; 'address': 0.61; 'your': 0.61; 'kind': 0.61; 'marked': 0.64; 'believe': 0.65; 'piece': 0.66; 'buck': 0.84; 'dict,': 0.84; 'messed': 0.84; 'problematic': 0.84; 'url:include': 0.84 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YnPHhXFpSwgMDddfwjeGa4dIiaJAfMoHMbR2hRy5Zvw=; b=L/D3mYRFgGmy/le4pqLvs9ewOIrWiRjHhGJ2drM2j4QbY05nLVsBkjySey49r2OmZa WUw0fuoadv4giLQH2clVyc+mkVN/eImHjDqUdi2M3LR5WgESaHM3pFP4+ijjV5UGAIm+ 5qRqwVX5dZWgzLU4L8yLnoqGZFpRyMANH/Y5E= MIME-Version: 1.0 In-Reply-To: <18365650.792.1324181855929.JavaMail.geo-discussion-forums@prht13> References: <18365650.792.1324181855929.JavaMail.geo-discussion-forums@prht13> Date: Sun, 18 Dec 2011 12:52:46 -0500 Subject: Re: Debugging a difficult refcount issue. From: Jack Diederich To: comp.lang.python@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: python-list@python.org X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 35 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1324230769 news.xs4all.nl 6844 [2001:888:2000:d::a6]:51345 X-Complaints-To: abuse@xs4all.nl Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:17468 I don't have any great advice, that kind of issue is hard to pin down. That said, do try using a python compile with --with-debug enabled, with that you can turn your unit tests on and off to pinpoint where the refcounts are getting messed up. It also causes python to use plain malloc()s so valgrind becomes useful. Worst case add assertions and printf()s in the places you think are most janky. -Jack On Sat, Dec 17, 2011 at 11:17 PM, buck wrote: > I'm getting a fatal python error "Fatal Python error: GC object already t= racked"[1]. > > Using gdb, I've pinpointed the place where the error is detected. It is a= n empty dictionary which is marked as in-use. This is somewhat helpful sinc= e I can reliably find the memory address of the dict, but it does not help = me pinpoint the issue. I was able to find the piece of code that allocates = the problematic dict via a malloc/LD_PRELOAD interposer, but that code was = pure python. I don't think it was the cause. > > I believe that the dict was deallocated, cached, and re-allocated via PyD= ict_New to a C routine with bad refcount logic, then the above error manife= sts when the dict is again deallocated, cached, and re-allocated. > > I tried to pinpoint this intermediate allocation with a similar PyDict_Ne= w/LD_PRELOAD interposer, but that isn't working for me[2]. > > How should I go about debugging this further? I've been completely stuck = on this for two days now :( > > [1] http://hg.python.org/cpython/file/99af4b44e7e4/Include/objimpl.h#l267 > [2] http://stackoverflow.com/questions/8549671/cant-intercept-pydict-new-= with-ld-preload > -- > http://mail.python.org/mailman/listinfo/python-list