[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 14:51:25 PDT 2015
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/bf72c7ba/attachment-0001.html>
More information about the Glass
mailing list