Istvan,
I reproduced the issue (segfault or leak). Try with the following
force_purge() method:
def force_purge(self):
while len(self._transients)>0:
transient = self._transients.pop()
transient._kill_pointed()
transient.was_purged = True
while len(self._misc)>0:
misc = self._misc.pop()
misc._kill_pointed()
misc.was_purged = True
while len(self._handles)>0:
handle = self._handles.pop()
handle.was_purged = True
With MMGT_OPT=1, MMGT_OPT=2 or undefined MMGT_OPT, this should do the job
(no crash, no leak). It's a tweak however, it seems that the smart_purge()
method conflicts with the OCC StackManager. I need to dig into this issue. I
will soon push a tp/memory-mgt-improvements branch to the github repos, stay
tuned.
Thomas
2011/10/1 István Csanády <istvancsan...@gmail.com>
> I have installed OCE 0.6.0, and the pythonocc current master, still the
> previous problem: with force_purge() it crashes with smart_purge() it leaks.
> Check the attached code.
>
>
> On Fri, Sep 30, 2011 at 3:33 PM, Thomas Paviot <tpav...@gmail.com> wrote:
>
>> The OCC API changed between 6.3.0 and 6.5.1. As a consequence, pythonocc
>> SWIG files were updated to be consistent with the new API. You need OCC6.5.1
>> or OCE-0.6.0 to be able to run pythonocc current master.
>>
>> Thomas
>>
>>
>> 2011/9/30 István Csanády <istvancsan...@gmail.com>
>>
>>> I was going to rebulid pythonocc 0.5 with OCE 0.6.0 to try to check if
>>> the code I sent does still crash or not with 0.6.0, but it misses
>>> BinLPlugin. Do I have to download the latest pythonocc version to build with
>>> OCE?
>>>
>>> On Fri, Sep 30, 2011 at 11:13 AM, Thomas Paviot <tpav...@gmail.com>wrote:
>>>
>>>> 2011/9/30 D. Barbier <bou...@gmail.com>
>>>>
>>>>> On 2011/9/30 István Csanády wrote:
>>>>> > Thanks Thomas, this solved the leaking issue. Any ideas for a
>>>>> workaround for
>>>>> > the MMGrOpt crash (when I don't remove gcurve.GetObject())? Or I will
>>>>> have
>>>>> > to wait for pyocc 0.6?
>>>>>
>>>>> Hello,
>>>>>
>>>>> Can you please check whether your crash happens with OCE 0.6.0? We
>>>>> fixed a bug which looks similar, so maybe it is gone.
>>>>> If it crashes, how can I reproduce it? I tried your
>>>>> example_GC_istvan.py file with MMGT_OPT set to 0, but it does not
>>>>> crash.
>>>>>
>>>>
>>>> On OSX/pythonocc current master/OCE-0.6.0, crash with MMGT_OPT=0,
>>>> MMGT_OPT=2 but succeed with MMGT_OPT=1.
>>>>
>>>>
>>>>>
>>>>> > Last night I have been profiling some pythonocc code and I have
>>>>> noticed that
>>>>> > collect_object is a quite slow even if I remove logging. Probably it
>>>>> has
>>>>> > some potential to increase pythonocc's performance. Since it is
>>>>> always
>>>>> > called when an object is destructed it makes sense to remove somehow
>>>>> the
>>>>> > costly string compares for the Handle objects. For example if it is
>>>>> possible
>>>>> > in OCE in the Handle class generator (handle classes are generated
>>>>> > automatically, aren't they?) can be modified that every Handle class
>>>>> should
>>>>> > subclass from an empty marker class (eg. class HandleMarkerClass{})
>>>>> and this
>>>>> > can be used in the GC by checking only
>>>>> > isinstance(obj_deleted,HandleMarkerClass), removing
>>>>> > the obj_deleted.__class__.__name__.startswith('Handle').
>>>>>
>>>>> AFAICT all handles derive from either Handle_Standard_Transient or
>>>>> Handle_Standard_Persistent, so your solution can be implemented
>>>>> without changes in C++ code.
>>>>>
>>>>> > The hasattr calls
>>>>> > might also can be replaced by some tricky way but I don't know if it
>>>>> worth
>>>>> > it but I think it does since hasattr searches in a python dictionary
>>>>> which
>>>>> > is a hashmap and a single isinstance is might be less costly than a
>>>>> dict
>>>>> > lookup. But replacing somehow the string compare IMO would definitely
>>>>> worth
>>>>> > it.
>>>>> > But these are only ideas I don't know OCC's structure very well.
>>>>>
>>>>> I guess that
>>>>> hasattr(obj_deleted,"GetHandle")
>>>>> can be replaced by
>>>>> isinstance(deleted, OCC.Standard.Standard_Transient) or
>>>>> isinstance(deleted, OCC.Standard.Standard_Persistent)
>>>>>
>>>>
>>>> Absolutely. That's what I implemented in my previous attachment.
>>>>
>>>>
>>>>>
>>>>> Denis
>>>>>
>>>>
>>>> Thomas
>>>>
>>>>
>>>> _______________________________________________
>>>> Pythonocc-users mailing list
>>>> Pythonocc-users@gna.org
>>>> https://mail.gna.org/listinfo/pythonocc-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Pythonocc-users mailing list
>>> Pythonocc-users@gna.org
>>> https://mail.gna.org/listinfo/pythonocc-users
>>>
>>>
>>
>> _______________________________________________
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>>
>>
>
> _______________________________________________
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
