[Glass] Grrrr cannot migrate (class rename with subclasses and with a name of a deleted class)
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Tue Sep 8 15:00:45 PDT 2015
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 ...
Dale
On 09/08/2015 02:51 PM, Dale Henrichs wrote:
> Thanks Mariano - yeah the args look okay - At this point, I'm
> suspicious that we're running out of memory during the scan and not
> failing "gracefully", but no evidence of that quite yet ...
>
> Dale
>
> On 09/08/2015 02:00 PM, Mariano Martinez Peck wrote:
>> OK Dale, I found out which was the problem, the code of printing
>> should have been placed inside the scanBlock. Anyway..I did that, and
>> then it did not work either because gem was crashing and so I
>> couldn't see the log from GemTools. So I then replaced Transcript
>> show: with "GsFile gciLogServer: " and now I got it the log:
>>
>> --LIST-FAILURE--_scanPomWithMaxThreads failure: 1 95 anIdentitySet(
>> FaSecurityAdjustedClosingPriceRecord) 0 0 nil
>>
>> Doesn't look like wrong, does it?
>>
>> Cheers,
>>
>> On Tue, Sep 8, 2015 at 5:03 PM, Dale Henrichs
>> <dale.henrichs at gemtalksystems.com
>> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>
>> Just rename the temps to ones that compile:)
>>
>> This time around we are not suspecting that blockClosures and
>> block temps are the problem, we are just trying to get the args
>> to the primitive call when it fails, so we can trace things
>> further in the C code and try determine the code path that leads
>> to a nil return value ...
>>
>> Dale
>>
>>
>> On 09/08/2015 12:49 PM, Mariano Martinez Peck wrote:
>>>
>>>
>>> On Tue, Sep 8, 2015 at 4:26 PM, Dale Henrichs
>>> <dale.henrichs at gemtalksystems.com
>>> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>>
>>> Mariano,
>>>
>>> Sorry for the delay, but I'm back in the office today and
>>> what we would like to do is capture the args that are being
>>> used for the primitive so replaicing the `memOnlyBool` block
>>> logic in the listInstances:.... method with the following
>>> will help us get them:
>>>
>>>
>>> Hi Dale, no worries, thanks for pushing!
>>>
>>> memOnlyBool
>>> ifFalse: [
>>> scanBlk := [ :scanSetThisTime | | ret sKind |
>>> sKind := (directoryString ifNotNil:[ 2 ] ifNil:[ 0 ]).
>>> ret := self
>>> _scanPomWithMaxThreads: maxThreads
>>> waitForLock: 60
>>> pageBufSize: 8
>>> percentCpuActiveLimit: aPercentage
>>> identSet: scanSetThisTime
>>> limit: aSmallInt
>>> scanKind: sKind
>>> toDirectory: directoryString ].
>>> ret ifNil: [
>>> Transcript cr; show: '_scanPomWithMaxThreads failure: ',
>>> maxThreads printString, ' ',
>>> aPercentage printString, ' ',
>>> scanSetThisTime printString, ' ',
>>> aSmallInt printString, ' ',
>>> sKind printString, ' ',
>>> directoryString printString ].
>>> ret ].
>>>
>>>
>>> This doesn't compile because 'sKind' was defined inside the
>>> 'scanBlk' and 'scanSetThisTime' is the argument to the closure.
>>> Since this problem was related to temp vars, I am not sure which
>>> is the correct solution.
>>>
>>> Let me know,
>>>
>>> We thought the problem might have been related to the method
>>> temp reference for `(directoryString ifNotNil:[ 2 ] ifNil:[
>>> 0 ])`, but since the prim is still failing with that
>>> expression inlined there must be a different (less obvious)
>>> failure mechanism.
>>>
>>> Dale
>>>
>>>
>>> On 09/01/2015 11:45 AM, Mariano Martinez Peck wrote:
>>>> OK then. Perfect. Let me know.
>>>> Thanks!
>>>>
>>>> On Tue, Sep 1, 2015 at 3:28 PM, Dale Henrichs
>>>> <dale.henrichs at gemtalksystems.com
>>>> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>>>
>>>>
>>>>
>>>> On 9/1/15 10:59 AM, Mariano Martinez Peck wrote:
>>>>>
>>>>> On Tue, Sep 1, 2015 at 2:14 PM, Dale Henrichs
>>>>> <dale.henrichs at gemtalksystems.com
>>>>> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>>>>
>>>>> Could you arrange to get a stack trace from your
>>>>> most recent error and a listing of the method that
>>>>> you used ... I want to make sure that we
>>>>> understand the failure mechanism ... if it is
>>>>> related to block temps then it is fixed in 3.2.x,
>>>>> but if it is not related to block temps then it
>>>>> could be present in later versions of GemStone and
>>>>> we'll want to characterize the problem ....
>>>>> Obviously, this particular call doesn't reproduce
>>>>> very frequently (I wasn't able to make it break
>>>>> with trivial examples) so there is likely to be
>>>>> something a little more complex going on ...
>>>>>
>>>>>
>>>>> Dale, the exception I get is the one I original shared
>>>>> with you and you got to the same conclusion as I did.
>>>>>
>>>>> What I can offer you is this that I log the error
>>>>> (continuation) in the object log and the provide you a
>>>>> user for the web user for our app and from there I can
>>>>> allow you open a kind of Seaside debugger/inspector
>>>>> which will be much richer than a plain string stack
>>>>> and at least you can also print/inspect from there. I
>>>>> cannot send you the extent because its quite big.
>>>>>
>>>>> If you think this is OK, then I please need you to ask
>>>>> you to only share the login info with GemTalks
>>>>> engineer. Since the site is a bit on use (but with a
>>>>> working extent) I must recover from backup and so the
>>>>> system will be running with a "broken" extent for a
>>>>> while. No problem with this but if this will be only a
>>>>> couple of hours or 1-2 day max. So if we will do this,
>>>>> I would appreciate that you let me know when (you or
>>>>> the engineer) would be available to take a look.
>>>>>
>>>>> Let me know if you want this.
>>>>>
>>>> Thanks for the offer ... we might want to instrument up
>>>> the method a bit more instead of looking at a
>>>> continuation ... so I will get back to you ... I won't
>>>> be in the office until Thursday, and that's when I will
>>>> talk things over with the engineer ...
>>>>
>>>> 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/20150908/fa2fd727/attachment-0001.html>
More information about the Glass
mailing list