From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: valgrind warnings [Re: Emacs bzr memory footprint] Date: Sat, 05 Nov 2011 18:08:32 -0400 Message-ID: References: <87vcrhfmww.fsf@uwakimon.sk.tsukuba.ac.jp> <87pqhpf1qo.fsf@uwakimon.sk.tsukuba.ac.jp> <87k47qaxvz.fsf@lifelogs.com> <83bot1bovw.fsf@gnu.org> <87y5w531eo.fsf@uwakimon.sk.tsukuba.ac.jp> <83zkgla1mg.fsf@gnu.org> <87vcr92z6x.fsf@uwakimon.sk.tsukuba.ac.jp> <83ty6t9zd0.fsf@gnu.org> <87wrbov52h.fsf@gnu.org> <4EB4519A.7070503@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1320530923 17985 80.91.229.12 (5 Nov 2011 22:08:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 5 Nov 2011 22:08:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 05 23:08:39 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RMoPm-0008RO-9W for ged-emacs-devel@m.gmane.org; Sat, 05 Nov 2011 23:08:38 +0100 Original-Received: from localhost ([::1]:42553 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMoPl-0004LU-OH for ged-emacs-devel@m.gmane.org; Sat, 05 Nov 2011 18:08:37 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52229) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMoPj-0004LP-27 for emacs-devel@gnu.org; Sat, 05 Nov 2011 18:08:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RMoPh-0008Vm-LJ for emacs-devel@gnu.org; Sat, 05 Nov 2011 18:08:34 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:35819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMoPh-0008VU-Ic for emacs-devel@gnu.org; Sat, 05 Nov 2011 18:08:33 -0400 Original-Received: from dann by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RMoPg-0003W4-HP; Sat, 05 Nov 2011 18:08:32 -0400 In-Reply-To: <4EB4519A.7070503@cs.ucla.edu> (Paul Eggert's message of "Fri, 04 Nov 2011 13:56:58 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145888 Archived-At: Paul Eggert writes: > I like the idea of creating a src/valgrind.supp file. > I looked at Dan's proposal and merged it with mine, > adding some comments to try to explain things > (merged version attached). This version looks nicer! > One question/problem that I had with Dan's is this rule: > > { > survives_gc_p_cond > Memcheck:Cond > fun:survives_gc_p > fun:sweep_weak_table > fun:sweep_weak_hash_tables > fun:Fgarbage_collect > fun:* > } > > As near as I can make out, if survives_gc_p is accessing > uninitialized storage, it's buggy, no? Shouldn't we omit > this rule and fix the bug instead? The full warning looks like this (when also using --track-origins=yes): ==4937== Conditional jump or move depends on uninitialised value(s) ==4937== at 0x5B7567: survives_gc_p (alloc.c:5838) ==4937== by 0x5E5FBD: sweep_weak_table (fns.c:3965) ==4937== by 0x5E62DE: sweep_weak_hash_tables (fns.c:4066) ==4937== by 0x5B75C8: gc_sweep (alloc.c:5850) ==4937== by 0x5B6195: Fgarbage_collect (alloc.c:5203) ==4937== by 0x62301A: exec_byte_code (bytecode.c:820) ==4937== by 0x5D7A96: funcall_lambda (eval.c:3205) ==4937== by 0x5D754A: apply_lambda (eval.c:3082) ==4937== by 0x5D5B4C: eval_sub (eval.c:2367) ==4937== by 0x5D3AF6: internal_lisp_condition_case (eval.c:1453) ==4937== by 0x623C06: exec_byte_code (bytecode.c:981) ==4937== by 0x5D7A96: funcall_lambda (eval.c:3205) ==4937== Uninitialised value was created by a stack allocation ==4937== at 0x6224AA: exec_byte_code (bytecode.c:437) ==4937== Do you think that's a problem?