[Glass] Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Wed Oct 28 18:47:20 PDT 2015
OK Dale, I think I found out what is going on.
Please, read carefully steps 1 to 3 from my original email. With that in
mind, the problem is this. I run this code:
| collectionsWithBadIndexes |
"Run a query so that to be sure we use indexes"
Object new assert: ((UserGlobals at: #IndexesBugReport) select: { :each |
each.testSelector = 'aString' }) size = 1.
"Check health of indexes"
[[
IndexManager current removeAllIncompleteIndexes.
collectionsWithBadIndexes := IndexManager current nscsWithBadIndexes.
Transcript show: 'There are ' , collectionsWithBadIndexes size asString, '
collections with bad indexes.'; cr.
Transcript show: 'The following are the OOPs of such collections: '.
collectionsWithBadIndexes do: [ :each | Transcript show: ' - ' , each asOop
asString. ].
Transcript cr.
] on: Error do: [ :err | Transcript show: ' Original error: ' , err
description; cr. ]
] ensure: [ System commit ]
It seems that #nscsWithBadIndexes let things in a very bad state. The
original error is the
*" Original error: a InternalError occurred (error 2261), The object with
object ID 20 is corrupt. Reason: 'relops: encrypt (no Unicode collator) --
Unicode strings encountered'*
*AUTOCOMMIT DISABLED"*
And the one trying to do the last commit is the
*"'a TransactionError occurred (error 2249), Further commits have been
disabled for this session because: ''CorruptObj error''. "*
So..why did I get in seaside request? I think because #
seasideProcessRequestWithRetry:resultBlock: tries again and so, the
problem.
Why do I got with loading Seaside from metacello? again, because it tries
3 times (when it fails, it tries again).
So it seems that the error "'a TransactionError occurred (error 2249),
Further commits have been disabled for this session because: ''CorruptObj
error''. This session m..." comes when you try to commit again after
getting the error " 'a InternalError occurred (error 2261), The object with
object ID 20 is corrupt. Reason: ''relops: encrypt (no Unicode collator) --
Unicode ..."
Maybe this is related to the "Autocommit disabled" ?
As for Seaside I imagine I only got the last error and not the original,
and that's why I couldn't see the original stack.
Does any of this make sense?
On Wed, Oct 28, 2015 at 10:36 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:
> Dale, it is being fairly easy for me to reproduce. You must perform steps
> 1 to 3 from my original email. Then, for example I executed this code:
>
> "Run a query so that to be sure we use indexes"
> Object new assert: ((UserGlobals at: #IndexesBugReport) select: { :each |
> each.testSelector = 'aString' }) size = 1.
>
> And then this one:
>
> "Check health of indexes"
> | collectionsWithBadIndexes |
> IndexManager current removeAllIncompleteIndexes.
> collectionsWithBadIndexes := IndexManager current nscsWithBadIndexes.
> Transcript show: 'There are ' , collectionsWithBadIndexes size asString, '
> collections with bad indexes.'; cr.
> Transcript show: 'The following are the OOPs of such collections: '.
> collectionsWithBadIndexes do: [ :each | Transcript show: ' - ' , each
> asOop asString. ].
> Transcript cr.
>
> That yielded the below error:
>
> Inspect InternalError(AbstractException)>>_signalFromPrimitive: @5 line
> 15a InternalError occurred (error 2261), The object with object ID 20 is
> corrupt. Reason: 'relops: encrypt (no Unicode collator) -- Unicode strings
> encountered'/
> --------------------
> . -> a InternalError occurred (error 2261), The object with
> object ID 20 is corrupt. Reason: 'relops: encrypt (no Unicode collator) --
> Unicode st...
> .. -> a InternalError occurred (error 2261), The object with
> object ID 20 is corrupt. Reason: 'relops: encrypt (no Unicode collator) --
> Unicode st...
> (class)@ -> InternalError
> (oop)@ -> 325122049
> currGsHandler@ -> nil
> gsArgs@ -> anArray( 20, 'relops: encrypt (no Unicode collator) --
> Unicode strings encountered')
> gsDetails@ -> nil
> gsNumber@ -> 2261
> gsReason@ -> nil
> gsResumable@ -> false
> gsStack@ -> nil
> gsTrappable@ -> true
> messageText@ -> 'a InternalError occurred (error 2261), The object with
> object ID 20 is corrupt. Reason: ''relops: encrypt (no Unicode collator) --
> Unicode ...
> tag@ -> nil
>
>
> The stack associated to that error was:
>
> aTDDebugger
> --------------------
> 1. InternalError(AbstractException)>>_signalFromPrimitive: @5 line 15
> 2. BtreeBasicLeafNode>>_encryptionFor: @1 line 1
> 3. BtreeBasicLeafNode(BtreeLeafNode)>>_auditLeafKeysValuesAndEncryptedDo:
> @20 line 12
> 4. BtreeBasicLeafNode(BtreeNode)>>auditNsc:for:offset:on: @19 line 15
> 5. PathTerm>>auditNsc:on:level: @17 line 19
> 6. [] in RcIdentityBag(UnorderedCollection)>>_fastAuditEqualityIndexes @22
> line 25
> 7. RcIdentityBag(ExecBlock)>>ensure: @2 line 12
> 8. RcIdentityBag(UnorderedCollection)>>_fastAuditEqualityIndexes @8 line 52
> 9. RcIdentityBag(UnorderedCollection)>>_fastAuditIndexes @16 line 28
> 10. RcIdentityBag(UnorderedCollection)>>auditIndexes @2 line 15
> 11. [] in ExecBlock1(IndexManager)>>nscsWithBadIndexes @2 line 7
> 12. IdentitySet(UnorderedCollection)>>_reject: @13 line 8
> 13. IdentitySet(UnorderedCollection)>>reject: @10 line 19
> 14. IndexManager>>nscsWithBadIndexes @3 line 5
> 15. Executed Code
> 16. String(CharacterCollection)>>evaluateIn:symbolList:literalVars: @4
> line 13
> 17.
> TDWorkspaceClientElementBuilder(TDClientSourceElementBuilder)>>evaluateString:
> @5 line 3
> 18.
> TDWorkspaceClientElementBuilder(TDClientSourceElementBuilder)>>doItMenuAction:selectedText:
> @2 line 2
> 19.
> TDWorkspaceClientElementBuilder(TDWindowBuilder)>>handleMenuActions:listElement:actionArg:
> @12 line 10
> 20. [] in
> TDWorkspaceClientElementBuilder(TDClientSourceElementBuilder)>>menuActionBlock
> @6 line 8
> 21.
> TDWorkspaceClientElementBuilder(ExecBlock)>>value:value:value:value:value:
> @2 line 11
> 22. GsNMethod class>>_gsReturnToC @1 line 1
>
>
> Then I tried to click on the "debug" button from the debugger pre-windows
> opened by tODE and that yielded yet another problem:
>
>
> Inspect TransactionError(AbstractException)>>_signalFromPrimitive: @5 line
> 15a TransactionError occurred (error 2249), Further commits have been
> disabled for this session because: 'CorruptObj error'. This session must
> logout./
> --------------------
> . -> a TransactionError occurred (error 2249), Further
> commits have been disabled for this session because: 'CorruptObj error'.
> This session must...
> .. -> a TransactionError occurred (error 2249), Further
> commits have been disabled for this session because: 'CorruptObj error'.
> This session must...
> (class)@ -> TransactionError
> (oop)@ -> 322639105
> currGsHandler@ -> nil
> gsArgs@ -> anArray( 'CorruptObj error')
> gsDetails@ -> nil
> gsNumber@ -> 2249
> gsReason@ -> nil
> gsResumable@ -> true
> gsStack@ -> nil
> gsTrappable@ -> true
> messageText@ -> 'a TransactionError occurred (error 2249), Further
> commits have been disabled for this session because: ''CorruptObj error''.
> This session m...
> tag@ -> nil
> 1@ -> aGsNMethod
> 2@ -> aGsNMethod
> 3@ -> 0
> 4@ -> -111
> 5@ -> -89
>
>
> And this was the stack:
>
>
> aTDDebugger
> --------------------
> 1. TransactionError(AbstractException)>>_signalFromPrimitive: @5 line 15
> 2. System class>>_primitiveCommit: @1 line 1
> 3. System class>>__commit: @2 line 8
> 4. [] in System class>>_localCommit: @2 line 30
> 5. System class(ExecBlock)>>onException:do: @2 line 66
> 6. System class>>_localCommit: @8 line 31
> 7.
> SessionMethodTransactionBoundaryPolicy(TransactionBoundaryDefaultPolicy)>>commit:
> @2 line 3
> 8. System class>>_commit: @7 line 16
> 9. System class>>commitTransaction @5 line 7
> 10. [] in TDTopezServer>>commitTransaction @2 line 5
> 11. TDTopezServer(ExecBlock)>>on:do: @3 line 42
> 12. TDTopezServer>>commitTransaction @6 line 13
> 13. [] in TDDebugger(TDAbstractToolBuilder)>>menuActionBlock @5 line 9
> 14. TDMiniToolSpec>>menuAction:actionSymbol:listElement:selectedIndex: @4
> line 4
> 15. [] in TDMiniToolClientListElementBuilder>>menuActionBlock @3 line 7
> 16. TDMiniToolClientListElementBuilder(ExecBlock)>>value:value:value: @2
> line 11
> 17. GsNMethod class>>_gsReturnToC @1 line 1
>
>
>
>
>
> On Wed, Oct 28, 2015 at 10:21 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>>
>> On Wed, Oct 28, 2015 at 4:50 PM, Dale Henrichs <
>> dale.henrichs at gemtalksystems.com> wrote:
>>
>>> Next time you get a corrupt error, please record the stack ... if we are
>>> getting random failures each stack will hep us piece together what might be
>>> happening ...
>>>
>>>
>> Sure, but by "record the stack" you mean the dead simple plain based
>> stack I can print from tODE right? Because since my session is kicked out
>> and not allowed any further commit I cannot even store the stack in the
>> object log or anything, right?
>> So I think that for one day we will do as the old fashion of debugging a
>> dead plain string stack hahahahah
>>
>>
>>> It's especially odd that you would get a problem during an install ...
>>> Seaside or not ... I've never seen anything like that happen before ...
>>> I've installed Seaside a ton of times and at this point I'm not sure that
>>> the upgrade would even be necessary as it sounds like there might be
>>> something else going on ..
>>>
>>> I'm going to wait and see some stacks from you and see if you can get a
>>> more reproducable test case before going fishing ... there are you getting
>>> disk errors? Are you running on a mac or linux?
>>>
>>>
>> The original error happened in Linux. But today I was able to reproduce
>> it (only once and I didn't save the stack as I thought I would be able to
>> reproduce it again grrr) in OSX.
>> It seems to me it's related to in the moment were we are trying to commit
>> something.
>>
>> I will see if I can reproduce it again.
>>
>>
>>> Dale
>>>
>>>
>>> On 10/28/2015 12:32 PM, Mariano Martinez Peck wrote:
>>>
>>> hahahahah funny. I was try to install Seaside in order to try the select
>>> from a Seaside callback and I even get the corrupt error while trying to
>>> install Seaside itself hahahha.
>>>
>>> 1) $GS_HOME/bin/createStone -f gs_3106 3.1.0.6
>>>
>>> 2) Via tODE in gs_3106 execute:
>>>
>>> | collection |
>>> collection := RcIdentityBag new.
>>> collection createEqualityIndexOn: 'testSelector' withLastElementClass:
>>> String.
>>> collection add: (TestCase new setTestSelector: 'aString').
>>> collection add: (TestCase new setTestSelector: 'aUnicode7' _asUnicode7).
>>> UserGlobals at: #IndexesBugReport put: collection.
>>> Object new assert: (collection select: { :each | each.testSelector =
>>> 'aString' }) size = 1.
>>> System commitTransaction.
>>>
>>> 3) $GS_HOME/sys/local/bin/upgradeStone -f gs_3106 gs_329 3.2.9
>>>
>>> 4) Try installing seaside...this MAY reproduce the Corrup error. It
>>> seems it's related to the time of the commit. So I THINK that maybe
>>> depending on #deploy: and depending on the RAM for gem temp space, it may
>>> reproduce it or not. If you reproduce it, do not loose it, since you may
>>> not be able to easily reproduce it again.
>>>
>>> GsDeployer deploy: [
>>> Metacello new
>>> baseline: 'Seaside3';
>>> repository: 'github://GsDevKit/Seaside31:v3.1.4.2-gs/repository';
>>> onLock: [:ex | ex honor];
>>> load: #('Development' 'Examples' 'Zinc') ].
>>>
>>> 5) if 4) did not reproduce it, try:
>>>
>>> WAComponent subclass: 'IndexesBugReportComponent' instVarNames: #( )
>>> classVars: #() classInstVars: #() poolDictionaries: #() inDictionary: ''
>>> category: 'Seaside-Component' options: #() IndexesBugReportComponent >>
>>> renderContentOn: html html anchor callback: [ (UserGlobals at:
>>> #'IndexesBugReport') select: { :each | each.testSelector = 'aString' } ];
>>> with: 'Reproduce bug' WAAdmin register: IndexesBugReportComponent
>>> asApplicationAt: 'indexesbug'. ZnSeasideGemServer register:
>>> 'ZincSeasideGems' on: #( 8383 ). (GemServerRegistry gemServerNamed:
>>> 'ZincSeasideGems') startGems.
>>>
>>> Go to localhost:8383/indexesbug and click the link .
>>> Let me know if you were lucky to reproduce it.
>>>
>>> On Wed, Oct 28, 2015 at 4:14 PM, Mariano Martinez Peck <
>>> <marianopeck at gmail.com>marianopeck at gmail.com> wrote:
>>>
>>>> Of course, I should have tried the query from a Seaside callback...
>>>> seems the #seasideProcessRequestWithRetry:resultBlock: may be related...
>>>>
>>>> Will try later...
>>>>
>>>> Cheers,
>>>>
>>>> On Wed, Oct 28, 2015 at 3:50 PM, Mariano Martinez Peck <
>>>> <marianopeck at gmail.com>marianopeck at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck <
>>>>> marianopeck at gmail.com> wrote:
>>>>>
>>>>>> ufff I could not reproduce it as a test case. However, I paste it
>>>>>> here in case you see something obvious I did wrong:
>>>>>>
>>>>>> 1) $GS_HOME/bin/createStone -f gs_3106 3.1.0.6
>>>>>>
>>>>>> 2) Via tODE in gs_3106 execute:
>>>>>>
>>>>>> | collection |
>>>>>> collection := RcIdentityBag new.
>>>>>> collection createEqualityIndexOn: 'testSelector'
>>>>>> withLastElementClass: String.
>>>>>> collection add: (TestCase new setTestSelector: 'aString').
>>>>>> collection add: (TestCase new setTestSelector: 'aUnicode7'
>>>>>> _asUnicode7).
>>>>>> UserGlobals at: #IndexesBugReport put: collection.
>>>>>> Object new assert: (collection select: { :each | each.testSelector =
>>>>>> 'aString' }) size = 1.
>>>>>> System commitTransaction.
>>>>>>
>>>>>> 3) $GS_HOME/sys/local/bin/upgradeStone -f gs_3106 gs_329 3.2.9
>>>>>>
>>>>>> 4) Via tODE in gs_329 execute:
>>>>>>
>>>>>> Object new assert: ((UserGlobals at: #IndexesBugReport) select: {
>>>>>> :each | each.testSelector = 'aString' }) size = 1.
>>>>>>
>>>>>> But it did work... so something else may be going on.
>>>>>> ufff...
>>>>>>
>>>>>
>>>>> 5) At least with this code I can reproduce the error I got once
>>>>> checking the status of the index:
>>>>>
>>>>> | collectionsWithBadIndexes |
>>>>> IndexManager current removeAllIncompleteIndexes.
>>>>> collectionsWithBadIndexes := IndexManager current nscsWithBadIndexes.
>>>>> Transcript show: 'There are ' , collectionsWithBadIndexes size
>>>>> asString, ' collections with bad indexes.'; cr.
>>>>> Transcript show: 'The following are the OOPs of such collections: '.
>>>>> collectionsWithBadIndexes do: [ :each | Transcript show: ' - ' , each
>>>>> asOop asString. ].
>>>>> Transcript cr.
>>>>>
>>>>>
>>>>> What I cannot reproduce is the corrupt obj error from seaside...
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 28, 2015 at 3:03 PM, Mariano Martinez Peck via Glass <
>>>>>> <glass at lists.gemtalksystems.com>glass at lists.gemtalksystems.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <
>>>>>>> <dale.henrichs at gemtalksystems.com>dale.henrichs at gemtalksystems.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <
>>>>>>>> <dale.henrichs at gemtalksystems.com>dale.henrichs at gemtalksystems.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I guess the exact unicode error message would be a starting point
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Hi Dale,
>>>>>>>>
>>>>>>>> Ok, I opened a new thread, as you asked.
>>>>>>>> OK I will try to recover it (I must recover from backup so give me
>>>>>>>> a few).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> This whole thread started because we had a bug that would throw a
>>>>>>>>> corruptObj message when invalid unicode was fed to a unicode primitive ...
>>>>>>>>> that bug was fixed in 3.2.2 or so ...
>>>>>>>>>
>>>>>>>>> So this corruptObj message is occuring for a different reason
>>>>>>>>> altogether ...
>>>>>>>>>
>>>>>>>>> In general you should not have to rebuild indexes across upgrade
>>>>>>>>> boundaries (unless we document that you have to) ....
>>>>>>>>>
>>>>>>>>> While it is good to know that a rebuild of indexes fixed you
>>>>>>>>> problem,. I am still interested in understanding what caused the error in
>>>>>>>>> the first place, since it may actually be another bug ...
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Dale, a few things:
>>>>>>>>
>>>>>>>> 1) The original stack / code that triggered the real error was
>>>>>>>> NEVER show anywhere. From the "button" I clicked in my app, which caused
>>>>>>>> the problem, I can tell you 99% that the error ocurred when I performed a
>>>>>>>> query using the special syntax ( { } ) for accessing an index of a
>>>>>>>> collection.
>>>>>>>> The fact of not seeing the REAL stack, WAS a problem.
>>>>>>>>
>>>>>>>> and that is another reason for me to get to the bottom of this ...
>>>>>>>>
>>>>>>>
>>>>>>> Yes, this was a bit of a pain not being able to get the original
>>>>>>> error.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2) From what I understand, I DID have to rebuild my indexes because
>>>>>>>> in the documentation it said that instances of Unicode7 cannot coexist
>>>>>>>> together with isntance of String in the same index. Let's say I have an
>>>>>>>> index on a instVar called 'tickerSymbol' of class XXX. I had a
>>>>>>>> RcIdentitySet with instances of XXX in which some instances have a String
>>>>>>>> instance in 'tickerSymbol' and others had a Unicode7 as instance. (why? no
>>>>>>>> clue...).
>>>>>>>> In the documentation I read this was not possible anymore and if
>>>>>>>> this were the case I would need to create a Unicode-kind of index. And
>>>>>>>> that's what I did and what it worked.
>>>>>>>>
>>>>>>>> okay so that information was true ... and we did document it ... so
>>>>>>>> we are down to trying to understand where the error that is causing the
>>>>>>>> corruptObj error on commit
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Indeed.
>>>>>>>
>>>>>>>
>>>>>>>> I think the bug (if it IS a bug..and if it is reproducible) should
>>>>>>>> be very easy to reproduce with tODE and gsDevKit
>>>>>>>>
>>>>>>>> 1) create 3.1.0.6 stone called gs_3106
>>>>>>>> 2) Create dummy ClassWithIndex with instVar 'instVarWithIndex'.
>>>>>>>> 3) Create a equality index over instVar 'instVarWithIndex' with
>>>>>>>> path element class String (old API since we are in 3.1.0.6)
>>>>>>>> 4) Store in #myUserGlobals a RcIdentityBag with 2 instances of
>>>>>>>> ClassWithIndex, one with a String in 'instVarWithIndex' and one with a
>>>>>>>> Unicode7 instance.
>>>>>>>> 5) Use `upgradeStone` (forcing a target 3.2.9 stone called gs_329)
>>>>>>>> to upgrade from gs_3106 to gs_329
>>>>>>>> 6) Make a #select: { } using 'instVarWithIndex' in the
>>>>>>>> RcIdentityBag stored in the userglobals.
>>>>>>>>
>>>>>>>>
>>>>>>>> This is enough for me to take a crack at reproducing the problem
>>>>>>>> ... these are the details that I needed ... thanks ...
>>>>>>>>
>>>>>>>> I've got a full plate right now, so I will try to get this
>>>>>>>> reproduced and then perhaps defer on characterizing as the fix will likely
>>>>>>>> not be a simple Smalltalk-based solution ... nonetheless I want to get this
>>>>>>>> one under the microscope ... thanks!
>>>>>>>>
>>>>>>>
>>>>>>> ok, no problem. I will see if I can reproduce it too.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mariano
>>>>>>> <http://marianopeck.wordpress.com>http://marianopeck.wordpress.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Glass mailing list
>>>>>>> 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
>>>
>>>
>>>
>>
>>
>> --
>> 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/20151028/6dfde09c/attachment-0001.html>
More information about the Glass
mailing list