[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:36:45 PDT 2015 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151028/bf0a16c6/attachment-0001.html>

More information about the Glass mailing list