[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.
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Wed Oct 28 12:50:22 PDT 2015
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 ...
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?
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 <mailto: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 <mailto:marianopeck at gmail.com>> wrote:
>
>
>
> On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck
> <marianopeck at gmail.com <mailto: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
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>
>
> On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs
> <dale.henrichs at gemtalksystems.com
> <mailto: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
>> <mailto: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
> <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/20151028/613f3a07/attachment-0001.html>
More information about the Glass
mailing list