From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.140.140.3 with SMTP id n3cs283620rvd; Fri, 5 Mar 2010 06:40:35 -0800 (PST) Received-SPF: pass (google.com: domain of 34ReRSwcLCtU85149LJ85149LJ.3FDI13B-45M5C7FF7C57IFLGJ.3FD@groups.bounces.google.com designates 10.224.104.161 as permitted sender) client-ip=10.224.104.161; Authentication-Results: mr.google.com; spf=pass (google.com: domain of 34ReRSwcLCtU85149LJ85149LJ.3FDI13B-45M5C7FF7C57IFLGJ.3FD@groups.bounces.google.com designates 10.224.104.161 as permitted sender) smtp.mail=34ReRSwcLCtU85149LJ85149LJ.3FDI13B-45M5C7FF7C57IFLGJ.3FD@groups.bounces.google.com; dkim=pass header.i=34ReRSwcLCtU85149LJ85149LJ.3FDI13B-45M5C7FF7C57IFLGJ.3FD@groups.bounces.google.com Received: from mr.google.com ([10.224.104.161]) by 10.224.104.161 with SMTP id p33mr63099qao.6.1267800034861 (num_hops = 1); Fri, 05 Mar 2010 06:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:received:received :received:received-spf:received:mime-version:received:from:date :message-id:subject:to:x-original-authentication-results :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:x-thread-url:x-message-url:sender :list-subscribe:list-unsubscribe:content-type; bh=pCYUeknlSmYtnx1Gf9rx+BLszUoMFW7TPTG5fxwrU+E=; b=DsYerW5JoDaL+sa71/GE8LcBaQYG5nbxiYfrRAFbGY79ps48B73nTZiqRBxO2lR865 2i4cOFIe7YSzJIPRlgnU9r30v63D056Mz7D96YreghI+9TY/8A/pF6eq02X28iMxVCjz Z8qX/qZ3bKADnGZz5dvsQNMAV2da5VCvw9AYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:mime-version:from:date:message-id:subject :to:x-original-authentication-results:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :x-thread-url:x-message-url:sender:list-subscribe:list-unsubscribe :content-type; b=AwYzz0tOSMciwuK1ifcpNWUrx0hf2p3osD17/1KJsSpkty3a0jXh9j5FFSj3MobPRw lm/9JxLgPZtDbA53K8s9aBelS5Qz6UDFsmdmRDiI3Iw8NGEovv+4HcNFAd0VzhqTsrGE 0zlCTV4G7X7XABNl5XA3Snpvp6vrmdXs+YTmU= Received: by 10.224.104.161 with SMTP id p33mr7187qao.6.1267800033584; Fri, 05 Mar 2010 06:40:33 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.224.22.138 with SMTP id n10ls1480389qab.0.p; Fri, 05 Mar 2010 06:40:32 -0800 (PST) Received: by 10.224.19.92 with SMTP id z28mr21845qaa.5.1267800031598; Fri, 05 Mar 2010 06:40:31 -0800 (PST) Received: by 10.224.19.92 with SMTP id z28mr21844qaa.5.1267800031569; Fri, 05 Mar 2010 06:40:31 -0800 (PST) Return-Path: Received: from mail-vw0-f47.google.com (mail-vw0-f47.google.com [209.85.212.47]) by gmr-mx.google.com with ESMTP id 18si359887qyk.12.2010.03.05.06.40.31; Fri, 05 Mar 2010 06:40:31 -0800 (PST) Received-SPF: pass (google.com: domain of headius@headius.com designates 209.85.212.47 as permitted sender) client-ip=209.85.212.47; Received: by vws10 with SMTP id 10so1180734vws.20 for ; Fri, 05 Mar 2010 06:40:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.108.34 with SMTP id d34mr606352vcp.155.1267800031103; Fri, 05 Mar 2010 06:40:31 -0800 (PST) From: Charles Oliver Nutter Date: Fri, 5 Mar 2010 08:40:11 -0600 Message-ID: Subject: Not cleaning up tempfiles for multipart? To: rack-devel@googlegroups.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of headius@headius.com designates 209.85.212.47 as permitted sender) smtp.mail=headius@headius.com X-Original-Sender: headius@headius.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: X-Thread-Url: http://groups.google.com/group/rack-devel/t/6eb2bc7a1f8c072c X-Message-Url: http://groups.google.com/group/rack-devel/msg/bafde9d57657342a Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset=UTF-8 I'm investigating some reported tempfle bugs in JRuby, and it seems like Rack may not be cleaning up tempfiles it uses. The creation of the tempfile happens at utils.rb line 486: if content_type || filename >> body = Tempfile.new("RackMultipart") body.binmode if body.respond_to?(:binmode) end The body is then written to (with the content of the request body), rewound, put into the "data" structure, passed to normalize_params (which inserts the "data" into the params hash), and that's it. The params are then presumably used for the request, and nobody ever explicitly cleans up the tempfile. Am I looking in the wrong place? If I'm correct, this is a bug. Tempfiles should not be relied upon to clean themselves up in response to GC, since you don't know when GC will fire... - Charlie