From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.bugs Subject: bug#19883: Correction for backtrace Date: Thu, 26 Feb 2015 12:35:32 +0100 Message-ID: <87k2z4dhx7.fsf@gnu.org> References: <87twyln70f.fsf@fencepost.gnu.org> <873865n2rr.fsf@fencepost.gnu.org> <87twy91vtc.fsf@gnu.org> <878ufld1iw.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1424950618 17030 80.91.229.3 (26 Feb 2015 11:36:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Feb 2015 11:36:58 +0000 (UTC) Cc: 19883@debbugs.gnu.org To: David Kastrup Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Feb 26 12:36:48 2015 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YQwkG-00089Z-EW for guile-bugs@m.gmane.org; Thu, 26 Feb 2015 12:36:44 +0100 Original-Received: from localhost ([::1]:58484 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQwkF-0001vd-SD for guile-bugs@m.gmane.org; Thu, 26 Feb 2015 06:36:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQwjb-0000dy-6G for bug-guile@gnu.org; Thu, 26 Feb 2015 06:36:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQwja-0000iX-76 for bug-guile@gnu.org; Thu, 26 Feb 2015 06:36:03 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQwja-0000iS-4b for bug-guile@gnu.org; Thu, 26 Feb 2015 06:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YQwjZ-0007qL-Mo for bug-guile@gnu.org; Thu, 26 Feb 2015 06:36:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 26 Feb 2015 11:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19883 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 19883-submit@debbugs.gnu.org id=B19883.142495054230122 (code B ref 19883); Thu, 26 Feb 2015 11:36:01 +0000 Original-Received: (at 19883) by debbugs.gnu.org; 26 Feb 2015 11:35:42 +0000 Original-Received: from localhost ([127.0.0.1]:58267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQwjE-0007pk-Ap for submit@debbugs.gnu.org; Thu, 26 Feb 2015 06:35:40 -0500 Original-Received: from fencepost.gnu.org ([208.118.235.10]:44327 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQwjB-0007pb-Pg for 19883@debbugs.gnu.org; Thu, 26 Feb 2015 06:35:38 -0500 Original-Received: from pluto.bordeaux.inria.fr ([193.50.110.57]:51291 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YQwjA-0005nm-KF; Thu, 26 Feb 2015 06:35:37 -0500 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 8 =?UTF-8?Q?Vent=C3=B4se?= an 223 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <878ufld1iw.fsf@fencepost.gnu.org> (David Kastrup's message of "Thu, 26 Feb 2015 00:17:27 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7727 Archived-At: David Kastrup skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> David Kastrup skribis: >> >>> This is embarrassing: I used the wrong executable in connection with the >>> core dump. With the matching executable, the coredump makes a lot more >>> sense: >>> >>> #0 0x00000000 in ?? () >>> #1 0x0804aee0 in Smob_base::mark_trampoline (arg=3D0x9fbb000) >>> at smobs.tcc:34 >>> #2 0xb761b2da in ?? () from /usr/lib/libguile-2.0.so.22 >>> #3 0xb72751f8 in GC_mark_from () from /usr/lib/i386-linux-gnu/libgc.so= .1 >> >> Could you try commenting out all the SMOB mark functions in LilyPond? >> >> This doesn=E2=80=99t fix the bug, of course, but it=E2=80=99s probably a= good >> workaround: user-provided mark functions are not needed in Guile 2.0 >> since libgc scans the whole heap for live pointers. > > Even the test program crashes at the end (when `count' is called in > order to traverse the created hierarchy) when you disable the setting of > the mark function in the init method in smobs.tcc. Could you add debugging symbols for libguile? I don=E2=80=99t understand h= ow =E2=80=98count=E2=80=99 gets called. Do you know if this is a use-after-free error? Perhaps setting MALLOC_CHECK_=3D1 would give a hint. If this is the case, Andy had the idea of turning on topological finalization in the GC. This may help for this particular case, but I vaguely recall that this breaks other finalizer-related things. (I would check by myself, but ISTR that building LilyPond =E2=80=9Con one= =E2=80=99s own=E2=80=9D is not recommended. What would you suggest? A Guix recipe would be sweet.) > A pointer to a C++ structure does not appear to protect the > corresponding SMOB data and free_smob calls the delete operator which > calls destructors and clobbers the memory area. Oh, I was mistaken in my previous message. GC scans the stack and the GC-managed heap (stuff allocated with GC_MALLOC/scm_gc_malloc et al.), but it does *not* scan the malloc/new heap. So indeed, C++ objects that hold references to =E2=80=98SCM=E2=80=99 object= s, such as instances of =E2=80=98Smob=E2=80=99, must either have a mark function, o= r they must be allocated with scm_gc_malloc. Would it be possible to add a =E2=80=98new=E2=80=99 operator to =E2=80=98Sm= ob=E2=80=99 that uses =E2=80=98scm_gc_malloc=E2=80=99, and a =E2=80=98delete=E2=80=99 operator th= at uses =E2=80=98scm_gc_free=E2=80=99? Thanks, Ludo=E2=80=99.