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 19:15:30 +0100 Message-ID: <87wq34zghp.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> <87fv9sahxx.fsf@gnu.org> <87wq34bsh7.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 1424974592 30189 80.91.229.3 (26 Feb 2015 18:16:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Feb 2015 18:16:32 +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 19:16:15 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 1YR2yr-0000Ve-De for guile-bugs@m.gmane.org; Thu, 26 Feb 2015 19:16:13 +0100 Original-Received: from localhost ([::1]:60305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR2yq-00039p-RH for guile-bugs@m.gmane.org; Thu, 26 Feb 2015 13:16:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR2yj-0002vY-KO for bug-guile@gnu.org; Thu, 26 Feb 2015 13:16:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YR2yh-0000go-0j for bug-guile@gnu.org; Thu, 26 Feb 2015 13:16:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YR2yg-0000gi-TD for bug-guile@gnu.org; Thu, 26 Feb 2015 13:16:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YR2yg-0002Bg-JN for bug-guile@gnu.org; Thu, 26 Feb 2015 13:16:02 -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 18:16:02 +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.14249745368346 (code B ref 19883); Thu, 26 Feb 2015 18:16:02 +0000 Original-Received: (at 19883) by debbugs.gnu.org; 26 Feb 2015 18:15:36 +0000 Original-Received: from localhost ([127.0.0.1]:58933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YR2yF-0002AW-MT for submit@debbugs.gnu.org; Thu, 26 Feb 2015 13:15:36 -0500 Original-Received: from fencepost.gnu.org ([208.118.235.10]:57932 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YR2yE-0002AO-4T for 19883@debbugs.gnu.org; Thu, 26 Feb 2015 13:15:34 -0500 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]:48780 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1YR2yD-0003XE-BD; Thu, 26 Feb 2015 13:15:33 -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: <87wq34bsh7.fsf@fencepost.gnu.org> (David Kastrup's message of "Thu, 26 Feb 2015 16:30:28 +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:7731 Archived-At: David Kastrup skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> David Kastrup skribis: [...] >>> 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++ >> object has a corresponding SMOB, and said SMOB is GC-protected; thus >> the C++ object itself is also GC-protected until the SMOB is >> unprotected. > > The code given in test.cc is representative for LilyPond: most of the > C++ objects refer to other C++ objects via pointers, and the protection > of SMOB and C++ objects is managed through the mark callbacks. Complex > C++ objects contain their own SCM value as part of the Smob base class. > Simple C++ objects (derived from Simple_smob) don't and are only > optionally managed by GUILE. I don=E2=80=99t think this contradicts what I wrote above, does it? >> Here=E2=80=99s the patch I=E2=80=99ve ended up with: >> >> 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); >> + } >> + > > As I stated: this will not help with STL containers which are > extensively used in pretty much every data structure of LilyPond. Sorry, I don=E2=80=99t understand how it doesn=E2=80=99t help. It would be a problem is =E2=80=98Smob=E2=80=99 objects could be copied, th= us ending up in non-GC-scanned storage, but IIUC they cannot be copied because their copy constructor is private. What am I missing? At any rate, I don=E2=80=99t see any failure with the test program. >> 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. > > Shrug. I'll put a link to this bug report to a suitable LilyPond issue. Thank you. Though I want other LilyPond developers to get involved, and I=E2=80=99m afraid it would be easy for them to just ignore a side bug repo= rt. It=E2=80=99s a vital task for LilyPond, it cannot be a one-person side-proj= ect on the LilyPond side. Thanks in advance, Ludo=E2=80=99.