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

Fri Sep 11 12:28:28 PDT 2015

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150911/956b2ec1/attachment-0001.html>