[Glass] Grrrr cannot migrate (class rename with subclasses and with a name of a deleted class)

Fri Sep 11 13:26:02 PDT 2015

Ok...it *seems* I am being able to reproduce the bug. I have added all the
steps and details in the issue tracker.

Let me know!

Cheers,

On Fri, Sep 11, 2015 at 4:28 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
> On Fri, Sep 11, 2015 at 4:17 PM, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>> Excellent! There's a bug for that[1] ... if you can reproduce it ..
>>
>>
> "Challengeeeee   ..... Accepted!!!" like Barny hahahaha.
> Ok...will see if I can reproduce it.
>
>
>> Dale
>>
>> [1] https://github.com/GsDevKit/GsDevKit/issues/74
>>
>>
>> On 09/11/2015 12:10 PM, Mariano Martinez Peck wrote:
>>
>>
>>
>> On Fri, Sep 11, 2015 at 4:06 PM, Dale Henrichs <
>> dale.henrichs at gemtalksystems.com> wrote:
>>
>>> Okay ... now that the bug is characterized we'll be able to determine if
>>> it exists in older versions or not ... the code in this area has been
>>> reworked for 3.2+ ...
>>>
>>>
>> Indeed.
>>
>>
>>> Which brings us to the second problem ... since I am entering the bug
>>> sweep, it will be worth creating a test case to produce the "2 metaclasses
>>> / 2 classes for the same class" and I plan to do that (if I can) and then
>>> see if there is a reasonable resolution (not sure:) ...
>>>
>>>
>> Yes! I will see if I can reproduce that too today. Basically, I had this:
>>
>>
>> Object
>> - *FaSecurityClosingPriceRecord* (no instances)
>> - SpecialSuperclass
>> - - *FaSecurityClosingPriceRecord2* (many instances)
>> - - - FSCPR2a (instances)
>> - - - FSCPR2b (instances)
>>
>>
>> and then I committed a monticello change with this:
>>
>> Object
>> - SpecialSuperclass
>> - - *FaSecurityClosingPriceRecord* (many instances....and note there is
>> no 2 at the end)
>> - - - FSCPR2a (instances)
>> - - - FSCPR2b (instances)
>>
>> I will see if I can reproduce it too using dummy classes.
>>
>> Cheers,
>>
>>
>> Dale
>>>
>>>
>>> On 09/11/2015 11:31 AM, Mariano Martinez Peck wrote:
>>>
>>> Hi Dale,
>>>
>>> Ok, I increased the SPC at 2GB and I put a TOC of 1.8GB. Now, the code
>>> update DOES WORK and does not crash anymore.
>>> However, the resulting stuff is again the 2 metaclasses / 2 classes for
>>> the same class. So I think we are dealing with 2 problems:
>>>
>>> 1) One was that the listInstances thingy was clearly failing because of
>>> TOC size. As you just found out.
>>> 2) This kind of code refactor I needed, does not seem to be correctly
>>> performed by Monticello. The way to solve this was performing the manual
>>> thing that James and Martin recommended at the very beginning of this
>>> thread. This change also avoided migration and so avoided the listInstaces
>>> issue too.
>>>
>>> So... I think those are the 2 problems and conclusions. I don't think we
>>> should continue investigating more. Thoughts?
>>>
>>> Thank you very much for keeping searching for this and for the engineers
>>> also.
>>>
>>>
>>>
>>> On Fri, Sep 11, 2015 at 2:03 PM, Dale Henrichs <
>>> dale.henrichs at gemtalksystems.com> wrote:
>>>
>>>>
>>>>
>>>> On 09/09/2015 06:24 AM, Mariano Martinez Peck wrote:
>>>>
>>>>
>>>> On Tue, Sep 8, 2015 at 7:00 PM, Dale Henrichs <
>>>> dale.henrichs at gemtalksystems.com> wrote:
>>>>
>>>>> Mariano,
>>>>>
>>>>> I just talked with engineering and they concur that this is likely to
>>>>> be a malloc failure and the this area of the code has been substantially
>>>>> reworked in recent releases to attempt to reduce the amount of RAM consumed
>>>>> during list instances ...
>>>>>
>>>>> So for 3.1.0.6, you might try this operation with more RAM available
>>>>> or perhaps just adding more swap space will allow the malloc to complete
>>>>> ... running statmon with a 1 second interval and looking at the heap
>>>>> consumption of the gem, might show  growth and a "sudden decline" when the
>>>>> malloc fails ...
>>>>>
>>>>
>>>> Hi Dale,
>>>>
>>>> Just for the record, I tried with this scenario:
>>>>
>>>> [marianopeck at quuveserver1 ~]$ free -m
>>>>               total        used        free      shared  buff/cache
>>>> available
>>>> Mem:           8014         388        6850         359         775
>>>>    7205
>>>> Swap:         16639           0       16639
>>>>
>>>> And still didn't work. Note that I have 7GB of RAM free. At the end,
>>>> when the system crashed, this was the resulting state:
>>>>
>>>> [marianopeck at quuveserver1 ~]$ free -m
>>>>               total        used        free      shared  buff/cache
>>>> available
>>>> Mem:           8014         338        1316         973        6359
>>>>    6639
>>>> Swap:         16639           0       16639
>>>>
>>>>
>>>> Anyway, no problem, I would assume this is a problem in 3.1.0.6 and
>>>> hopefully I will never need to list instances / migrate this class until I
>>>> am in 3.2/3.3...
>>>>
>>>>
>>>> Okay, we've read code and to sorta confirm your experience, we _do not_
>>>> return a nil when the malloc fails ... So we're  reading more code, but our
>>>> suspicion now is that you are running out of TOC and the"normal"  failure
>>>> mechanisms aren't being triggered  ... to help confirm this suspicion we
>>>> think that you can try two independent things:
>>>>
>>>>   1. trigger an in-vm scavenge before making a call and/or
>>>>   2. bump up the TOC for that particular vm and see if you can find a
>>>> size that works ...
>>>>
>>>> The journey continues...
>>>>
>>>> Dale
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150911/34ab0f02/attachment.html>