Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email]> 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.

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.

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.

I am leaving early today, but I can give it a try to see if I can reproduce it.

Thoughts? 

 
Dale

On 10/28/2015 09:41 AM, Mariano Martinez Peck wrote:
Sure, I can start a new thread. But what else could I provided you in order to get to the bottom of this? 
The only thing I did not mention in my email is the exact unicode error message when checking the health of the indexes. 
What else could help? 

On Wed, Oct 28, 2015 at 1:34 PM, Dale Henrichs <[hidden email]> wrote:
Mariano,

I would like to understand this a bit more - the corruptObj error in this original message should not be the source of the corruptObj in this case, because we believe that we have fixed that bug

I'd like to get to the bottom of this (perhaps a different email thread, since at the moment I don't think they share the same root cause ...

Dale




On 10/28/2015 06:30 AM, Mariano Martinez Peck wrote:
Just for the record in case someone finds a similar problem. I was also getting the error

"a TransactionError occurred (error 2249), Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout."

I got this error in a stone that I just migrated frlom 3.1.0.6 to 3.2.9. 

The stack was not showing the real error, but something like this:

----------- Internal FASTCGI ERROR Encountered: 2015-10-28T09:05:03.8873279094696-04:00
a TransactionError occurred (error 2249), Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.
1 GRGemStonePlatform >> logError:title:shouldCommit: @2 line 4  [GsNMethod 32628056833]
2 GRGemStonePlatform >> logError:title: @2 line 3  [GsNMethod 32628060929]
3 WAFastCGIAdaptor >> internalServerErrorMessage: @20 line 14  [GsNMethod 35365869057]
4 [] in  ExecBlock1 (GRGemStonePlatform) >> seasideProcessRequest:adaptor:resultBlock: @4 line 15  [GsNMethod 34982101505]
5 TransactionError (AbstractException) >> _executeOuterHandler: @3 line 7  [GsNMethod 26844481025]
6 TransactionError (AbstractException) >> _pass:with: @4 line 13  [GsNMethod 26844477953]
7 TransactionError (AbstractException) >> pass @2 line 14  [GsNMethod 26844477185]
8 [] in  ExecBlock1 (System class) >> _localCommit: @2 line 34  [GsNMethod 27208227073]
9 TransactionError (AbstractException) >> _executeHandler: @3 line 8  [GsNMethod 26844481537]
10 TransactionError (AbstractException) >> _signalFromPrimitive: @1 line 1  [GsNMethod 26844471553]
11 System class >> _primitiveCommit: @1 line 1  [GsNMethod 26844868097]
12 System class >> __commit: @2 line 8  [GsNMethod 26844854785]
13 [] in  ExecBlock0 (System class) >> _localCommit: @2 line 30  [GsNMethod 27208227329]
14 ExecBlock0 (ExecBlock) >> onException:do: @2 line 66  [GsNMethod 26843884289]
15 System class >> _localCommit: @8 line 31  [GsNMethod 26844855041]
16 SessionMethodTransactionBoundaryPolicy (TransactionBoundaryDefaultPolicy) >> commit: @2 line 3  [GsNMethod 27996333825]
17 System class >> _commit: @7 line 16  [GsNMethod 26844855297]
18 System class >> commitTransaction @5 line 7  [GsNMethod 26844864257]
19 System class >> _commitPrintingDiagnostics @2 line 8  [GsNMethod 26844773377]
20 SystemCommitTransaction >> defaultAction @2 line 3  [GsNMethod 32628044801]
21 SystemCommitTransaction (AbstractException) >> _signalWith: @5 line 25  [GsNMethod 26844482049]
22 SystemCommitTransaction class (AbstractException class) >> signal @3 line 5  [GsNMethod 26844463873]
23 GRGemStonePlatform >> doCommitTransaction @4 line 3  [GsNMethod 32628057857]
24 [] in  ExecBlock0 (GRGemStonePlatform) >> seasideProcessRequestWithRetry:resultBlock: @24 line 32  [GsNMethod 34982100993]
25 ExecBlock0 (ExecBlock) >> ensure: @2 line 12  [GsNMethod 26843897345]
26 TransientRecursionLock >> critical: @11 line 12  [GsNMethod 34929957889]
27 GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: @3 line 6  [GsNMethod 34965516033]
28 [] in  ExecBlock1 (GRGemStonePlatform) >> seasideProcessRequest:adaptor:resultBlock: @2 line 6  [GsNMethod 34997412097]
29 Array (Collection) >> do: @5 line 10  [GsNMethod 26844013569]
30 [] in  ExecBlock0 (GRGemStonePlatform) >> seasideProcessRequest:adaptor:resultBlock: @3 line 5  [GsNMethod 34982101761]
31 ExecBlock0 (ExecBlock) >> on:do: @3 line 42  [GsNMethod 26843883521]
32 GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: @2 line 12  [GsNMethod 34965516289]
33 WAFastCGIAdaptor >> process: @3 line 4  [GsNMethod 35365868545]
34 [] in  ExecBlock0 (WAFastCGIAdaptor) >> answerResponderRole: @2 line 4  [GsNMethod 35391972609]
35 ExecBlock0 (ExecBlock) >> on:do: @3 line 42  [GsNMethod 26843883521]
36 WAFastCGIAdaptor >> answerResponderRole: @2 line 5  [GsNMethod 35365870337]
37 FSResponderRole >> answer @3 line 4  [GsNMethod 35366788609]
38 FSResponderRole (FSRole) >> handleConnection @3 line 5  [GsNMethod 35366808065]
39 FSConnection >> unsafeServe @5 line 8  [GsNMethod 35366100481]
40 [] in  ExecBlock0 (FSConnection) >> safeServe @2 line 8  [GsNMethod 35409050625]
41 ExecBlock0 (ExecBlock) >> on:do: @3 line 42  [GsNMethod 26843883521]
42 [] in  ExecBlock0 (FSConnection) >> safeServe @2 line 9  [GsNMethod 35403513089]
43 ExecBlock0 (ExecBlock) >> on:do: @3 line 42  [GsNMethod 26843883521]
44 [] in  ExecBlock0 (FSConnection) >> safeServe @2 line 12  [GsNMethod 35392137217]
45 ExecBlock0 (ExecBlock) >> ensure: @2 line 12  [GsNMethod 26843897345]
46 FSConnection >> safeServe @2 line 15  [GsNMethod 35366102529]
47 FSConnection >> serve @2 line 4  [GsNMethod 35366102017]
48 [] in  ExecBlock (FSSocketServer) >> listen: @3 line 15  [GsNMethod 35392254721]
49 GsProcess >> _start @7 line 16  [GsNMethod 26844511489]
50 <Reenter marker>


The corrupt thingy made me think in running an audit in the indexes since I knew they changed in 3.2.9. I executed this code that I normally run to check indexes health:

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

And that indeed triggered an error saying something about Unicode and collector etc. So it was clearly the problem that I had an index mixing plain strings and instances of Unicode* classes. So the fix was to rebuild the indexes (first removing all of them via `IndexManager current removeAllTracking.`) and specifying a Unicode* as the `pathElementClass` or using the new API for creating indexes and using the message for unicode ones.

Best, 






On Tue, May 27, 2014 at 4:54 PM, Dale Henrichs <[hidden email][hidden email]> wrote:
... and it turns that the particular case that was causing the corruptObj error in 3.1.0.5 produces an ArgumentError in 3.2 ... there are some paths in the 3.2 code base that could lead to corruptObj errors and THOSE will be fixed in 3.2.x. If we do a 3.1.0.7 release, the bug will be fixed there. Right now there is no schedule for a 3.1.0.7 release.

Dale


On Tue, May 27, 2014 at 12:38 PM, Dale Henrichs <[hidden email][hidden email]> wrote:
... and opened a GemStone Seaside3.1 issue[1]...



On Tue, May 27, 2014 at 12:18 PM, Dale Henrichs <[hidden email][hidden email]> wrote:
I forgot to mention that internally we are tracking this as bug 44291...

Dale


On Tue, May 27, 2014 at 12:16 PM, Dale Henrichs <[hidden email][hidden email]> wrote:
Okay, I've talked to engineering and they agree that the corruptObj error in this case is too extreme. We are in the final stages of a 3.2.1 release, so it may be too late to include a fix in 3.2.1, but it will most likely be included in a 3.2.2, but we don't have a schedule for that.

Until then I think that the following patch to GRGemStonePlatform>>seasideProcessRequest:adaptor:resultBlock: is the best we can do:


  ----- Method: GRGemStonePlatform>>seasideProcessRequest:adaptor:resultBlock: (in category '*seaside-gemstone-core') -----seasideProcessRequest: aNativeRequest adaptor: adaptor resultBlock: resultBlock
    | result |
    [ 
    | retryCount result count |
    retryCount := self retryCount.
    count := 1.
    retryCount
      timesRepeat: [ 
        (result := self
          seasideProcessRequestWithRetry: aNativeRequest
          resultBlock: resultBlock) ~~ nil
          ifTrue: [ ^ result ].
        System _sessionCacheStatAt: 2 put: (System _sessionCacheStatAt: 2) + 1. "requests retried"
        (Delay forMilliseconds: self retryDelay * count) wait.
        count := count * 10 ]. "exceeded retry limit"
    ^ adaptor
      internalServerErrorMessage:
        'Too many retries: ' , (retryCount + 1) printString ]
      on: Error
      do: [ :ex | 
        self doAbortTransaction.
+       result := adaptor internalServerErrorMessage: ex description.
+       ex gsNumber == 2261
+         ifTrue:
+           [ 
+ "
+           Transcript
+             cr;
+             show:
+                 'Session terminating due to CorruptObj error ... session must logout'.
+           System logout ]
+             ex
+         return: nil "Do an explicit return. Because of the abort above, the default action for an exception (resume) is set. see bug39246." ].
-       result := adaptor internalServerErrorMessage: ex description. "Do an explicit return. Because of the abort above, the default action for an exception (resume) is set. see bug39246."
-       ex return: nil ].
    ^ result

If you use this patch, make sure that you have a system in place for automatically restarting gems that get fatal errors. You should be using monit or daaemontools in production since gems may crash occasionally  and they need to be restarted. Other than the extra time/cpu/disk for restarting a gem, stopping/restarting gems is not a fatal problem as no persistent data is lost or corrupted ... see my post on "GLASS 101: Disposable Gems, Durable Data"[1].

I'm on the fence about including this patch in the standard release of Seaside for GemStone ... on the one hand if you get this particular error (or any other "commit prohibiting error" the gem is effectively out of service and needs to be restarted...

An alternative to logout would be to update a field in SessionTemps that indicates the the gem needs to be restarted ... that session state can be queried by a monit http request (presumably) ...  so at the end of the day we should probably invent some sort of gem termination policy that can be controlled at the application level...

Dale





On Mon, May 26, 2014 at 10:33 AM, Dale Henrichs <[hidden email][hidden email]> wrote:
Johan,

I think that a corruptObj error in this case may be a bit extreme. I have asked engineering if there is a "session safe" method for finding the obviously invalid utf8 ... Today is a holiday, so I may not get a response until tomorrow.

I hope that crashed vms is an acceptable outcome of the security audit? 

The corruptObj error is our response to the error thrown by ICU ... the commit prohibiting error normally is thrown when we think that "memory stomping" has occurred and we want to avoid persisting potentially corrupt objects ...  presumably the security audit folks knew that mishandling this particular ICU error condition could lead to a security breach:)

Dale


On Mon, May 26, 2014 at 9:44 AM, Johan Brichau <[hidden email][hidden email]> wrote:
Hi,

Today, we had a security audit on a Seaside 3.0.10 application running in a GS 3.1.0.5 stone with FastCGI behind nginx.

I have no idea what exactly they did to obtain this, but the system went unresponsive after the following error until I restarted the gems.
- a InternalError occurred (error 2261), The object with object ID 'Hannes_Alfvén' is corrupt. Reason: 'carrysize > 0 at end of utf8 decode'
- a TransactionError occurred (error 2249), Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.
- repeat last one

The stacks from the gem log are attached.

I am trying to trace what happened. Any clues?

Johan

----------- Internal FASTCGI ERROR Encountered: 2014-05-26T13:37:41.31612992286682+02:00
a InternalError occurred (error 2261), The object with object ID 'Hannes_Alfvén' is corrupt. Reason: 'carrysize > 0 at end of utf8 decode'
1 GRGemStonePlatform >> logError:title:shouldCommit: (envId 0) @2 line 4  [GsNMethod 7469480705]
2 GRGemStonePlatform >> logError:title: (envId 0) @2 line 3  [GsNMethod 7469494785]
3 WAFastCGIAdaptor >> internalServerErrorMessage: (envId 0) @20 line 14  [GsNMethod 9828254465]
4 [] in  GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @4 line 26  [GsNMethod 10506396161]
5 AbstractException >> _executeHandler: (envId 0) @3 line 8  [GsNMethod 1394121473]
6 AbstractException >> _signalFromPrimitive: (envId 0) @1 line 1  [GsNMethod 1360964097]
7 String >> decodeFromUTF8 (envId 0) @1 line 1  [GsNMethod 1064104705]
8 UTF8PrimitiveEncoding >> decode: (envId 0) @2 line 4  [GsNMethod 7470277121]
9 GRUtf8GemStoneCodec >> decode: (envId 0) @3 line 3  [GsNMethod 7468617985]
10 [] in  WAUrl >> decodedWith: (envId 0) @3 line 17  [GsNMethod 9230396417]
11 SequenceableCollection >> collect: (envId 0) @9 line 16  [GsNMethod 1064183041]
12 WAUrl >> decodedWith: (envId 0) @22 line 17  [GsNMethod <a href="tel:8789933313" value="+18789933313" target="_blank">8789933313]
13 WAFastCGIRequestConverter >> requestUrlFor: (envId 0) @6 line 4  [GsNMethod 9828231425]
14 WAServerAdaptor >> requestFor: (envId 0) @3 line 6  [GsNMethod 8790261761]
15 WAFastCGIRequestConverter >> requestFor: (envId 0) @12 line 7  [GsNMethod 9828215809]
16 WAFastCGIAdaptor >> requestFor: (envId 0) @2 line 4  [GsNMethod 9828250881]
17 WAServerAdaptor >> contextFor: (envId 0) @2 line 5  [GsNMethod 8790264577]
18 WAServerAdaptor >> process: (envId 0) @2 line 5  [GsNMethod 8790258433]
19 [] in  WAFastCGIAdaptor >> process: (envId 0) @2 line 6  [GsNMethod 8794996737]
20 [] in  GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId 0) @2 line 13  [GsNMethod 10501067521]
21 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 1064627457]
22 [] in  GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId 0) @14 line 14  [GsNMethod 10506395905]
23 ExecBlock >> ensure: (envId 0) @2 line 12  [GsNMethod 1064640769]
24 TransientRecursionLock >> critical: (envId 0) @11 line 12  [GsNMethod 6527748609]
25 GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId 0) @3 line 5  [GsNMethod 10509761025]
26 [] in  GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @6 line 15  [GsNMethod 10506396417]
27 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 1064627457]
28 GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @3 line 23  [GsNMethod 10509761281]
29 WAFastCGIAdaptor >> process: (envId 0) @3 line 4  [GsNMethod 9828418049]
30 [] in  WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 4  [GsNMethod 8795113729]
31 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 1064627457]
32 WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 5  [GsNMethod 9828248321]
33 FSResponderRole >> answer (envId 0) @3 line 4  [GsNMethod 8854227457]
34 FSRole >> handleConnection (envId 0) @3 line 5  [GsNMethod 8854243329]
35 FSConnection >> unsafeServe (envId 0) @5 line 8  [GsNMethod 8853951745]
36 [] in  FSConnection >> safeServe (envId 0) @2 line 8  [GsNMethod 9557561601]
37 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 1064627457]
38 [] in  FSConnection >> safeServe (envId 0) @2 line 9  [GsNMethod 9322044673]
39 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 1064627457]
40 [] in  FSConnection >> safeServe (envId 0) @2 line 12  [GsNMethod <a href="tel:9258731777" value="+19258731777" target="_blank">9258731777]
41 ExecBlock >> ensure: (envId 0) @2 line 12  [GsNMethod 1064640769]
42 FSConnection >> safeServe (envId 0) @2 line 15  [GsNMethod 8853958913]
43 FSConnection >> serve (envId 0) @2 line 4  [GsNMethod 8853957889]
44 [] in  FSSocketServer >> listen: (envId 0) @3 line 15  [GsNMethod 9261209601]
45 GsProcess >> _start (envId 0) @7 line 16  [GsNMethod 1403422977]
46 <Reenter marker>
-----------
----------- Internal FASTCGI LOG ENTRY: anArray-----------
----------- Internal FASTCGI ERROR Encountered: 2014-05-26T13:37:41.37823009490967+02:00
a TransactionError occurred (error 2249), Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.
1 GRGemStonePlatform >> logError:title:shouldCommit: (envId 0) @2 line 4  [GsNMethod 7469480705]
2 GRGemStonePlatform >> logError:title: (envId 0) @2 line 3  [GsNMethod 7469494785]
3 WAFastCGIAdaptor >> internalServerErrorMessage: (envId 0) @20 line 14  [GsNMethod 9828254465]
4 [] in  GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @4 line 26  [GsNMethod 10506396161]
5 AbstractException >> _executeOuterHandler: (envId 0) @3 line 7  [GsNMethod 1394117633]
6 AbstractException >> _pass:with: (envId 0) @4 line 13  [GsNMethod 1393936385]
7 AbstractException >> pass (envId 0) @2 line 14  [GsNMethod 1393935361]
8 [] in  System class >> _localCommit: (envId 0) @2 line 34  [GsNMethod 5944183041]
9 AbstractException >> _executeHandler: (envId 0) @3 line 8  [GsNMethod 1394121473]
10 AbstractException >> _signalFromPrimitive: (envId 0) @1 line 1  [GsNMethod 1360964097]
11 System class >> _primitiveCommit: (envId 0) @1 line 1  [GsNMethod 1789434881]
12 System class >> __commit: (envId 0) @2 line 8  [GsNMethod 1789345025]
13 [] in  System class >> _localCommit: (envId 0) @2 line 30  [GsNMethod 5944183297]
14 ExecBlock >> onException:do: (envId 0) @2 line 66  [GsNMethod 1064628225]
15 System class >> _localCommit: (envId 0) @8 line 31  [GsNMethod 1789345281]
16 TransactionBoundaryDefaultPolicy >> commit: (envId 0) @2 line 3  [GsNMethod 5986577665]
17 System class >> _commit: (envId 0) @7 line 16  [GsNMethod 1789345537]
18 System class >> commitTransaction (envId 0) @5 line 7  [GsNMethod 1789402113]
19 System class >> _commitPrintingDiagnostics (envId 0) @2 line 8  [GsNMethod 1700522241]
20 SystemCommitTransaction >> defaultAction (envId 0) @2 line 3  [GsNMethod 7468825857]
21 AbstractException >> _signalWith: (envId 0) @5 line 25  [GsNMethod 1394122241]
22 AbstractException class >> signal (envId 0) @3 line 5  [GsNMethod 1172775681]
23 GRGemStonePlatform >> doCommitTransaction (envId 0) @4 line 3  [GsNMethod 7469481473]
24 [] in  GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId 0) @47 line 54  [GsNMethod 10506395905]
25 ExecBlock >> ensure: (envId 0) @2 line 12  [GsNMethod 1064640769]
26 TransientRecursionLock >> critical: (envId 0) @11 line 12  [GsNMethod 6527748609]
27 GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId 0) @3 line 5  [GsNMethod 10509761025]
28 [] in  GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @6 line 15  [GsNMethod 10506396417]
29 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 1064627457]
30 GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @3 line 23  [GsNMethod 10509761281]
31 WAFastCGIAdaptor >> process: (envId 0) @3 line 4  [GsNMethod 9828418049]
32 [] in  WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 4  [GsNMethod 8795113729]
33 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 1064627457]
34 WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 5  [GsNMethod 9828248321]
35 FSResponderRole >> answer (envId 0) @3 line 4  [GsNMethod 8854227457]
36 FSRole >> handleConnection (envId 0) @3 line 5  [GsNMethod 8854243329]
37 FSConnection >> unsafeServe (envId 0) @5 line 8  [GsNMethod 8853951745]
38 [] in  FSConnection >> safeServe (envId 0) @2 line 8  [GsNMethod 9557561601]
39 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 1064627457]
40 [] in  FSConnection >> safeServe (envId 0) @2 line 9  [GsNMethod 9322044673]
41 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 1064627457]
42 [] in  FSConnection >> safeServe (envId 0) @2 line 12  [GsNMethod <a href="tel:9258731777" value="+19258731777" target="_blank">9258731777]
43 ExecBlock >> ensure: (envId 0) @2 line 12  [GsNMethod 1064640769]
44 FSConnection >> safeServe (envId 0) @2 line 15  [GsNMethod 8853958913]
45 FSConnection >> serve (envId 0) @2 line 4  [GsNMethod 8853957889]
46 [] in  FSSocketServer >> listen: (envId 0) @3 line 15  [GsNMethod 9261209601]
47 GsProcess >> _start (envId 0) @7 line 16  [GsNMethod 1403422977]
48 <Reenter marker>
-----------
_______________________________________________
Glass mailing list
[hidden email][hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass






_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--




--




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list


On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email]> 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 ...

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

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!

Dale

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list


On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <[hidden email]> wrote:


On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email]> 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.  


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
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...
 

On Wed, Oct 28, 2015 at 3:03 PM, Mariano Martinez Peck via Glass <[hidden email]> wrote:


On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <[hidden email]> wrote:


On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email]> 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.  


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list


On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck <[hidden email]> 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 <[hidden email]> wrote:


On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <[hidden email]> wrote:


On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email]> 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.  


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
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 <[hidden email]> wrote:


On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck <[hidden email]> 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 <[hidden email]> wrote:


On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <[hidden email]> wrote:


On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email]> 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.  


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--



--



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck <[hidden email]> 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 <[hidden email]> wrote:


On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <[hidden email]> wrote:


On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email]> 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.  


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--



--



--



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck <[hidden email]> 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 <[hidden email]> wrote:


On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <[hidden email]> wrote:


On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email]> 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.  


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--



--



--



--


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list


On Wed, Oct 28, 2015 at 4:50 PM, Dale Henrichs <[hidden email]> 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 <[hidden email][hidden email]> 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 <[hidden email][hidden email]> wrote:


On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck <[hidden email]> 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 <[hidden email][hidden email]> wrote:


On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <[hidden email][hidden email]> wrote:


On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email][hidden email]> 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.  


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--



--



--



--




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
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 <[hidden email]> wrote:


On Wed, Oct 28, 2015 at 4:50 PM, Dale Henrichs <[hidden email]> 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 <[hidden email][hidden email]> 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 <[hidden email][hidden email]> wrote:


On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck <[hidden email]> 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 <[hidden email][hidden email]> wrote:


On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <[hidden email][hidden email]> wrote:


On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email][hidden email]> 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.  


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--



--



--



--




--



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, Oct 28, 2015 at 4:50 PM, Dale Henrichs <[hidden email]> 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 <[hidden email][hidden email]> 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 <[hidden email][hidden email]> wrote:


On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck <[hidden email]> 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 <[hidden email][hidden email]> wrote:


On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <[hidden email][hidden email]> wrote:


On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email][hidden email]> 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.  


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--



--



--



--




--



--



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
In reply to this post by GLASS mailing list


On 10/28/2015 06:21 PM, Mariano Martinez Peck wrote:


On Wed, Oct 28, 2015 at 4:50 PM, Dale Henrichs <[hidden email]> 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
For random errors that are not easily reproducible as in this case, we need as much information as possible ... for Seaside servers I try to make sure that every error is logged to gem log, since you cannot be 100% sure that a commit to the object log will succeed ...
 
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. 


This particular corruptObj error is _indeed_ thrown at commit time ... because of the commit prohibiting error that occurred earlier and it this original error that we need to isolate.

Dale

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
In reply to this post by GLASS mailing list
Excellent! I will see if this blows up for me as well ... this looks
like the type of "original" error that I was expecting to see. it is
worth noting that once you get a corruptObj error like this you will get
slightly different error when you attempt to commit ...

I've got some more comments below ...

On 10/28/2015 06:36 PM, Mariano Martinez Peck 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
This error is telling me that inside the C code for indexes we are
encountering a Unicode string in an index that has no collator
associated with (which is true) -- so this a completely valid error ...
however, I'm not sure that we should be signaling a corrupt obj error
here ... we want to make sure that commit prohibiting errors (like
corrupt obj errors) are signalled when there is the possibility that a
commit will INTRODUCE corruption ... from the stack below I can tell
that the operation we are performing is a read operation and not a write
operation (which could introduce corruption into the system) so the
corruptobj error is not called for

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

This error and stack (from the click in the debugger) is being triggered
when the autoCommit in tODE hits a commit error (the commit prohibiting
bug) ... It's worthwhile noting that tODE will continue to function (the
prompt in the console should turn red) but nothing will be save to the
system from this point forward ...

Dale
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
In reply to this post by GLASS mailing list


On 10/28/2015 06:47 PM, Mariano Martinez Peck wrote:
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''. "
Okay I think I discussed these things in my earlier response ...

So..why did I get in seaside request?
Yes! ... this is still a mystery...
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" ?
Yes Seaside will try to commit when encountering an error (to record things in the object log), but commit prohibiting errors don't allow the commit and you get to where the commit fails ...

And yes, Seaside continues to retry on commit failures and if somehow the ensuing requests don't trigger the index error you will be allowed to commit again

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? 


Yes ... and now I need to look into things for indexes to see if I can avoid issuing a corrupt obj error when you are doing read only operations ... I think my original logic, is that obviously the index is corrupt if the collator is missing, but I anticipate that in an upgrade scenario it will be "normal" to have a collator-less index containing Unicode strings ...

So will submit a bug ... I'm not sure that I will be able to safely fix this bug, but the bug report (and bug notes with wrokaround) are worth having ...

Thanks for you effort,

Dale

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
Hi Dale, 

Thanks for all the answers and explanations. Hopefully this was worth. 

If you open an internal bug please simply let me know the internal bug number since I am keeping a list of the issues I found (with their state). 

Cheers, 
 

On Wed, Nov 4, 2015 at 3:16 PM, Dale Henrichs <[hidden email]> wrote:


On 10/28/2015 06:47 PM, Mariano Martinez Peck wrote:
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''. "
Okay I think I discussed these things in my earlier response ...

So..why did I get in seaside request?
Yes! ... this is still a mystery...
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" ?
Yes Seaside will try to commit when encountering an error (to record things in the object log), but commit prohibiting errors don't allow the commit and you get to where the commit fails ...

And yes, Seaside continues to retry on commit failures and if somehow the ensuing requests don't trigger the index error you will be allowed to commit again

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? 


Yes ... and now I need to look into things for indexes to see if I can avoid issuing a corrupt obj error when you are doing read only operations ... I think my original logic, is that obviously the index is corrupt if the collator is missing, but I anticipate that in an upgrade scenario it will be "normal" to have a collator-less index containing Unicode strings ...

So will submit a bug ... I'm not sure that I will be able to safely fix this bug, but the bug report (and bug notes with wrokaround) are worth having ...

Thanks for you effort,

Dale



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list


On 11/04/2015 11:02 AM, Mariano Martinez Peck wrote:
> Hi Dale,
>
> Thanks for all the answers and explanations. Hopefully this was worth.
>
> If you open an internal bug please simply let me know the internal bug
> number since I am keeping a list of the issues I found (with their
> state).
>
bug 45812 covers this report ... as I said before I'm still not sure
that I can get rid of the corrutp obj error, but I am pretty that I can
improve the error message produced by the IndexingErrorPreventingCommit
error (a IndexingErrorPreventingCommit occurred (error 2726), errors
during index maintenance; commit will be disallowed) by including the
root error in the error message ...

This was definitely worth it ...

Dale
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list


On Wed, Nov 4, 2015 at 8:49 PM, Dale Henrichs <[hidden email]> wrote:


On 11/04/2015 11:02 AM, Mariano Martinez Peck wrote:
Hi Dale,

Thanks for all the answers and explanations. Hopefully this was worth.

If you open an internal bug please simply let me know the internal bug number since I am keeping a list of the issues I found (with their state).

bug 45812 covers this report ... as I said before I'm still not sure that I can get rid of the corrutp obj error, but I am pretty that I can improve the error message produced by the IndexingErrorPreventingCommit error (a IndexingErrorPreventingCommit occurred (error 2726), errors during index maintenance; commit will be disallowed) by including the root error in the error message ...


Great. Thanks for letting me know. 
 
This was definitely worth it ...

BTW, sometimes we take things for granted without realizing it...did you see how difficult it was for me to reproduce the problem with gsDevKit_home? With 3 lines of code I was able to get a fresh 3.1.0.6 stone, create indexes,  upgrade it to 3.2.9, and then reproduce the bug.
Honestly, without gsDevKit_home I would have not tried to reproduce this as the effort would have been huge. 

Best,

--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list


On 11/04/2015 04:00 PM, Mariano Martinez Peck wrote:


On Wed, Nov 4, 2015 at 8:49 PM, Dale Henrichs <[hidden email]> wrote:


On 11/04/2015 11:02 AM, Mariano Martinez Peck wrote:
Hi Dale,

Thanks for all the answers and explanations. Hopefully this was worth.

If you open an internal bug please simply let me know the internal bug number since I am keeping a list of the issues I found (with their state).

bug 45812 covers this report ... as I said before I'm still not sure that I can get rid of the corrutp obj error, but I am pretty that I can improve the error message produced by the IndexingErrorPreventingCommit error (a IndexingErrorPreventingCommit occurred (error 2726), errors during index maintenance; commit will be disallowed) by including the root error in the error message ...


Great. Thanks for letting me know. 
 
This was definitely worth it ...

BTW, sometimes we take things for granted without realizing it...did you see how difficult it was for me to reproduce the problem with gsDevKit_home? With 3 lines of code I was able to get a fresh 3.1.0.6 stone, create indexes,  upgrade it to 3.2.9, and then reproduce the bug.
Honestly, without gsDevKit_home I would have not tried to reproduce this as the effort would have been huge. 


Haha, no kidding ... I used the GsDevKit_home bash scripts plus the attached index script to my internal bug report with the following instructions:

1) $GS_HOME/bin/createStone -f gs_3106 3.1.0.6

2)in tODE using the attached tODE script:

   /home/index --clean --create --query --edit
  
3) $GS_HOMEbin/upgradeStone -f gs_3106 gs_329 3.2.9

4) then in tODE using attached tODE script:

   /home/index --boom   # to get the root error
or
   /home/index --update # to get the IndexingErrorPreventingCommit error

(of course you have to move the .ston file to $GS_HOME/sys/local/server/home to see it)

Dale

And right before submitting the bug, I went through the whole sequence just to make sure that it broke the way it was supposed to

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

index.ston (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list


On Wed, Nov 4, 2015 at 9:09 PM, Dale Henrichs <[hidden email]> wrote:


On 11/04/2015 04:00 PM, Mariano Martinez Peck wrote:


On Wed, Nov 4, 2015 at 8:49 PM, Dale Henrichs <[hidden email]> wrote:


On 11/04/2015 11:02 AM, Mariano Martinez Peck wrote:
Hi Dale,

Thanks for all the answers and explanations. Hopefully this was worth.

If you open an internal bug please simply let me know the internal bug number since I am keeping a list of the issues I found (with their state).

bug 45812 covers this report ... as I said before I'm still not sure that I can get rid of the corrutp obj error, but I am pretty that I can improve the error message produced by the IndexingErrorPreventingCommit error (a IndexingErrorPreventingCommit occurred (error 2726), errors during index maintenance; commit will be disallowed) by including the root error in the error message ...


Great. Thanks for letting me know. 
 
This was definitely worth it ...

BTW, sometimes we take things for granted without realizing it...did you see how difficult it was for me to reproduce the problem with gsDevKit_home? With 3 lines of code I was able to get a fresh 3.1.0.6 stone, create indexes,  upgrade it to 3.2.9, and then reproduce the bug.
Honestly, without gsDevKit_home I would have not tried to reproduce this as the effort would have been huge. 


Haha, no kidding ... I used the GsDevKit_home bash scripts plus the attached index script to my internal bug report with the following instructions:

1) $GS_HOME/bin/createStone -f gs_3106 3.1.0.6

2)in tODE using the attached tODE script:

   /home/index --clean --create --query --edit
  
3) $GS_HOMEbin/upgradeStone -f gs_3106 gs_329 3.2.9

4) then in tODE using attached tODE script:

   /home/index --boom   # to get the root error
or
   /home/index --update # to get the IndexingErrorPreventingCommit error

(of course you have to move the .ston file to $GS_HOME/sys/local/server/home to see it)

Dale

And right before submitting the bug, I went through the whole sequence just to make sure that it broke the way it was supposed to


Sweet :)
Next time I will try to write such a script!


--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

GLASS mailing list
Hi Dale,

I am seeing again this problem (issue 45812) when upgrading from 3.2.9 to 3.3.1. It happens when I reload all my app code. On the console, I see:


ERROR 2249 , a TransactionError occurred (error 2249), Further commits have been disabled for this session because: 'CorruptObj, relops: encrypt (no Unicode collator) -- Unicode strings encountered'. This session must logout. (TransactionError)
topaz 1>
topaz 1> commit
ERROR 2249 , a TransactionError occurred (error 2249), Further commits have been disabled for this session because: 'CorruptObj, relops: encrypt (no Unicode collator) -- Unicode strings encountered'. This session must logout. (TransactionError)
topaz 1> logout
--- 11/18/2016 14:53:59.924 EST Logging out


Do you know if 45812 was integrated in 3.3.1 ?






On Wed, Nov 4, 2015 at 10:17 PM, Mariano Martinez Peck <[hidden email]> wrote:


On Wed, Nov 4, 2015 at 9:09 PM, Dale Henrichs <[hidden email]> wrote:


On 11/04/2015 04:00 PM, Mariano Martinez Peck wrote:


On Wed, Nov 4, 2015 at 8:49 PM, Dale Henrichs <[hidden email]> wrote:


On 11/04/2015 11:02 AM, Mariano Martinez Peck wrote:
Hi Dale,

Thanks for all the answers and explanations. Hopefully this was worth.

If you open an internal bug please simply let me know the internal bug number since I am keeping a list of the issues I found (with their state).

bug 45812 covers this report ... as I said before I'm still not sure that I can get rid of the corrutp obj error, but I am pretty that I can improve the error message produced by the IndexingErrorPreventingCommit error (a IndexingErrorPreventingCommit occurred (error 2726), errors during index maintenance; commit will be disallowed) by including the root error in the error message ...


Great. Thanks for letting me know. 
 
This was definitely worth it ...

BTW, sometimes we take things for granted without realizing it...did you see how difficult it was for me to reproduce the problem with gsDevKit_home? With 3 lines of code I was able to get a fresh 3.1.0.6 stone, create indexes,  upgrade it to 3.2.9, and then reproduce the bug.
Honestly, without gsDevKit_home I would have not tried to reproduce this as the effort would have been huge. 


Haha, no kidding ... I used the GsDevKit_home bash scripts plus the attached index script to my internal bug report with the following instructions:

1) $GS_HOME/bin/createStone -f gs_3106 3.1.0.6

2)in tODE using the attached tODE script:

   /home/index --clean --create --query --edit
  
3) $GS_HOMEbin/upgradeStone -f gs_3106 gs_329 3.2.9

4) then in tODE using attached tODE script:

   /home/index --boom   # to get the root error
or
   /home/index --update # to get the IndexingErrorPreventingCommit error

(of course you have to move the .ston file to $GS_HOME/sys/local/server/home to see it)

Dale

And right before submitting the bug, I went through the whole sequence just to make sure that it broke the way it was supposed to


Sweet :)
Next time I will try to write such a script!


--



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
12