← Back to team overview

yade-dev team mailing list archive

[Bug 1764424] [NEW] MeasureCapStress-caused segmentation fault (boost::python)

 

Public bug reported:

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: 0x00000000008fa220 ***
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)

** Affects: yade
     Importance: Undecided
         Status: New

-- 
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:
  MeasureCapStress-caused segmentation fault (boost::python)

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: 0x00000000008fa220 ***
  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


Follow ups