From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: valgrind warnings [Re: Emacs bzr memory footprint] Date: Sat, 29 Oct 2011 11:10:10 +0200 Message-ID: <83aa8k9n9p.fsf@gnu.org> References: <87fwivwp37.fsf@turtle.gmx.de> <87sjmvpmd2.fsf@lifelogs.com> <87aa93wmc4.fsf@turtle.gmx.de> <87sjmnrdjw.fsf@spindle.srvr.nix> <87ty73mc0m.fsf@spindle.srvr.nix> <4EA19111.7060401@yandex.ru> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1319879425 1965 80.91.229.12 (29 Oct 2011 09:10:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 29 Oct 2011 09:10:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 29 11:10:21 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 1RK4vk-0006Ky-LS for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2011 11:10:20 +0200 Original-Received: from localhost ([::1]:54166 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RK4vi-0000NY-Og for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2011 05:10:18 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RK4vf-0000NI-SX for emacs-devel@gnu.org; Sat, 29 Oct 2011 05:10:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RK4ve-0008Ng-Ty for emacs-devel@gnu.org; Sat, 29 Oct 2011 05:10:15 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:48937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RK4vd-0008NO-HR; Sat, 29 Oct 2011 05:10:13 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LTT00900LB2T400@a-mtaout20.012.net.il>; Sat, 29 Oct 2011 11:10:10 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.212.197]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LTT009C1LGY8XD0@a-mtaout20.012.net.il>; Sat, 29 Oct 2011 11:10:10 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 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:145748 Archived-At: > From: Dan Nicolaescu > Cc: emacs-devel@gnu.org > Date: Fri, 28 Oct 2011 16:20:25 -0400 > > > Valgrind produces these warnings, maybe some of them are interesting: > > > > ==30382== Conditional jump or move depends on uninitialised value(s) > > ==30382== at 0x499251: coding_set_destination (coding.c:1046) > > ==30382== by 0x4B477A: decode_coding (coding.c:7022) > > ==30382== by 0x4B7317: decode_coding_object (coding.c:7671) > > ==30382== by 0x63610F: Fcall_process (callproc.c:813) > > ==30382== by 0x5D6C07: Ffuncall (eval.c:2956) > > ==30382== by 0x5D5ECA: Fapply (eval.c:2479) > > ==30382== by 0x5D6C07: Ffuncall (eval.c:2956) > > ==30382== by 0x622C5B: exec_byte_code (bytecode.c:785) > > ==30382== by 0x5D77BA: funcall_lambda (eval.c:3205) > > ==30382== by 0x5D6F4C: Ffuncall (eval.c:3023) > > ==30382== by 0x622C5B: exec_byte_code (bytecode.c:785) > > ==30382== by 0x5D77BA: funcall_lambda (eval.c:3205) > > This looks like setup_coding_system (or whatever else initializes struct > coding_system) does not initialize the src_pos field. > > > > > ==30382== Conditional jump or move depends on uninitialised value(s) > > ==30382== at 0x6302A9: send_process (process.c:5398) > > ==30382== by 0x630DC8: Fprocess_send_string (process.c:5648) > > ==30382== by 0x5D6D61: Ffuncall (eval.c:2977) > > ==30382== by 0x622C5B: exec_byte_code (bytecode.c:785) > > ==30382== by 0x5D77BA: funcall_lambda (eval.c:3205) > > ==30382== by 0x5D6F4C: Ffuncall (eval.c:3023) > > ==30382== by 0x622C5B: exec_byte_code (bytecode.c:785) > > ==30382== by 0x5D77BA: funcall_lambda (eval.c:3205) > > ==30382== by 0x5D6F4C: Ffuncall (eval.c:3023) > > ==30382== by 0x622C5B: exec_byte_code (bytecode.c:785) > > ==30382== by 0x5D77BA: funcall_lambda (eval.c:3205) > > ==30382== by 0x5D6F4C: Ffuncall (eval.c:3023) > > similarly the struct coding_system.src_multibyte needs to be > initialized. > > > > ==30382== Conditional jump or move depends on uninitialised value(s) > > ==30382== at 0x636022: Fcall_process (callproc.c:799) > > ==30382== by 0x5D6C07: Ffuncall (eval.c:2956) > > ==30382== by 0x5D5ABB: Fapply (eval.c:2422) > > ==30382== by 0x5D6C07: Ffuncall (eval.c:2956) > > ==30382== by 0x622C5B: exec_byte_code (bytecode.c:785) > > ==30382== by 0x5D77BA: funcall_lambda (eval.c:3205) > > ==30382== by 0x5D6F4C: Ffuncall (eval.c:3023) > > ==30382== by 0x5D5ABB: Fapply (eval.c:2422) > > ==30382== by 0x5D6C07: Ffuncall (eval.c:2956) > > ==30382== by 0x622C5B: exec_byte_code (bytecode.c:785) > > ==30382== by 0x5D77BA: funcall_lambda (eval.c:3205) > > ==30382== by 0x5D6F4C: Ffuncall (eval.c:3023) > > similarly the struct coding_system.dst_multibyte needs to be > initialized. > > > > ==30382== Use of uninitialised value of size 8 > > ==30382== at 0x5B7000: mark_object (alloc.c:5674) > > ==30382== by 0x5B4C9B: mark_maybe_object (alloc.c:4152) > > ==30382== by 0x5B4FE6: mark_memory (alloc.c:4274) > > ==30382== by 0x5B507E: mark_stack (alloc.c:4532) > > ==30382== by 0x5B5F48: Fgarbage_collect (alloc.c:5119) > > ==30382== by 0x5D69F0: Ffuncall (eval.c:2911) > > ==30382== by 0x5D64CA: call2 (eval.c:2758) > > ==30382== by 0x5809AA: Finsert_file_contents (fileio.c:4144) > > ==30382== by 0x5D6E00: Ffuncall (eval.c:2990) > > ==30382== by 0x622C5B: exec_byte_code (bytecode.c:785) > > ==30382== by 0x5D77BA: funcall_lambda (eval.c:3205) > > ==30382== by 0x5D6F4C: Ffuncall (eval.c:3023) > > It would be interesting to know if the gc warnings are relevant... I suggest to file a separate bug report about each valgrind warning.