Thank you very much Bruno for the links and hints, I understand there
probably is some bad practice here (see 3.).

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 ?

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..

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..



[1] if you would just add this line in NewtonIntegrator::action() (with the 
correct "include<pkg/dem/Shop.hpp>"), same kind of segfaults would occur

You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.

  Segfaults with boost::python::tuple during simulation loop

Status in Yade:

Bug description:

  I'm currently facing segmentation fault when using "my"
  MeasureCapStress post-processing engine (this constitutes a

  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 
  - *** 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,


  ### Script example ###
  # two contacting particles with a capillary bridge inbetween. Segfaults 
because of MeasureCapStress on my machine
  r1,r2 = 1e-4,4e-4



  ### End of script example ###

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:

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

Reply via email to