[Glass] Grrrr cannot migrate (class rename with subclasses and with a name of a deleted class)
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Tue Sep 1 10:59:43 PDT 2015
On Tue, Sep 1, 2015 at 2:14 PM, Dale Henrichs <
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.
> There's always time to track down bugs, even if I get cranky from time to
> time:)
>
> Dale
>
>
> On 9/1/15 9:44 AM, Mariano Martinez Peck wrote:
>
> Hi Dale,
>
> I just tried but unfortunately I still got the same error.... I do not
> want to make you loose more time if this was fixed in newer gemstone
> versions. I just hope I do not get this error frequently in the future
> until I am able to migrate to newer versions. If you still want me to dig
> or try something else because of your convenience (like if you think there
> might still be a bug even for newer versions), then let me know.
>
> Thanks anyway for the help. Very much appreciated.
>
>
> On Mon, Aug 31, 2015 at 4:14 PM, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>>
>>
>> On 8/31/15 11:49 AM, Mariano Martinez Peck wrote:
>>
>>
>>
>> On Mon, Aug 31, 2015 at 3:38 PM, Dale Henrichs <
>> <dale.henrichs at gemtalksystems.com>dale.henrichs at gemtalksystems.com>
>> wrote:
>>
>>> Mariano,
>>>
>>> Here's a better patch (from engineering) ... there are bugs in the
>>> handling of temps and blocks (in 3.1.x) that appears to be the culprit (the
>>> code i.v. value was not correctly picked up ... do the calculation in the
>>> context of the block ... this is the preferred patch because the nil return
>>> value dod not imply an empty result set as my patch implied ... this one
>>> should give you correct results ... let me know if there are further
>>> problems):
>>>
>>>
>>
>> Thanks Dale and the rest of the engineers for the effort. I will test it
>> soon (I must restore from backup first and do a few things in order to
>> reproduce it again). In the meanwhile let me ask:
>>
>> 1) was this "temps and blocks" bugs solved in 3.2 or 3.3?
>>
>> I don't know the exact details ... the engineer I talked to was pretty
>> confident that this bug wasn't present in 3.2.x or 3.3.x.
>>
>> 2) Is there anything I should take care of for when I am using temps and
>> closures? I mean, were you able to fin the exact issue so that I can know
>> and not have those problems in my own code? I do remember the known problem
>> of seaside callbacks and temps and the usage of ValueHolder, but I don't
>> know if this is related or not.
>>
>> Since you are using 3.1.0.6, your best course of action might be to read
>> through the release notes for each of the 3.2.x releases[1] and see if
>> block/temp bugs were fixed or mentioned and then cross reference with
>> bugnotes[2] using the site-search[3].
>>
>> IIRC the particular bug in this case had to do with assigning the temp
>> that was only referenced in a block created before the temp assignment was
>> made - moving the temp assignment before the block was created could be a
>> workaround (I don't recall any additional details) ...
>>
>> Dale
>>
>> [1] https://gemtalksystems.com/products/gs64/versions32x/
>> [2] https://gemtalksystems.com/techsupport/bugnotes/
>> [3] https://cse.google.com/cse/home?cx=014580976650604809618:1cdoq5jo3te
>>
>>
>> Thanks in advance,
>>
>>
>>
>>> listInstances: anArray limit: aSmallInt toDirectory: directoryString
>>> withMaxThreads: maxThreads maxCpuUsage: aPercentage memoryOnly: memOnlyBool
>>> "If directoryString == nil, result includes in-memory objects.
>>>
>>> If memBool == true, result contains only the in-memory objects,
>>> and maxThreads and aPercentage are ignored."
>>>
>>> | inputSet resultInSetOrder result scanBlk |
>>> memOnlyBool
>>> ifFalse: [
>>> System needsCommit
>>> ifTrue: [ self _error: #'rtErrAbortWouldLoseData' ] ].
>>> inputSet := self _arrayOfClassesAsSet: anArray.
>>> inputSet size < 1
>>> ifTrue: [ ^ {} ].
>>> memOnlyBool
>>> ifFalse: [
>>> scanBlk := [ :scanSetThisTime |
>>> self
>>> _scanPomWithMaxThreads: maxThreads
>>> waitForLock: 60
>>> pageBufSize: 8
>>> percentCpuActiveLimit: aPercentage
>>> https://gemtalksystems.com/techsupport/bugnotes/ identSet:
>>> scanSetThisTime
>>> limit: aSmallInt
>>> scanKind: (directoryString ifNotNil:[ 2 ] ifNil:[ 0 ])
>>> toDirectory: directoryString ] ].
>>> inputSet := IdentitySet withAll: anArray.
>>> resultInSetOrder := self
>>> _doListInstancesFrom: inputSet
>>> with: scanBlk
>>> includeMemory: directoryString == nil.
>>> directoryString
>>> ifNotNil: [ result := resultInSetOrder "primitive wrote the
>>> files, so we are done" ]
>>> ifNil: [
>>> | inputArraySize |
>>> inputArraySize := anArray size.
>>> result := Array new: inputArraySize * 2.
>>> 1 to: inputArraySize do: [ :j |
>>> | soIdx resIdx anObj |
>>> anObj := anArray at: j.
>>> soIdx := (inputSet _offsetOf: anObj) * 2.
>>> resIdx := j * 2.
>>> result at: resIdx - 1 put: (resultInSetOrder at: soIdx - 1).
>>> "totalCount"
>>> result at: resIdx put: (resultInSetOrder at: soIdx) "array of
>>> instances" ] ].
>>> ^ result
>>>
>>>
>>> On 08/28/2015 03:09 PM, Dale Henrichs wrote:
>>>
>>> Here's an untested patch for
>>> Repository>>listInstances:limit:toDirectory:withMaxThreads:maxCpuUsage:memoryOnly:
>>> that you can try (Probably have to use topaz logged in as SystemUser to
>>> install this patch) based on 3.1.0.6:
>>>
>>> listInstances: anArray limit: aSmallInt toDirectory: directoryString
>>> withMaxThreads: maxThreads maxCpuUsage: aPercentage memoryOnly: memOnlyBool
>>> "If directoryString == nil, result includes in-memory objects.
>>>
>>> If memBool == true, result contains only the in-memory objects,
>>> and maxThreads and aPercentage are ignored."
>>>
>>> | inputSet resultInSetOrder result code scanBlk |
>>> memOnlyBool
>>> ifFalse: [
>>> System needsCommit
>>> ifTrue: [ self _error: #'rtErrAbortWouldLoseData' ] ].
>>> inputSet := self _arrayOfClassesAsSet: anArray.
>>> inputSet size < 1
>>> ifTrue: [ ^ {} ].
>>> memOnlyBool
>>> ifFalse: [
>>> scanBlk := [ :scanSetThisTime |
>>> (self
>>> _scanPomWithMaxThreads: maxThreads
>>> waitForLock: 60
>>> pageBufSize: 8
>>> percentCpuActiveLimit: aPercentage
>>> identSet: scanSetThisTime
>>> limit: aSmallInt
>>> scanKind: code
>>> toDirectory: directoryString) ifNil: [ #() ] ] ].
>>> code := directoryString ifNotNil: [ 2 ] ifNil: [ 0 ].
>>> inputSet := IdentitySet withAll: anArray.
>>> resultInSetOrder := self
>>> _doListInstancesFrom: inputSet
>>> with: scanBlk
>>> includeMemory: directoryString == nil.
>>> directoryString
>>> ifNotNil: [ result := resultInSetOrder "primitive wrote the
>>> files, so we are done" ]
>>> ifNil: [
>>> | inputArraySize |
>>> inputArraySize := anArray size.
>>> result := Array new: inputArraySize * 2.
>>> 1 to: inputArraySize do: [ :j |
>>> | soIdx resIdx anObj |
>>> anObj := anArray at: j.
>>> soIdx := (inputSet _offsetOf: anObj) * 2.
>>> resIdx := j * 2.
>>> result at: resIdx - 1 put: (resultInSetOrder at: soIdx - 1).
>>> "totalCount"
>>> result at: resIdx put: (resultInSetOrder at: soIdx) "array of
>>> instances" ] ].
>>> ^ result
>>>
>>>
>>> On 8/28/15 3:04 PM, Dale Henrichs wrote:
>>>
>>> Mariano,
>>>
>>> Does the following return nil consistently when run in your image:
>>>
>>> System abortTransaction.
>>> SystemRepository
>>> listInstances: {FaSecurityAdjustedClosingPriceRecord}
>>> limit: 0
>>> toDirectory: nil
>>> withMaxThreads: 1
>>> maxCpuUsage: 95
>>> memoryOnly: false
>>>
>>> I think this is the equivalent call that is causing a nil return value.
>>> I've looked at the code and there is no obvious code path for returning
>>> nill instead of an Array .... I've submitted an internal bug.
>>>
>>> Dale
>>>
>>> On 8/28/15 1:20 PM, Dale Henrichs wrote:
>>>
>>> Nonetheless, this looks like a bug in GemStone and now I need to
>>> understand why so I can provide a test case to the server guys ... I don't
>>> think that 2 metaclasses and 2 classes is a good reason for nil, since
>>> GemStone is supposed to survive this kind of situation ... likely it is
>>> something else ... this is a multi-thread operation and it is possible that
>>> something related to that is the root cause could you check in the stone
>>> log and the gem log to see if any error information is written there ...
>>>
>>> Thanks for pushing on this like you did ... I was an email behind and
>>> you were way ahead of me ... but ... I have an "expectation" that certain
>>> class loading scenarios could result in an error, but this kind of error is
>>> not part of my expectation and the monticello loading scheme does hide
>>> these kinds of problems ....
>>>
>>> Need to make the error more visible at the very least ... and fix the
>>> GemStone bug ... it's possible that the bug is already fixed and it is not
>>> likely that we will ship a 3.1.0.7 with a bugfix -
>>>
>>> Let's get a simplified test case and move forward from there ...
>>>
>>> Is it possible that you're in a limited memory situation in your
>>> development environment?
>>>
>>> Dale
>>>
>>> On 8/28/15 1:04 PM, Mariano Martinez Peck wrote:
>>>
>>>
>>>
>>> On Fri, Aug 28, 2015 at 5:00 PM, Mariano Martinez Peck <
>>> <marianopeck at gmail.com>marianopeck at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Aug 28, 2015 at 4:56 PM, Dale Henrichs via Glass <
>>>> <glass at lists.gemtalksystems.com>glass at lists.gemtalksystems.com> wrote:
>>>>
>>>>> Definitely a GemStone bug, since
>>>>> Repository>>_scanPomWithMaxThreads:waitForLock:pageBufSize:percentCpuActiveLimit:identSet:limit:scanKind:toDirectory:
>>>>> is a primitive call and is not documented to return nil ... unless I
>>>>> misread the stack and calls?
>>>>>
>>>>>
>>>> No, I got exactly until that point too. I read the comment of the
>>>> method, it said anywhere why it would answer nil, so I kind of give up.
>>>>
>>>>
>>> BTW..I will try to see if I can get there again. But I suspect this is
>>> related to the fact that I end up having 2 metaclasses and 2 classes (as I
>>> show some emails up) for the same "class" after loading.
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>> Dale
>>>>>
>>>>>
>>>>> On 8/28/15 12:50 PM, Dale Henrichs wrote:
>>>>>
>>>>>> This looks like a GemStone bug (at first blush), since the error is
>>>>>> originating in
>>>>>>
>>>>>> [13] Repository >> _doListInstancesFrom:with:includeMemory: (envId 0)
>>>>>>
>>>>>> so if you could extract some detail from that frame about where the
>>>>>> source of the nil, we might be able to work our way back to the root cause
>>>>>> ...
>>>>>>
>>>>>> Dale
>>>>>>
>>>>>> On 8/28/15 7:58 AM, Mariano Martinez Peck via Glass wrote:
>>>>>>
>>>>>>> [13] Repository >> _doListInstancesFrom:with:includeMemory: (envId 0)
>>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Glass mailing list
>>>>> <Glass at lists.gemtalksystems.com>Glass at lists.gemtalksystems.com
>>>>> <http://lists.gemtalksystems.com/mailman/listinfo/glass>
>>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mariano
>>>> <http://marianopeck.wordpress.com>http://marianopeck.wordpress.com
>>>>
>>>
>>>
>>>
>>> --
>>> Mariano
>>> <http://marianopeck.wordpress.com>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/20150901/a2727e1d/attachment-0001.html>
More information about the Glass
mailing list