Hi, I don't know whether this one is related to the previous ones but I successfully made the garbage collector crash again with a different code :) (OCE 0.6.0, pythonocc main) I have attached the code. Probably it's a different one, it seems to be a double free. (python(5159) malloc: *** error for object 0x10d134400: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug)
And a question: I don't really understand why the GC is even
neccessary. Why can't the GC code just simply placed into the
overridden __del__ methods?
István
On Sun, Oct 2, 2011 at 10:29 AM, Thomas Paviot <tpav...@gmail.com> wrote:
> 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
>
>
yet_another_memory_error.py
Description: Binary data
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
