On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <[hidden email]> wrote:
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).
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?
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On 10/28/2015 10:48 AM, Mariano
Martinez Peck wrote:
and that is another reason for me to get to the bottom of this ... 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
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 |
On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <[hidden email]> wrote:
Yes, this was a bit of a pain not being able to get the original error.
Indeed.
ok, no problem. I will see if I can reproduce it too. _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck <[hidden email]> wrote:
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...
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Wed, Oct 28, 2015 at 4:50 PM, Dale Henrichs <[hidden email]> wrote:
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
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.
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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' 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:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On 10/28/2015 06:21 PM, Mariano
Martinez Peck wrote:
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 ...
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 |
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 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 |
In reply to this post by GLASS mailing list
On 10/28/2015 06:47 PM, Mariano
Martinez Peck wrote:
Okay I think I discussed these things in my earlier response ... Yes! ... this is still a mystery... 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
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 |
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:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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 |
On Wed, Nov 4, 2015 at 8:49 PM, Dale Henrichs <[hidden email]> wrote:
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. _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On 11/04/2015 04:00 PM, Mariano
Martinez Peck wrote:
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 |
On Wed, Nov 4, 2015 at 9:09 PM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |