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 15:03:22 +0100 Message-ID: <87fv9sahxx.fsf@gnu.org> References: <87twyln70f.fsf@fencepost.gnu.org> <873865n2rr.fsf@fencepost.gnu.org> <87twy91vtc.fsf@gnu.org> <878ufld1iw.fsf@fencepost.gnu.org> <87k2z4dhx7.fsf@gnu.org> <874mq8dfb3.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1424959470 7596 80.91.229.3 (26 Feb 2015 14:04:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Feb 2015 14:04:30 +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 15:04:17 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 1YQz32-0002Po-8I for guile-bugs@m.gmane.org; Thu, 26 Feb 2015 15:04:16 +0100 Original-Received: from localhost ([::1]:59194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQz31-0002ZQ-EG for guile-bugs@m.gmane.org; Thu, 26 Feb 2015 09:04:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQz2q-0002T5-Hw for bug-guile@gnu.org; Thu, 26 Feb 2015 09:04:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQz2o-0005VJ-8x for bug-guile@gnu.org; Thu, 26 Feb 2015 09:04:04 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQz2o-0005VF-59 for bug-guile@gnu.org; Thu, 26 Feb 2015 09:04:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YQz2n-0004Ws-QC for bug-guile@gnu.org; Thu, 26 Feb 2015 09:04: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 14:04: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.142495940817366 (code B ref 19883); Thu, 26 Feb 2015 14:04:01 +0000 Original-Received: (at 19883) by debbugs.gnu.org; 26 Feb 2015 14:03:28 +0000 Original-Received: from localhost ([127.0.0.1]:58356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQz2G-0004W1-2a for submit@debbugs.gnu.org; Thu, 26 Feb 2015 09:03:28 -0500 Original-Received: from fencepost.gnu.org ([208.118.235.10]:48667 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YQz2D-0004Vq-Pi for 19883@debbugs.gnu.org; Thu, 26 Feb 2015 09:03:26 -0500 Original-Received: from pluto.bordeaux.inria.fr ([193.50.110.57]:51386 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YQz2C-0001Dd-Us; Thu, 26 Feb 2015 09:03:25 -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: <874mq8dfb3.fsf@fencepost.gnu.org> (David Kastrup's message of "Thu, 26 Feb 2015 13:32:00 +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:7729 Archived-At: --=-=-= Content-Type: text/plain David Kastrup skribis: > Is there a reason you are not using the test program provided with this > bug report? Sorry, I had overlooked it. Please assume good faith. With this patch: --=-=-= Content-Type: text/x-patch Content-Disposition: inline diff --git a/smobs.tcc b/smobs.tcc index c8b9dfe..b1d61b7 100644 --- a/smobs.tcc +++ b/smobs.tcc @@ -132,9 +132,6 @@ void Smob_base::init () // types in order to be able to compare them. The other comparisons // are for static member functions and thus are ordinary function // pointers which work without those contortions. - if (static_cast(&Super::mark_smob) != - static_cast(&Smob_base::mark_smob)) - scm_set_smob_mark (smob_tag_, Super::mark_trampoline); scm_set_smob_print (smob_tag_, Super::print_trampoline); if (&Super::equal_p != &Smob_base::equal_p) scm_set_smob_equalp (smob_tag_, Super::equal_p); --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =E2=80=9C./test 1000 1000 10000=E2=80=9D works fine. However, it=E2=80=99s not representative since the C++ objects in this test= do not hold =E2=80=98SCM=E2=80=99 references, AFAICS. > LilyPond's GUILEv2 branch is currently out of order again since 2.0.11 > changed encoding mechanisms _again_ Please submit a different bug report. >>> 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 obj= ects, such as >> instances of =E2=80=98Smob=E2=80=99, must either have a mark function= , or 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= =98Smob=E2=80=99 that uses >> =E2=80=98scm_gc_malloc=E2=80=99, and a =E2=80=98delete=E2=80=99 operator= that uses =E2=80=98scm_gc_free=E2=80=99? > > It would not help since many of the references are stored in STL > containers (like std::vector ) which have their data > allocated/deallocated separately from the memory area of the structure > itself. Oh, OK. Still, I don=E2=80=99t think this is a problem because each C++ ob= ject has a corresponding SMOB, and said SMOB is GC-protected; thus the C++ object itself is also GC-protected until the SMOB is unprotected. Here=E2=80=99s the patch I=E2=80=99ve ended up with: --=-=-= Content-Type: text/x-patch Content-Disposition: inline diff --git a/smobs.hh b/smobs.hh index 3701280..a41a645 100644 --- a/smobs.hh +++ b/smobs.hh @@ -263,6 +263,20 @@ private: protected: Smob () : self_scm_ (SCM_UNDEFINED), protection_cons_ (SCM_EOL) { }; public: + static void *operator new (std::size_t size) + { + /* This C++ object is referred to by the corresponding SMOB, which is + itself GC-protected. Thus, no need to protect the C++ object. */ + return scm_gc_malloc (size, "lily-smob"); + } + + static void operator delete (void *thing) + { + /* Nothing to do: the GC will reclaim memory for THING when it deems + appropriate. */ + // printf ("delete %p\n", thing); + } + static size_t free_smob (SCM obj) { delete Smob_base::unregister_ptr (obj); diff --git a/smobs.tcc b/smobs.tcc index c8b9dfe..0eb0c30 100644 --- a/smobs.tcc +++ b/smobs.tcc @@ -31,7 +31,7 @@ template SCM Smob_base::mark_trampoline (SCM arg) { - return (Super::unsmob (arg))->mark_smob (); + abort (); } template @@ -60,14 +60,14 @@ template SCM Smob_base::mark_smob () { - return SCM_UNSPECIFIED; + abort (); } template size_t Smob_base::free_smob (SCM) { - return 0; + abort (); } template @@ -125,16 +125,11 @@ void Smob_base::init () // While that's not a consideration for type_p_name_, it's easier // doing it like the rest. - if (&Super::free_smob != &Smob_base::free_smob) - scm_set_smob_free (smob_tag_, Super::free_smob); // Old GCC versions get their type lattice for pointers-to-members // tangled up to a degree where we need to typecast _both_ covariant // types in order to be able to compare them. The other comparisons // are for static member functions and thus are ordinary function // pointers which work without those contortions. - if (static_cast(&Super::mark_smob) != - static_cast(&Smob_base::mark_smob)) - scm_set_smob_mark (smob_tag_, Super::mark_trampoline); scm_set_smob_print (smob_tag_, Super::print_trampoline); if (&Super::equal_p != &Smob_base::equal_p) scm_set_smob_equalp (smob_tag_, Super::equal_p); diff --git a/test.cc b/test.cc index b5ab476..6bbd435 100644 --- a/test.cc +++ b/test.cc @@ -41,9 +41,7 @@ Family::Family (int totals, int branch) SCM Family::mark_smob () { - for (int i = 0; i < kids.size (); i++) - scm_gc_mark (kids[i]->self_scm ()); - return SCM_EOL; + abort (); } int @@ -51,7 +49,11 @@ Family::count () { int sum = 1; for (int i = 0; i < kids.size (); i++) - sum += kids[i]->count (); + { + sum += kids[i]->count (); + if ((i % 100) == 0) + scm_gc (); + } return sum; } --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It works on this test case, and, assuming I correctly understand LilyPond=E2=80=99s use case, it may be a viable solution for LilyPond. Cou= ld you give it a try and report back? > Frankly, I don't get the current strategy of GUILE: basically any use of > scm_set_smob_mark will result in a function that can be called with > garbage from a smob that has already been deallocated via the function > registered with scm_set_smob_free. That=E2=80=99s not true. For example, the GnuTLS bindings use the exact sa= me code for 1.8 and 2.0 without any problems; it=E2=80=99s surely a simpler ex= ample than LilyPond, of course, but still. ~~~~~~~ In the interest of the Guile and LilyPond projects, I would like to improve our communication. Let me explain what my personal expectations are. First, like many others, I=E2=80=99m a volunteer with limited bandwidth. Thus, I really pre= fer bug reports that are as concise as possible and to-the-point; I can=E2=80= =99t afford to read so much. Second, I don=E2=80=99t want to mix issues: this bug report is about a spec= ific GC issue, not about an encoding issue. It=E2=80=99s better for me (and eve= ryone I guess) when a bug report remains focused. Third, we must fix these LilyPond vs. Guile 2 issues. You and others have spent a lot of time on this already. I think it would help to get everyone involved on both sides. Thus, could you Cc: this bug report to the LilyPond developer list, or the corresponding LilyPond bug report? This is really important to me. Please don=E2=80=99t take it personally or anything. I=E2=80=99m really tr= ying hard to see how we can improve the collaboration between the two projects. Thanks, Ludo=E2=80=99. --=-=-=--