[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop
Initial MeasureCapStress problem fixed in commit 68b0557. The possible use of e.g. boost::python::extract during Engine::action() (see the link in #3) remains to be explored, as far as I'm concerned. ** Changed in: yade Status: New => Fix Released -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1764424 Title: Segfaults with boost::python::tuple during simulation loop Status in Yade: Fix Released Bug description: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3) ,NewtonIntegrator() ,GlobalStiffnessTimeStepper() ,MeasureCapStress(iterPeriod=1) ] O.run() ### End of script example ### [*] https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. While another boost:python: appears L64, it seems L63 is enough to cause the crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" (making L63 useless but still annoying enough to cause the crash) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1764424/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop
Hi Jerome, to find where the segfault problem comes from, you can run catchsegv yade script.py the output tells the last actions before the segfault. If the output is too long, you can try catchsegv yade script.py > /tmp/segv.err or catchsegv yade script.py 2> /tmp/segv.err (don't remember) and provde the segv.err file cheers Jan PS: this is exactly the point I mentioned in [1]. If you use these functions in C++, using boost::python stuff is extra, std::vector should be used instead of boost::python::tuple and the buust::python stuff should only be used to interact with Python :-) [1] https://www.mail-archive.com/yade- d...@lists.launchpad.net/msg13300.html -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1764424 Title: Segfaults with boost::python::tuple during simulation loop Status in Yade: New Bug description: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3) ,NewtonIntegrator() ,GlobalStiffnessTimeStepper() ,MeasureCapStress(iterPeriod=1) ] O.run() ### End of script example ### [*] https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. While another boost:python: appears L64, it seems L63 is enough to cause the crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" (making L63 useless but still annoying enough to cause the crash) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1764424/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop
For the record, see also https://www.mail-archive.com/yade- d...@lists.launchpad.net/msg13223.html -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1764424 Title: Segfaults with boost::python::tuple during simulation loop Status in Yade: New Bug description: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3) ,NewtonIntegrator() ,GlobalStiffnessTimeStepper() ,MeasureCapStress(iterPeriod=1) ] O.run() ### End of script example ### [*] https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. While another boost:python: appears L64, it seems L63 is enough to cause the crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" (making L63 useless but still annoying enough to cause the crash) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1764424/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop
Hi, Thank you very much Bruno for the links and hints, I understand there probably is some bad practice here (see 3.). 1. However, I'm quite sure the crash is just caused by the following line "boost::python::tuple extrema = Shop::aabbExtrema();" [1] I thus suspect incorrect Python/C++ extraction or items access are not the reason of the present crash ? 2. Actually, I would like to point out the following "funny" fact: 2.1. Asking ** O.run(100,True) # => crash ** at the end of the above MWE triggers (in one call to MeasureCapStress) the crash. (same with O.run()) 2.2. Asking ** for i in range(0,100): O.step() # => no crash ** instead of O.run does not trigger any crash. The ~100 calls to MeasureCapStress pass like a charm.. 3. The syntax I used in this MeasureCapStress code was directly inspired from what is done in getPorosity() [2], getStress() [3], or fabricTensor() [4] utils functions (which work, I guess). It's true none of those was probably intended to be used "within" the simulation loop, though.. Thanks, Jérôme [1] if you would just add this line in NewtonIntegrator::action() (with the correct "include"), same kind of segfaults would occur [2] https://github.com/yade/trunk/blob/d504abfec35f13e8b7e58ba3f59e5014c6196531/pkg/dem/Shop_01.cpp#L304 [3] https://github.com/yade/trunk/blob/c8be93791ffbc99b0e63275c1b866414391b27c0/pkg/dem/Shop_02.cpp#L352 [4] https://github.com/yade/trunk/blob/c8be93791ffbc99b0e63275c1b866414391b27c0/pkg/dem/Shop_02.cpp#L266 -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1764424 Title: Segfaults with boost::python::tuple during simulation loop Status in Yade: New Bug description: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3) ,NewtonIntegrator() ,GlobalStiffnessTimeStepper() ,MeasureCapStress(iterPeriod=1) ] O.run() ### End of script example ### [*] https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. While another boost:python: appears L64, it seems L63 is enough to cause the crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" (making L63 useless but still annoying enough to cause the crash) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1764424/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop
** Summary changed: - MeasureCapStress-caused segmentation fault (boost::python) + Segfaults with boost::python::tuple during simulation loop -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1764424 Title: Segfaults with boost::python::tuple during simulation loop Status in Yade: New Bug description: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3) ,NewtonIntegrator() ,GlobalStiffnessTimeStepper() ,MeasureCapStress(iterPeriod=1) ] O.run() ### End of script example ### [*] https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. While another boost:python: appears L64, it seems L63 is enough to cause the crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" (making L63 useless but still annoying enough to cause the crash) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1764424/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
