[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.

Wed Oct 28 12:32:23 PDT 2015

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> 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> 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> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <
>>>> 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> 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
>>>>
>>>> _______________________________________________
>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151028/721e50c6/attachment-0001.html>