[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4997 Add Preinit class for early initialization
- **status**: Fixed --> Verified --- ** [issues:#4997] Add Preinit class for early initialization** **Status:** Verified **Labels:** FIxed_2_19_51 **Created:** Sat Nov 12, 2016 10:03 PM UTC by David Kastrup **Last Updated:** Sat Nov 19, 2016 01:23 PM UTC **Owner:** David Kastrup Add Preinit class for early initialization This patch series may well be incomplete: strictly speaking, it might be needed with Guile 1.8 already to ensure parts of derived classes are not being scanned and interpreted by the mark_smob hooks before they are initialized. However, the semi-asynchronous nature of Guile 2.0 makes this situation more troubling. I don't have positive proof that this code avoids actual crashes in the context of either Guile 1.8 or Guile 2.0. While the implementation is rather simple (and cannot be made much more complicated since it has to work with objects in seriously incomplete form), its necessity is headache-inducing. But if its necessity turns out to be of more than theoretical nature, I'd rather have it in the code base sooner than later. Probably some other derived classes than those addressed in the followup patches should get the same treatment. Here is the commit message for the first patch of the series, followed by the others: This is a tricky thing: once a base class calls smobify_self () in its constructor, further allocations during construction of base class and derived classes might lead to mark_smob calls on the object under construction. When those call a virtual function like derived_mark, the virtual function corresponding to the incompletely initialized object is likely to be called. This situation is acerbated in Guile 2.0 where the mark passes may occur with only loose synchronization to the allocations. The order of initialization of an object consists in calling the constructors of virtual base classes, then of non-virtual base classes, then initializing all data members. As a result, the derived constructor comes too late for initialization. That's where the Preinit template class comes in. Derive from it _before_ deriving from the smobifying base class providing derived_mark, and it will call its Base class' pre_init function (which must not rely on the instantiation being complete). The pre_init function should then put the derived class into a state _before_ its constructor or a constructor of its data members is being called where it's safe to call its derived_mark function. Note that in particular that most STL data structures are in undefined state before their constructor is being called, so the pre_init function has to establish a state where derived_mark will not attempt to interpret data members of types like std::vector which may not have been constructed yet. Use Preinit for Global_context, protect output definition Use Preinit for font metrics Use Preinit in Engraver_group Use Preinit in Spanner Use Preinit in Music Use Preinit class in Scheme_engraver This avoids calls of derived_mark on uninitialized data. Fold Scheme_engraver::init_from_scheme (SCM) into converting constructor since it has become identical to it. http://codereview.appspot.com/316890043 --- Sent from sourceforge.net because testlilyissues-a...@lists.sourceforge.net is subscribed to https://sourceforge.net/p/testlilyissues/issues/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Testlilyissues-auto mailing list testlilyissues-a...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4997 Add Preinit class for early initialization
- **labels**: --> FIxed_2_19_51 - **status**: Started --> Fixed - **Patch**: push --> - **Comment**: author David Kastrup Sat, 4 Jun 2016 12:09:08 + (14:09 +0200) committer David Kastrup Fri, 18 Nov 2016 20:49:58 + (21:49 +0100) commit 0943e805fa82ebeb1d1ed32e675070467e340c39 author David Kastrup Sat, 4 Jun 2016 12:11:31 + (14:11 +0200) committer David Kastrup Fri, 18 Nov 2016 20:49:58 + (21:49 +0100) commit 6f5133448f7f6daf27191f12b411c70942751b50 author David Kastrup Sat, 4 Jun 2016 15:41:05 + (17:41 +0200) committer David Kastrup Fri, 18 Nov 2016 20:49:58 + (21:49 +0100) commit 402fcf51e5a567209b0293ef4e387315a8c5c2a4 author David Kastrup Sat, 4 Jun 2016 15:41:23 + (17:41 +0200) committer David Kastrup Fri, 18 Nov 2016 20:49:58 + (21:49 +0100) commit 2df973cc940e9bf1862579a80a2f94a009c8f621 author David Kastrup Sat, 4 Jun 2016 16:13:13 + (18:13 +0200) committer David Kastrup Fri, 18 Nov 2016 20:49:58 + (21:49 +0100) commit b6ab7b0d552591f2039fd2c83c3566d7c2ce5d37 author David Kastrup Sat, 4 Jun 2016 17:00:16 + (19:00 +0200) committer David Kastrup Fri, 18 Nov 2016 20:49:58 + (21:49 +0100) commit 3cdc909d8cea64c8faef90d3a6a391f32a424ba2 author David Kastrup Sat, 4 Jun 2016 17:31:31 + (19:31 +0200) committer David Kastrup Fri, 18 Nov 2016 20:49:58 + (21:49 +0100) commit b0dce4ca74c6ebf43a3f574ccf281b8bc58a3b75 --- ** [issues:#4997] Add Preinit class for early initialization** **Status:** Fixed **Labels:** FIxed_2_19_51 **Created:** Sat Nov 12, 2016 10:03 PM UTC by David Kastrup **Last Updated:** Fri Nov 18, 2016 07:58 PM UTC **Owner:** David Kastrup Add Preinit class for early initialization This patch series may well be incomplete: strictly speaking, it might be needed with Guile 1.8 already to ensure parts of derived classes are not being scanned and interpreted by the mark_smob hooks before they are initialized. However, the semi-asynchronous nature of Guile 2.0 makes this situation more troubling. I don't have positive proof that this code avoids actual crashes in the context of either Guile 1.8 or Guile 2.0. While the implementation is rather simple (and cannot be made much more complicated since it has to work with objects in seriously incomplete form), its necessity is headache-inducing. But if its necessity turns out to be of more than theoretical nature, I'd rather have it in the code base sooner than later. Probably some other derived classes than those addressed in the followup patches should get the same treatment. Here is the commit message for the first patch of the series, followed by the others: This is a tricky thing: once a base class calls smobify_self () in its constructor, further allocations during construction of base class and derived classes might lead to mark_smob calls on the object under construction. When those call a virtual function like derived_mark, the virtual function corresponding to the incompletely initialized object is likely to be called. This situation is acerbated in Guile 2.0 where the mark passes may occur with only loose synchronization to the allocations. The order of initialization of an object consists in calling the constructors of virtual base classes, then of non-virtual base classes, then initializing all data members. As a result, the derived constructor comes too late for initialization. That's where the Preinit template class comes in. Derive from it _before_ deriving from the smobifying base class providing derived_mark, and it will call its Base class' pre_init function (which must not rely on the instantiation being complete). The pre_init function should then put the derived class into a state _before_ its constructor or a constructor of its data members is being called where it's safe to call its derived_mark function. Note that in particular that most STL data structures are in undefined state before their constructor is being called, so the pre_init function has to establish a state where derived_mark will not attempt to interpret data members of types like std::vector which may not have been constructed yet. Use Preinit for Global_context, protect output definition Use Preinit for font metrics Use Preinit in Engraver_group Use Preinit in Spanner Use Preinit in Music Use Preinit class in Scheme_engraver This avoids calls of derived_mark on uninitialized data. Fold Scheme_engraver::init_from_scheme (SCM) into converting constructor since it has become identical to it. http://codereview.appspot.com/316890043 --- Sent from sourceforge.net because testlilyissues-a...@lists.sourceforge.net is subscribed to https://sourceforge.net/p/testlilyissues/issues/ To unsubscribe from further messages,
[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4997 Add Preinit class for early initialization
- **Patch**: countdown --> push - **Comment**: Patch counted down - please push --- ** [issues:#4997] Add Preinit class for early initialization** **Status:** Started **Created:** Sat Nov 12, 2016 10:03 PM UTC by David Kastrup **Last Updated:** Tue Nov 15, 2016 11:27 AM UTC **Owner:** David Kastrup Add Preinit class for early initialization This patch series may well be incomplete: strictly speaking, it might be needed with Guile 1.8 already to ensure parts of derived classes are not being scanned and interpreted by the mark_smob hooks before they are initialized. However, the semi-asynchronous nature of Guile 2.0 makes this situation more troubling. I don't have positive proof that this code avoids actual crashes in the context of either Guile 1.8 or Guile 2.0. While the implementation is rather simple (and cannot be made much more complicated since it has to work with objects in seriously incomplete form), its necessity is headache-inducing. But if its necessity turns out to be of more than theoretical nature, I'd rather have it in the code base sooner than later. Probably some other derived classes than those addressed in the followup patches should get the same treatment. Here is the commit message for the first patch of the series, followed by the others: This is a tricky thing: once a base class calls smobify_self () in its constructor, further allocations during construction of base class and derived classes might lead to mark_smob calls on the object under construction. When those call a virtual function like derived_mark, the virtual function corresponding to the incompletely initialized object is likely to be called. This situation is acerbated in Guile 2.0 where the mark passes may occur with only loose synchronization to the allocations. The order of initialization of an object consists in calling the constructors of virtual base classes, then of non-virtual base classes, then initializing all data members. As a result, the derived constructor comes too late for initialization. That's where the Preinit template class comes in. Derive from it _before_ deriving from the smobifying base class providing derived_mark, and it will call its Base class' pre_init function (which must not rely on the instantiation being complete). The pre_init function should then put the derived class into a state _before_ its constructor or a constructor of its data members is being called where it's safe to call its derived_mark function. Note that in particular that most STL data structures are in undefined state before their constructor is being called, so the pre_init function has to establish a state where derived_mark will not attempt to interpret data members of types like std::vector which may not have been constructed yet. Use Preinit for Global_context, protect output definition Use Preinit for font metrics Use Preinit in Engraver_group Use Preinit in Spanner Use Preinit in Music Use Preinit class in Scheme_engraver This avoids calls of derived_mark on uninitialized data. Fold Scheme_engraver::init_from_scheme (SCM) into converting constructor since it has become identical to it. http://codereview.appspot.com/316890043 --- Sent from sourceforge.net because testlilyissues-a...@lists.sourceforge.net is subscribed to https://sourceforge.net/p/testlilyissues/issues/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- ___ Testlilyissues-auto mailing list testlilyissues-a...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4997 Add Preinit class for early initialization
- Description has changed: Diff: - **Needs**: --> - **Patch**: new --> countdown - **Comment**: Passes make, make check and a full make doc. --- ** [issues:#4997] Add Preinit class for early initialization** **Status:** Started **Created:** Sat Nov 12, 2016 10:03 PM UTC by David Kastrup **Last Updated:** Sat Nov 12, 2016 10:03 PM UTC **Owner:** David Kastrup Add Preinit class for early initialization This patch series may well be incomplete: strictly speaking, it might be needed with Guile 1.8 already to ensure parts of derived classes are not being scanned and interpreted by the mark_smob hooks before they are initialized. However, the semi-asynchronous nature of Guile 2.0 makes this situation more troubling. I don't have positive proof that this code avoids actual crashes in the context of either Guile 1.8 or Guile 2.0. While the implementation is rather simple (and cannot be made much more complicated since it has to work with objects in seriously incomplete form), its necessity is headache-inducing. But if its necessity turns out to be of more than theoretical nature, I'd rather have it in the code base sooner than later. Probably some other derived classes than those addressed in the followup patches should get the same treatment. Here is the commit message for the first patch of the series, followed by the others: This is a tricky thing: once a base class calls smobify_self () in its constructor, further allocations during construction of base class and derived classes might lead to mark_smob calls on the object under construction. When those call a virtual function like derived_mark, the virtual function corresponding to the incompletely initialized object is likely to be called. This situation is acerbated in Guile 2.0 where the mark passes may occur with only loose synchronization to the allocations. The order of initialization of an object consists in calling the constructors of virtual base classes, then of non-virtual base classes, then initializing all data members. As a result, the derived constructor comes too late for initialization. That's where the Preinit template class comes in. Derive from it _before_ deriving from the smobifying base class providing derived_mark, and it will call its Base class' pre_init function (which must not rely on the instantiation being complete). The pre_init function should then put the derived class into a state _before_ its constructor or a constructor of its data members is being called where it's safe to call its derived_mark function. Note that in particular that most STL data structures are in undefined state before their constructor is being called, so the pre_init function has to establish a state where derived_mark will not attempt to interpret data members of types like std::vector which may not have been constructed yet. Use Preinit for Global_context, protect output definition Use Preinit for font metrics Use Preinit in Engraver_group Use Preinit in Spanner Use Preinit in Music Use Preinit class in Scheme_engraver This avoids calls of derived_mark on uninitialized data. Fold Scheme_engraver::init_from_scheme (SCM) into converting constructor since it has become identical to it. http://codereview.appspot.com/316890043 --- Sent from sourceforge.net because testlilyissues-a...@lists.sourceforge.net is subscribed to https://sourceforge.net/p/testlilyissues/issues/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- ___ Testlilyissues-auto mailing list testlilyissues-a...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #4997 Add Preinit class for early initialization
--- ** [issues:#4997] Add Preinit class for early initialization** **Status:** Started **Created:** Sat Nov 12, 2016 10:03 PM UTC by David Kastrup **Last Updated:** Sat Nov 12, 2016 10:03 PM UTC **Owner:** nobody Add Preinit class for early initialization This patch series may well be incomplete: strictly speaking, it might be needed with Guile 1.8 already to ensure parts of derived classes are not being scanned and interpreted by the mark_smob hooks before they are initialized. However, the semi-asynchronous nature of Guile 2.0 makes this situation more troubling. I don't have positive proof that this code avoids actual crashes in the context of either Guile 1.8 or Guile 2.0. While the implementation is rather simple (and cannot be made much more complicated since it has to work with objects in seriously incomplete form), its necessity is headache-inducing. But if its necessity turns out to be of more than theoretical nature, I'd rather have it in the code base sooner than later. Probably some other derived classes than those addressed in the followup patches should get the same treatment. Here is the commit message for the first patch of the series, followed by the others: This is a tricky thing: once a base class calls smobify_self () in its constructor, further allocations during construction of base class and derived classes might lead to mark_smob calls on the object under construction. When those call a virtual function like derived_mark, the virtual function corresponding to the incompletely initialized object is likely to be called. This situation is acerbated in Guile 2.0 where the mark passes may occur with only loose synchronization to the allocations. The order of initialization of an object consists in calling the constructors of virtual base classes, then of non-virtual base classes, then initializing all data members. As a result, the derived constructor comes too late for initialization. That's where the Preinit template class comes in. Derive from it _before_ deriving from the smobifying base class providing derived_mark, and it will call its Base class' pre_init function (which must not rely on the instantiation being complete). The pre_init function should then put the derived class into a state _before_ its constructor or a constructor of its data members is being called where it's safe to call its derived_mark function. Note that in particular that most STL data structures are in undefined state before their constructor is being called, so the pre_init function has to establish a state where derived_mark will not attempt to interpret data members of types like std::vector which may not have been constructed yet. Use Preinit for Global_context, protect output definition Use Preinit for font metrics Use Preinit in Engraver_group Use Preinit in Spanner Use Preinit in Music Use Preinit class in Scheme_engraver This avoids calls of derived_mark on uninitialized data. Fold Scheme_engraver::init_from_scheme (SCM) into converting constructor since it has become identical to it. http://codereview.appspot.com/316890043 --- Sent from sourceforge.net because testlilyissues-a...@lists.sourceforge.net is subscribed to https://sourceforge.net/p/testlilyissues/issues/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Testlilyissues-auto mailing list testlilyissues-a...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
