[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 1 10:14:29 PDT 2015
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 ...
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
> <mailto: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
>> <mailto: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
>>> <http://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 <mailto:marianopeck at gmail.com>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 28, 2015 at 4:56 PM, Dale Henrichs via
>>>>>> Glass <glass at lists.gemtalksystems.com
>>>>>> <mailto: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
>>>>>> <mailto:Glass at lists.gemtalksystems.com>
>>>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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/20150901/ad5e176a/attachment-0001.html>
More information about the Glass
mailing list