Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Chris Angelico Newsgroups: comp.lang.python Subject: Re: What is heating the memory here? hashlib? Date: Sun, 14 Feb 2016 13:01:52 +1100 Lines: 54 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: news.uni-berlin.de UlSfhuC57D0Q+s95j1+aVwJVNrw1/ipUxRxcYh0UOjtg== Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'else:': 0.03; 'received:209.85.223': 0.03; '(python': 0.05; 'memory.': 0.05; 'none:': 0.05; 'calls.': 0.07; 'chunk': 0.07; 'cc:addr:python- list': 0.09; 'function),': 0.09; 'hashlib': 0.09; 'leaks': 0.09; '2016': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'itertools': 0.16; 'linux)': 0.16; 'paulo': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'somewhere.': 0.16; 'this)': 0.16; 'usage,': 0.16; 'wrote:': 0.16; 'memory': 0.17; 'byte': 0.18; 'cc:2**0': 0.20; 'cc:addr:python.org': 0.20; 'cycles': 0.22; 'produces': 0.22; 'seems': 0.23; 'feb': 0.23; 'forgot': 0.23; 'this:': 0.23; 'second': 0.24; 'import': 0.24; 'somewhere': 0.24; 'header:In-Reply-To:1': 0.24; 'testing': 0.25; "doesn't": 0.26; 'handling': 0.27; 'message-id:@mail.gmail.com': 0.27; '14,': 0.27; 'disk': 0.27; 'actual': 0.28; 'another.': 0.29; 'buffers': 0.29; 'if,': 0.29; 'unlikely': 0.29; 'code': 0.30; "i'd": 0.31; 'computer.': 0.32; 'problem': 0.33; 'ram': 0.33; 'correctly': 0.34; 'file': 0.34; 'running': 0.34; 'received:google.com': 0.35; 'returning': 0.35; 'stable': 0.35; 'something': 0.35; 'but': 0.36; 'possible.': 0.36; 'received:209.85': 0.36; '(and': 0.36; 'subject:?': 0.36; 'pm,': 0.36; 'subject:: ': 0.37; 'received:209': 0.38; 'skip:p 20': 0.38; 'data': 0.39; 'subject:the': 0.39; 'your': 0.60; 'different': 0.63; 'complete': 0.63; 'between': 0.65; 'transfer': 0.73; '3.6': 0.84; 'chrisa': 0.84; 'expect.': 0.84; 'probable': 0.84; 'subject:here': 0.84; 'yours': 0.89; 'to:none': 0.91 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=4HAbXg9dYO/jYqSRGeE3VAleZkAMQt9wkAif3pSBmPA=; b=xLe0FlKp7+fKX2Ild8mMnSExPgPN3sk35k/jSsGkfMwlLYsrX+vnsJStnXNPYEyg2T uqgg8+HL4Pf4vNUwEnV2JB0Nkf4gj7n6BkEAeyNMUg9A4Fs2T5nZspR8Jym4rIoKzG4q 61iF8NB+eV9Fqs6l3De3cFrpWLYoQbuAvvmlKbALrvzbFYeasxfin3+cE+hoPHmMElfl L2H3ZZv7bkriyLwrL6zbzQwmayXWc8oJo/Zyzpqb+IkhDYYsgI/CznqGFQtMJBJXlcTP Lq9l2ASekW97c8Xwix9yWkK19w6Oiuvp5q6C9BMUfVsrp5XKx9H6KqYNj4G34Q7H1/w3 wRBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=4HAbXg9dYO/jYqSRGeE3VAleZkAMQt9wkAif3pSBmPA=; b=WMTVbTgnlrTnaUS+GTT18ukv3nxsxssZEiAV8W6iGdcSqFvsLICh6JcLQ1XrW6FujC hDpIN2vv/FeRk0iM2tejOc52g7+E8WX9/9yFaK9toyrfZCYh1lUmtiBLgtKhvA/hEBQJ mAGZObMWMCUAxeOzwqU5fH2uJ/m9RVFWbI1KSeEYgH6HIssjs32zJDPsaY9MLosebuZl prrivHyOpRRXIwpte8dCPzIG0erLBE3lMj1B9qfv1ZqOyaWsi9Buzi1nFMXju5hWn2pq R4WvKyp5orVX5Wpg6IIkFQEEThYBWPgzCnxdCY/WN1uKTCkDCV1JkVvZi/1onvq08qmW YrJQ== X-Gm-Message-State: AG10YOTX8dXfcxyh7ElQc+dUuOnQjrydV3q1umTzuWrkDmlTRtJdyr4wdsjZT7LXDVTl6mX4+42JIBy+ycKrOg== X-Received: by 10.107.132.90 with SMTP id g87mr9751871iod.157.1455415312721; Sat, 13 Feb 2016 18:01:52 -0800 (PST) In-Reply-To: X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.21rc2 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com comp.lang.python:102898 On Sun, Feb 14, 2016 at 12:44 PM, Paulo da Silva wrote: >> What happens if, after hashing each file (and returning from this >> function), you call gc.collect()? If that reduces your RAM usage, you >> have reference cycles somewhere. >> > I have used gc and del. No luck. > > The most probable cause seems to be hashlib not correctly handling big > buffers updates. I am working in a computer and testing in another. For > the second part may be somehow I forgot to transfer the change to the > other computer. Unlikely but possible. I'd like to see the problem boiled down to just the hashlib calls. Something like this: import hashlib data = b"*" * 4*1024*1024 lastdig = None while "simulating files": h = hashlib.sha256() hu = h.update for chunk in range(100): hu(data) dig = h.hexdigest() if lastdig is None: lastdig = dig print("Digest:",dig) else: if lastdig != dig: print("Digest fail!") Running this on my system (Python 3.6 on Debian Linux) produces a long-running process with stable memory usage, which is exactly what I'd expect. Even using different data doesn't change that: import hashlib import itertools byte = itertools.count() data = b"*" * 4*1024*1024 while "simulating files": h = hashlib.sha256() hu = h.update for chunk in range(100): hu(data + bytes([next(byte)&255])) dig = h.hexdigest() print("Digest:",dig) Somewhere between my code and yours is something that consumes all that memory. Can you neuter the actual disk reading (replacing it with constants, like this) and make a complete and shareable program that leaks all that memory? ChrisA