[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:21:15 PDT 2015
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151028/c1c84ae3/attachment-0001.html>
More information about the Glass
mailing list