[Glass] Nested transactions and 'CorruptObj error', or: how to abort in GLASS?

[Dale Henrichs]

Pieter,

We'd like to find out more information about the failure that you are
seeing ... specifically we'd like to start by getting a C stack at the
point of the error. If you could add:

  GEM_HALT_ON_ERROR = 2261;

to your system.conf (or gem.conf) and then restart your seaside gems and
keep an eye on your gem log file ...

When you hit the error, you should get a c and smalltalk stacks dumped to
the log file so send us a copy of the log file and go from there ...

Basically, you shouldn't be able to reference a GsMethodLookupCache from
persistent state, so we're interesting in finding out how it's sneaking in
...

Dale


On Wed, Mar 19, 2014 at 5:08 AM, Pieter Nagel <pieter at nagel.co.za> wrote:

> Still no luck with nested transactions on 3.1.0.5:
>
> ---
> [1] AbstractException >> _signalFromPrimitive: (envId 0)
>         handleInCextensionBool: nil
>         num: nil
>         res: nil
>         .t1: nil
>         .t2: a InternalError occurred (error 2261), The object with object
> ID
> aGsMethodLookupCache( 284640->aGsNativeCode) is corrupt. Reason: 'attempt
> to commit a hidden object'
>         receiver: a InternalError occurred (error 2261), The object with
> object
> ID aGsMethodLookupCache( 284640->aGsNativeCode) is corrupt. Reason:
> 'attempt to commit a hidden object'
> [2] System class >> _primitiveCommit: (envId 0)
>         commitMode: 0
>         receiver: System
> [3] System class >> __commit: (envId 0)
>         commitMode: 0
>         receiver: System
> [4] [] in  System class >> _localCommit: (envId 0)
>         actualMode: 0
>         self: System
>         receiver: System
> [5] ExecBlock >> onException:do: (envId 0)
>         anException: Error
>         handlerBlock: anExecBlock1
>         receiver: System
> [6] System class >> _localCommit: (envId 0)
>         commitMode: 0
>         commitResult: nil
>         actualMode: 0
>         self: System
>         .t1: anExecBlock0
>         .t2: Error
>         .t3: anExecBlock1
>         receiver: System
> [7] TransactionBoundaryDefaultPolicy >> commit: (envId 0)
>         commitMode: 0
>         res: nil
>         .t1: System
>         .t2: 0
>         receiver: aSessionMethodTransactionBoundaryPolicy
> [8] System class >> _commit: (envId 0)
>         commitMode: 0
>         coordinator: aSessionMethodTransactionBoundaryPolicy
>         .t1: aSessionMethodTransactionBoundaryPolicy
>         .t2: 0
>         receiver: System
> [9] System class >> commitTransaction (envId 0)
>         receiver: System
> [10] OBGemStonePlatform class >> doAutoCommit (envId 0)
>         result: nil
>         .t1: System
>         receiver: OBGemStonePlatform
> [11] JadeServer >> evaluate:inContext: (envId 0)
>         aString: 'WonkaTestRunner runDomainTests.
> '
>         anObject: nil
>         result: true
>         .t1: OBGemStonePlatform
>         receiver: aJadeServer
> [12] JadeServer >> printIt:in: (envId 0)
>         aString: 'WonkaTestRunner runDomainTests.
> '
>         aContext: nil
>         receiver: aJadeServer
> [13] GsNMethod class >> _gsReturnToC (envId 0)
>         receiver: nil
> ---
>
> This happens as part of the auto-commit that happens right at the end of
> "print it"'ing the code that runs our entire unit test, so it is hard to
> point a finger at which one of the many tests called caused the initial
> corruption (except to say this does not happen when not using nested
> transaction).
>
> I've seen the above error many times under 3.1.0.4 as well.
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140319/426a55f3/attachment.html>