Smalltalk › Gemtalk › GLASS

CorruptObj error

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 10 messages Options
keropotter
Reply | Threaded
Open this post in threaded view
♦
♦
|

CorruptObj error

keropotter
Hi, everyone!

We're running a system on GLASS (Gemstone 3.0.1, Seaside 3.0) and we're receiving multiple complains about this error:

Internal Server Error:
a TransactionError occurred (error 2249), Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.
You should contact the system administrator

While going through the ObjectLog, i deleted a few entries and sorted them by time and I got the error myself twice within seconds.

Has anybody experienced this issue? What could be causing it? And more importantly, is there a good way to prevent this from happening?

Many thanks in advance!!
Alejandro
keropotter
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: CorruptObj error

keropotter
I could get the stack trace form the production environment, and here it is, in case it's useful for you. If you need any other information, please let me know!

Cheers!
Alejandro


----------- Internal FASTCGI LOG ENTRY: anArray-----------
----------- Internal FASTCGI ERROR Encountered: 2012-11-30T18:01:55.38709092140198-03: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 49096449]
2 GRGemStonePlatform >> logError:title: (envId 0) @2 line 3 [GsNMethod 49101825]
3 WAFastCGIAdaptor >> internalServerErrorMessage: (envId 0) @20 line 14 [GsNMethod 117320193]
4 [] in GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @4 line 20 [GsNMethod 116031233]
5 AbstractException >> _executeOuterHandler: (envId 0) @3 line 7 [GsNMethod 2347009]
6 AbstractException >> _pass:with: (envId 0) @4 line 13 [GsNMethod 4475393]
7 AbstractException >> pass (envId 0) @2 line 14 [GsNMethod 4485121]
8 [] in System class >> _localCommit: (envId 0) @2 line 34 [GsNMethod 4685825]
9 AbstractException >> _executeHandler: (envId 0) @3 line 8 [GsNMethod 2346241]
10 AbstractException >> _signalFromPrimitive: (envId 0) @1 line 1 [GsNMethod 2340353]
11 System class >> _primitiveCommit: (envId 0) @1 line 1 [GsNMethod 4738049]
12 System class >> __commit: (envId 0) @2 line 8 [GsNMethod 4684289]
13 [] in System class >> _localCommit: (envId 0) @2 line 30 [GsNMethod 4686337]
14 ExecBlock >> onException:do: (envId 0) @2 line 66 [GsNMethod 4320513]
15 System class >> _localCommit: (envId 0) @8 line 31 [GsNMethod 4686593]
16 TransactionBoundaryDefaultPolicy >> commit: (envId 0) @2 line 3 [GsNMethod 10937601]
17 System class >> _commit: (envId 0) @7 line 16 [GsNMethod 4687873]
18 System class >> commitTransaction (envId 0) @2 line 28 [GsNMethod 4718337]
19 System class >> _commitPrintingDiagnostics (envId 0) @2 line 8 [GsNMethod 4659713]
20 SystemCommitTransaction >> defaultAction (envId 0) @2 line 3 [GsNMethod 51072513]
21 AbstractException >> _signalWith: (envId 0) @5 line 25 [GsNMethod 2339073]
22 AbstractException class >> signal (envId 0) @3 line 5 [GsNMethod 2330881]
23 GRGemStonePlatform >> doCommitTransaction (envId 0) @4 line 3 [GsNMethod 49100289]
24 [] in GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId 0) @21 line 32 [GsNMethod 116030721]
25 ExecBlock >> ensure: (envId 0) @2 line 12 [GsNMethod 4293121]
26 TransientRecursionLock >> critical: (envId 0) @11 line 12 [GsNMethod 31094017]
27 GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId 0) @3 line 5 [GsNMethod 111355905]
28 [] in GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @6 line 9 [GsNMethod 116031489]
29 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
30 GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @2 line 17 [GsNMethod 111357185]
31 WAFastCGIAdaptor >> process: (envId 0) @3 line 4 [GsNMethod 117315841]
32 [] in WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 4 [GsNMethod 144833793]
33 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
34 WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 5 [GsNMethod 117315585]
35 FSResponderRole >> answer (envId 0) @3 line 4 [GsNMethod 121678337]
36 FSRole >> handleConnection (envId 0) @3 line 5 [GsNMethod 117278721]
37 FSConnection >> unsafeServe (envId 0) @5 line 8 [GsNMethod 121662721]
38 [] in FSConnection >> safeServe (envId 0) @2 line 8 [GsNMethod 158193409]
39 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
40 [] in FSConnection >> safeServe (envId 0) @2 line 9 [GsNMethod 157013249]
41 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
42 [] in FSConnection >> safeServe (envId 0) @2 line 12 [GsNMethod 149979393]
43 ExecBlock >> ensure: (envId 0) @2 line 12 [GsNMethod 4293121]
44 FSConnection >> safeServe (envId 0) @2 line 15 [GsNMethod 121662977]
45 FSConnection >> serve (envId 0) @2 line 4 [GsNMethod 121660929]
46 [] in FSSocketServer >> listen: (envId 0) @3 line 15 [GsNMethod 144808705]
47 GsProcess >> _start (envId 0) @7 line 15 [GsNMethod 3163137]
48 <Reenter marker> -----------
Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: CorruptObj error

Dale Henrichs
Alejandro,

This seems vaguely familiar to me, but I don't recall details ... I'm checking into this ...

Dale

----- Original Message -----
| From: "keropotter" <[hidden email]>
| To: [hidden email]
| Sent: Friday, November 30, 2012 1:05:45 PM
| Subject: Re: [GS/SS Beta] CorruptObj error
|
| I could get the stack trace form the production environment, and here
| it is,
| in case it's useful for you. If you need any other information,
| please let
| me know!
|
| Cheers!
| Alejandro
|
|
| ----------- Internal FASTCGI LOG ENTRY: anArray-----------
| ----------- Internal FASTCGI ERROR Encountered:
| 2012-11-30T18:01:55.38709092140198-03: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 49096449]
| 2 GRGemStonePlatform >> logError:title: (envId 0) @2 line 3
| [GsNMethod
| 49101825]
| 3 WAFastCGIAdaptor >> internalServerErrorMessage: (envId 0) @20 line
| 14
| [GsNMethod 117320193]
| 4 [] in GRGemStonePlatform >>
| seasideProcessRequest:adaptor:resultBlock:
| (envId 0) @4 line 20 [GsNMethod 116031233]
| 5 AbstractException >> _executeOuterHandler: (envId 0) @3 line 7
| [GsNMethod
| 2347009]
| 6 AbstractException >> _pass:with: (envId 0) @4 line 13 [GsNMethod
| 4475393]
| 7 AbstractException >> pass (envId 0) @2 line 14 [GsNMethod 4485121]
| 8 [] in System class >> _localCommit: (envId 0) @2 line 34 [GsNMethod
| 4685825]
| 9 AbstractException >> _executeHandler: (envId 0) @3 line 8
| [GsNMethod
| 2346241]
| 10 AbstractException >> _signalFromPrimitive: (envId 0) @1 line 1
| [GsNMethod
| 2340353]
| 11 System class >> _primitiveCommit: (envId 0) @1 line 1 [GsNMethod
| 4738049]
| 12 System class >> __commit: (envId 0) @2 line 8 [GsNMethod 4684289]
| 13 [] in System class >> _localCommit: (envId 0) @2 line 30
| [GsNMethod
| 4686337]
| 14 ExecBlock >> onException:do: (envId 0) @2 line 66 [GsNMethod
| 4320513]
| 15 System class >> _localCommit: (envId 0) @8 line 31 [GsNMethod
| 4686593]
| 16 TransactionBoundaryDefaultPolicy >> commit: (envId 0) @2 line 3
| [GsNMethod 10937601]
| 17 System class >> _commit: (envId 0) @7 line 16 [GsNMethod 4687873]
| 18 System class >> commitTransaction (envId 0) @2 line 28 [GsNMethod
| 4718337]
| 19 System class >> _commitPrintingDiagnostics (envId 0) @2 line 8
| [GsNMethod
| 4659713]
| 20 SystemCommitTransaction >> defaultAction (envId 0) @2 line 3
| [GsNMethod
| 51072513]
| 21 AbstractException >> _signalWith: (envId 0) @5 line 25 [GsNMethod
| 2339073]
| 22 AbstractException class >> signal (envId 0) @3 line 5 [GsNMethod
| 2330881]
| 23 GRGemStonePlatform >> doCommitTransaction (envId 0) @4 line 3
| [GsNMethod
| 49100289]
| 24 [] in GRGemStonePlatform >>
| seasideProcessRequestWithRetry:resultBlock:
| (envId 0) @21 line 32 [GsNMethod 116030721]
| 25 ExecBlock >> ensure: (envId 0) @2 line 12 [GsNMethod 4293121]
| 26 TransientRecursionLock >> critical: (envId 0) @11 line 12
| [GsNMethod
| 31094017]
| 27 GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock:
| (envId
| 0) @3 line 5 [GsNMethod 111355905]
| 28 [] in GRGemStonePlatform >>
| seasideProcessRequest:adaptor:resultBlock:
| (envId 0) @6 line 9 [GsNMethod 116031489]
| 29 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
| 30 GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock:
| (envId
| 0) @2 line 17 [GsNMethod 111357185]
| 31 WAFastCGIAdaptor >> process: (envId 0) @3 line 4 [GsNMethod
| 117315841]
| 32 [] in WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 4
| [GsNMethod 144833793]
| 33 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
| 34 WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 5
| [GsNMethod
| 117315585]
| 35 FSResponderRole >> answer (envId 0) @3 line 4 [GsNMethod
| 121678337]
| 36 FSRole >> handleConnection (envId 0) @3 line 5 [GsNMethod
| 117278721]
| 37 FSConnection >> unsafeServe (envId 0) @5 line 8 [GsNMethod
| 121662721]
| 38 [] in FSConnection >> safeServe (envId 0) @2 line 8 [GsNMethod
| 158193409]
| 39 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
| 40 [] in FSConnection >> safeServe (envId 0) @2 line 9 [GsNMethod
| 157013249]
| 41 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
| 42 [] in FSConnection >> safeServe (envId 0) @2 line 12 [GsNMethod
| 149979393]
| 43 ExecBlock >> ensure: (envId 0) @2 line 12 [GsNMethod 4293121]
| 44 FSConnection >> safeServe (envId 0) @2 line 15 [GsNMethod
| 121662977]
| 45 FSConnection >> serve (envId 0) @2 line 4 [GsNMethod 121660929]
| 46 [] in FSSocketServer >> listen: (envId 0) @3 line 15 [GsNMethod
| 144808705]
| 47 GsProcess >> _start (envId 0) @7 line 15 [GsNMethod 3163137]
| 48 <Reenter marker> -----------
|
|
|
| --
| View this message in context:
| http://forum.world.st/CorruptObj-error-tp4657451p4657502.html
| Sent from the GLASS mailing list archive at Nabble.com.
|
Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: CorruptObj error

Dale Henrichs
In reply to this post by keropotter
Alejandro,

Here's a link from an earlier report of this error ... not very useful, but there's a little more info there that might apply ... like "are you using indexes?" and "have you recorded any previous errors in that session?"

Dale

[1] http://forum.world.st/Problem-commiting-transactions-td2260676.html

----- Original Message -----
| From: "keropotter" <[hidden email]>
| To: [hidden email]
| Sent: Friday, November 30, 2012 1:05:45 PM
| Subject: Re: [GS/SS Beta] CorruptObj error
|
| I could get the stack trace form the production environment, and here
| it is,
| in case it's useful for you. If you need any other information,
| please let
| me know!
|
| Cheers!
| Alejandro
|
|
| ----------- Internal FASTCGI LOG ENTRY: anArray-----------
| ----------- Internal FASTCGI ERROR Encountered:
| 2012-11-30T18:01:55.38709092140198-03: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 49096449]
| 2 GRGemStonePlatform >> logError:title: (envId 0) @2 line 3
| [GsNMethod
| 49101825]
| 3 WAFastCGIAdaptor >> internalServerErrorMessage: (envId 0) @20 line
| 14
| [GsNMethod 117320193]
| 4 [] in GRGemStonePlatform >>
| seasideProcessRequest:adaptor:resultBlock:
| (envId 0) @4 line 20 [GsNMethod 116031233]
| 5 AbstractException >> _executeOuterHandler: (envId 0) @3 line 7
| [GsNMethod
| 2347009]
| 6 AbstractException >> _pass:with: (envId 0) @4 line 13 [GsNMethod
| 4475393]
| 7 AbstractException >> pass (envId 0) @2 line 14 [GsNMethod 4485121]
| 8 [] in System class >> _localCommit: (envId 0) @2 line 34 [GsNMethod
| 4685825]
| 9 AbstractException >> _executeHandler: (envId 0) @3 line 8
| [GsNMethod
| 2346241]
| 10 AbstractException >> _signalFromPrimitive: (envId 0) @1 line 1
| [GsNMethod
| 2340353]
| 11 System class >> _primitiveCommit: (envId 0) @1 line 1 [GsNMethod
| 4738049]
| 12 System class >> __commit: (envId 0) @2 line 8 [GsNMethod 4684289]
| 13 [] in System class >> _localCommit: (envId 0) @2 line 30
| [GsNMethod
| 4686337]
| 14 ExecBlock >> onException:do: (envId 0) @2 line 66 [GsNMethod
| 4320513]
| 15 System class >> _localCommit: (envId 0) @8 line 31 [GsNMethod
| 4686593]
| 16 TransactionBoundaryDefaultPolicy >> commit: (envId 0) @2 line 3
| [GsNMethod 10937601]
| 17 System class >> _commit: (envId 0) @7 line 16 [GsNMethod 4687873]
| 18 System class >> commitTransaction (envId 0) @2 line 28 [GsNMethod
| 4718337]
| 19 System class >> _commitPrintingDiagnostics (envId 0) @2 line 8
| [GsNMethod
| 4659713]
| 20 SystemCommitTransaction >> defaultAction (envId 0) @2 line 3
| [GsNMethod
| 51072513]
| 21 AbstractException >> _signalWith: (envId 0) @5 line 25 [GsNMethod
| 2339073]
| 22 AbstractException class >> signal (envId 0) @3 line 5 [GsNMethod
| 2330881]
| 23 GRGemStonePlatform >> doCommitTransaction (envId 0) @4 line 3
| [GsNMethod
| 49100289]
| 24 [] in GRGemStonePlatform >>
| seasideProcessRequestWithRetry:resultBlock:
| (envId 0) @21 line 32 [GsNMethod 116030721]
| 25 ExecBlock >> ensure: (envId 0) @2 line 12 [GsNMethod 4293121]
| 26 TransientRecursionLock >> critical: (envId 0) @11 line 12
| [GsNMethod
| 31094017]
| 27 GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock:
| (envId
| 0) @3 line 5 [GsNMethod 111355905]
| 28 [] in GRGemStonePlatform >>
| seasideProcessRequest:adaptor:resultBlock:
| (envId 0) @6 line 9 [GsNMethod 116031489]
| 29 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
| 30 GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock:
| (envId
| 0) @2 line 17 [GsNMethod 111357185]
| 31 WAFastCGIAdaptor >> process: (envId 0) @3 line 4 [GsNMethod
| 117315841]
| 32 [] in WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 4
| [GsNMethod 144833793]
| 33 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
| 34 WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 5
| [GsNMethod
| 117315585]
| 35 FSResponderRole >> answer (envId 0) @3 line 4 [GsNMethod
| 121678337]
| 36 FSRole >> handleConnection (envId 0) @3 line 5 [GsNMethod
| 117278721]
| 37 FSConnection >> unsafeServe (envId 0) @5 line 8 [GsNMethod
| 121662721]
| 38 [] in FSConnection >> safeServe (envId 0) @2 line 8 [GsNMethod
| 158193409]
| 39 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
| 40 [] in FSConnection >> safeServe (envId 0) @2 line 9 [GsNMethod
| 157013249]
| 41 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 4323073]
| 42 [] in FSConnection >> safeServe (envId 0) @2 line 12 [GsNMethod
| 149979393]
| 43 ExecBlock >> ensure: (envId 0) @2 line 12 [GsNMethod 4293121]
| 44 FSConnection >> safeServe (envId 0) @2 line 15 [GsNMethod
| 121662977]
| 45 FSConnection >> serve (envId 0) @2 line 4 [GsNMethod 121660929]
| 46 [] in FSSocketServer >> listen: (envId 0) @3 line 15 [GsNMethod
| 144808705]
| 47 GsProcess >> _start (envId 0) @7 line 15 [GsNMethod 3163137]
| 48 <Reenter marker> -----------
|
|
|
| --
| View this message in context:
| http://forum.world.st/CorruptObj-error-tp4657451p4657502.html
| Sent from the GLASS mailing list archive at Nabble.com.
|
Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: CorruptObj error

Dale Henrichs
In reply to this post by keropotter
Alejandro,

The Transaction error is occuring because you are getting another error that is not being caught or logged. To force the logging of the "mystery error", put the following chunk of code in the topaz script that launches your fastcgi servers (probably in startSeaside30_Adaptor somewhere before the line that starts `GsFile gciLogServer:`):

    AbstractException
      installDebugBlock: [:ex |
        ex gsNumber = 2261
          ifTrue: [
            GRPlatform current
              logError: ex description
              title: 'ERROR 2261 caught'
              shouldCommit: false].
        ].

This installs a static exception handler that will catch and log error 2261 (the 'CorruptObj error') ... the debugBlock is run BEFORE any other exception handlers are fired off ...

It is this error that we need to understand, since the Transaction error is a side effect ...

Dale

----- Original Message -----
| From: "keropotter" <[hidden email]>
| To: [hidden email]
| Sent: Friday, November 30, 2012 8:07:26 AM
| Subject: [GS/SS Beta] CorruptObj error
|
| Hi, everyone!
|
| We're running a system on GLASS (Gemstone 3.0.1, Seaside 3.0) and
| we're
| receiving multiple complains about this error:
|
| *Internal Server Error:
| a TransactionError occurred (error 2249), Further commits have been
| disabled
| for this session because: 'CorruptObj error'. This session must
| logout.
| You should contact the system administrator*
|
| While going through the ObjectLog, i deleted a few entries and sorted
| them
| by time and I got the error myself twice within seconds.
|
| Has anybody experienced this issue? What could be causing it? And
| more
| importantly, is there a good way to prevent this from happening?
|
| Many thanks in advance!!
| Alejandro
|
|
|
| --
| View this message in context:
| http://forum.world.st/CorruptObj-error-tp4657451.html
| Sent from the GLASS mailing list archive at Nabble.com.
|
keropotter
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: CorruptObj error

keropotter
Hello, Dale!

Thank you very much for your kind help!! As this is a production environment, and making changes to it involves a fair amount of bureaucracy, I will ask for this to be done on Monday and get back to you with the results as soon as I can. I would do it now on our development environment, but i haven't been able to reproduce it. I will try there too anyway!

Thanks again!!
Alejandro


On Fri, Nov 30, 2012 at 9:52 PM, Dale Henrichs [via Smalltalk] <[hidden email]> wrote:
Alejandro,

The Transaction error is occuring because you are getting another error that is not being caught or logged. To force the logging of the "mystery error", put the following chunk of code in the topaz script that launches your fastcgi servers (probably in startSeaside30_Adaptor somewhere before the line that starts `GsFile gciLogServer:`):

    AbstractException
      installDebugBlock: [:ex |
        ex gsNumber = 2261
          ifTrue: [
            GRPlatform current
              logError: ex description
              title: 'ERROR 2261 caught'
              shouldCommit: false].
        ].

This installs a static exception handler that will catch and log error 2261 (the 'CorruptObj error') ... the debugBlock is run BEFORE any other exception handlers are fired off ...

It is this error that we need to understand, since the Transaction error is a side effect ...

Dale

----- Original Message -----
| From: "keropotter" <[hidden email]>
| To: [hidden email]
| Sent: Friday, November 30, 2012 8:07:26 AM
| Subject: [GS/SS Beta] CorruptObj error
|
| Hi, everyone!
|
| We're running a system on GLASS (Gemstone 3.0.1, Seaside 3.0) and
| we're
| receiving multiple complains about this error:
|
| *Internal Server Error:
| a TransactionError occurred (error 2249), Further commits have been
| disabled
| for this session because: 'CorruptObj error'. This session must
| logout.
| You should contact the system administrator*
|
| While going through the ObjectLog, i deleted a few entries and sorted
| them
| by time and I got the error myself twice within seconds.
|
| Has anybody experienced this issue? What could be causing it? And
| more
| importantly, is there a good way to prevent this from happening?
|
| Many thanks in advance!!
| Alejandro
|
|
|
| --
| View this message in context:
| http://forum.world.st/CorruptObj-error-tp4657451.html

| Sent from the GLASS mailing list archive at Nabble.com.
|


If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/CorruptObj-error-tp4657451p4657555.html
To unsubscribe from CorruptObj error, click here.
NAML

Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: CorruptObj error

Dale Henrichs
Alejandro,

The installDebugBlock code is going to intercept every exception before it is handled, so before installing that code into production do some testing to ensure that it won't have an adverse impact on your production environment ...

In fact, let me talk to some of the other engineers here (on Monday) to see if there might be a less intrusive approach for production...

Dale

----- Original Message -----
| From: "keropotter" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, December 1, 2012 6:14:54 AM
| Subject: Re: [GS/SS Beta] CorruptObj error
|
| Hello, Dale!
|
|
| Thank you very much for your kind help!! As this is a production
| environment, and making changes to it involves a fair amount of
| bureaucracy, I will ask for this to be done on Monday and get back
| to you with the results as soon as I can. I would do it now on our
| development environment, but i haven't been able to reproduce it. I
| will try there too anyway!
|
|
| Thanks again!!
| Alejandro
|
|
|
| On Fri, Nov 30, 2012 at 9:52 PM, Dale Henrichs [via Smalltalk] <
| [hidden email] > wrote:
|
|
| Alejandro,
|
| The Transaction error is occuring because you are getting another
| error that is not being caught or logged. To force the logging of
| the "mystery error", put the following chunk of code in the topaz
| script that launches your fastcgi servers (probably in
| startSeaside30_Adaptor somewhere before the line that starts `GsFile
| gciLogServer:`):
|
| AbstractException
| installDebugBlock: [:ex |
| ex gsNumber = 2261
| ifTrue: [
| GRPlatform current
| logError: ex description
| title: 'ERROR 2261 caught'
| shouldCommit: false].
| ].
|
| This installs a static exception handler that will catch and log
| error 2261 (the 'CorruptObj error') ... the debugBlock is run BEFORE
| any other exception handlers are fired off ...
|
| It is this error that we need to understand, since the Transaction
| error is a side effect ...
|
| Dale
|
|
| ----- Original Message -----
| | From: "keropotter" < [hidden email] >
| | To: [hidden email]
| | Sent: Friday, November 30, 2012 8:07:26 AM
| | Subject: [GS/SS Beta] CorruptObj error
| |
| | Hi, everyone!
| |
| | We're running a system on GLASS (Gemstone 3.0.1, Seaside 3.0) and
| | we're
| | receiving multiple complains about this error:
| |
| | *Internal Server Error:
|
| | a TransactionError occurred (error 2249), Further commits have been
| | disabled
| | for this session because: 'CorruptObj error'. This session must
| | logout.
| | You should contact the system administrator*
| |
| | While going through the ObjectLog, i deleted a few entries and
| | sorted
| | them
| | by time and I got the error myself twice within seconds.
| |
| | Has anybody experienced this issue? What could be causing it? And
| | more
| | importantly, is there a good way to prevent this from happening?
| |
| | Many thanks in advance!!
| | Alejandro
|
| |
| |
| |
| | --
| | View this message in context:
| | http://forum.world.st/CorruptObj-error-tp4657451.html
|
| | Sent from the GLASS mailing list archive at Nabble.com.
| |
|
|
|
|
|
|
| If you reply to this email, your message will be added to the
| discussion below:
| http://forum.world.st/CorruptObj-error-tp4657451p4657555.html
|
|
| To unsubscribe from CorruptObj error, click here .
| NAML
|
|
| View this message in context: Re: CorruptObj error
| Sent from the GLASS mailing list archive at Nabble.com.
|
keropotter
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: CorruptObj error

keropotter
Thank you very much, Dale!!

I will wait for your advice then!


On Sat, Dec 1, 2012 at 12:32 PM, Dale Henrichs [via Smalltalk] <[hidden email]> wrote:
Alejandro,

The installDebugBlock code is going to intercept every exception before it is handled, so before installing that code into production do some testing to ensure that it won't have an adverse impact on your production environment ...

In fact, let me talk to some of the other engineers here (on Monday) to see if there might be a less intrusive approach for production...

Dale

----- Original Message -----
| From: "keropotter" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, December 1, 2012 6:14:54 AM
| Subject: Re: [GS/SS Beta] CorruptObj error
|
| Hello, Dale!
|
|
| Thank you very much for your kind help!! As this is a production
| environment, and making changes to it involves a fair amount of
| bureaucracy, I will ask for this to be done on Monday and get back
| to you with the results as soon as I can. I would do it now on our
| development environment, but i haven't been able to reproduce it. I
| will try there too anyway!
|
|
| Thanks again!!
| Alejandro
|
|
|
| On Fri, Nov 30, 2012 at 9:52 PM, Dale Henrichs [via Smalltalk] <
| [hidden email] > wrote:
|
|
| Alejandro,
|
| The Transaction error is occuring because you are getting another
| error that is not being caught or logged. To force the logging of
| the "mystery error", put the following chunk of code in the topaz
| script that launches your fastcgi servers (probably in
| startSeaside30_Adaptor somewhere before the line that starts `GsFile
| gciLogServer:`):
|
| AbstractException
| installDebugBlock: [:ex |
| ex gsNumber = 2261
| ifTrue: [
| GRPlatform current
| logError: ex description
| title: 'ERROR 2261 caught'
| shouldCommit: false].
| ].
|
| This installs a static exception handler that will catch and log
| error 2261 (the 'CorruptObj error') ... the debugBlock is run BEFORE
| any other exception handlers are fired off ...
|
| It is this error that we need to understand, since the Transaction
| error is a side effect ...
|
| Dale
|
|
| ----- Original Message -----
| | From: "keropotter" < [hidden email] >
| | To: [hidden email]
| | Sent: Friday, November 30, 2012 8:07:26 AM
| | Subject: [GS/SS Beta] CorruptObj error
| |
| | Hi, everyone!
| |
| | We're running a system on GLASS (Gemstone 3.0.1, Seaside 3.0) and
| | we're
| | receiving multiple complains about this error:
| |
| | *Internal Server Error:
|
| | a TransactionError occurred (error 2249), Further commits have been
| | disabled
| | for this session because: 'CorruptObj error'. This session must
| | logout.
| | You should contact the system administrator*
| |
| | While going through the ObjectLog, i deleted a few entries and
| | sorted
| | them
| | by time and I got the error myself twice within seconds.
| |
| | Has anybody experienced this issue? What could be causing it? And
| | more
| | importantly, is there a good way to prevent this from happening?
| |
| | Many thanks in advance!!
| | Alejandro
|
| |
| |
| |
| | --
| | View this message in context:
| | http://forum.world.st/CorruptObj-error-tp4657451.html
|
| | Sent from the GLASS mailing list archive at Nabble.com.
| |
|
|
|
|
|
|
| If you reply to this email, your message will be added to the
| discussion below:
| http://forum.world.st/CorruptObj-error-tp4657451p4657555.html
|
|
| To unsubscribe from CorruptObj error, click here .
| NAML
|
|
| View this message in context: Re: CorruptObj error
| Sent from the GLASS mailing list archive at Nabble.com.
|


If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/CorruptObj-error-tp4657451p4657585.html
To unsubscribe from CorruptObj error, click here.
NAML

Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: CorruptObj error

Dale Henrichs
Alejandro,

The static debug handler should be safe to use in production, but you want to make sure that your handler block is correct by running something like the following in your development enviroment:

    AbstractException
      installDebugBlock: [:ex |
       ex gsNumber = 2741
          ifTrue: [
            GRPlatform current
              logError: ex description
              title: 'Testing ... should log Deprecated not Warning'
              shouldCommit: false].
        ].
    [
        Warning signal: 'skip me'.
        Deprecated signal: 'catch me' ]
                on: Deprecated, Warning
                do: [:ex |
                        Transcript cr; show: 'got here: ', ex gsNumber printString.
                        ex resume . ].

And it should produce an entry in your gem log file like the following:

----------- Testing ... should log Deprecated not Warning LOG ENTRY: anArray-----------
----------- Testing ... should log Deprecated not Warning ERROR Encountered: 2012-12-05T14:21:12.56282901763916-08:00
Deprecated: catch me
1 GRGemStonePlatform >> logError:title:shouldCommit: (envId 0) @2 line 4  [GsNMethod 51113217]
2 [] in  Executed Code  (envId 0) @7 line 6  [GsNMethod 202627841]
3 AbstractException >> _debugException: (envId 0) @2 line 12  [GsNMethod 4520961]
4 AbstractException >> _executeHandler: (envId 0) @2 line 7  [GsNMethod 4524801]
5 AbstractException >> _signalWith: (envId 0) @1 line 1  [GsNMethod 4505857]
6 AbstractException >> signal: (envId 0) @3 line 7  [GsNMethod 4496641]
7 AbstractException class >> signal: (envId 0) @3 line 4  [GsNMethod 4388609]
8 [] in  Executed Code  (envId 0) @3 line 11  [GsNMethod 202627585]
9 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 3746049]
10 Executed Code            @4 line 11  [GsNMethod 202627329]
11 String >> evaluateInContext:symbolList: (envId 0) @3 line 10  [GsNMethod 2406145]
12 JadeServer >> evaluate:inContext: (envId 0) @4 line 4  [GsNMethod 91699457]
13 JadeServer >> doIt:in: (envId 0) @2 line 3  [GsNMethod 48598529]
14 <Reenter marker>
-----------


Note that the installDebugBlock: is only triggered before an on:do: is executed, which is why the test has to introduce handlers.

The gsNumber of CorruptObj is 2261, so change only that (and the message) in the block that you install in production ... You should get log entries with the stack for any 2261 errors that get thrown and by looking at the methods on the stack find the exception handler that is masking error ...

Good luck,

Dale

----- Original Message -----
| From: "keropotter" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, December 1, 2012 9:34:26 AM
| Subject: Re: [GS/SS Beta] CorruptObj error
|
| Thank you very much, Dale!!
|
|
| I will wait for your advice then!
|
|
|
| On Sat, Dec 1, 2012 at 12:32 PM, Dale Henrichs [via Smalltalk] <
| [hidden email] > wrote:
|
|
| Alejandro,
|
| The installDebugBlock code is going to intercept every exception
| before it is handled, so before installing that code into production
| do some testing to ensure that it won't have an adverse impact on
| your production environment ...
|
| In fact, let me talk to some of the other engineers here (on Monday)
| to see if there might be a less intrusive approach for production...
|
|
| Dale
|
| ----- Original Message -----
| | From: "keropotter" < [hidden email] >
| | To: [hidden email]
|
| | Sent: Saturday, December 1, 2012 6:14:54 AM
| | Subject: Re: [GS/SS Beta] CorruptObj error
| |
|
| | Hello, Dale!
| |
| |
| | Thank you very much for your kind help!! As this is a production
| | environment, and making changes to it involves a fair amount of
| | bureaucracy, I will ask for this to be done on Monday and get back
| | to you with the results as soon as I can. I would do it now on our
| | development environment, but i haven't been able to reproduce it. I
| | will try there too anyway!
| |
| |
| | Thanks again!!
| | Alejandro
| |
| |
| |
| | On Fri, Nov 30, 2012 at 9:52 PM, Dale Henrichs [via Smalltalk] <
|
|
| | [hidden email] > wrote:
| |
| |
| | Alejandro,
| |
| | The Transaction error is occuring because you are getting another
| | error that is not being caught or logged. To force the logging of
| | the "mystery error", put the following chunk of code in the topaz
| | script that launches your fastcgi servers (probably in
| | startSeaside30_Adaptor somewhere before the line that starts
| | `GsFile
| | gciLogServer:`):
| |
| | AbstractException
| | installDebugBlock: [:ex |
| | ex gsNumber = 2261
| | ifTrue: [
| | GRPlatform current
| | logError: ex description
| | title: 'ERROR 2261 caught'
| | shouldCommit: false].
| | ].
| |
| | This installs a static exception handler that will catch and log
| | error 2261 (the 'CorruptObj error') ... the debugBlock is run
| | BEFORE
| | any other exception handlers are fired off ...
| |
| | It is this error that we need to understand, since the Transaction
| | error is a side effect ...
| |
| | Dale
| |
| |
| | ----- Original Message -----
| | | From: "keropotter" < [hidden email] >
| | | To: [hidden email]
| | | Sent: Friday, November 30, 2012 8:07:26 AM
| | | Subject: [GS/SS Beta] CorruptObj error
| | |
| | | Hi, everyone!
| | |
| | | We're running a system on GLASS (Gemstone 3.0.1, Seaside 3.0) and
| | | we're
| | | receiving multiple complains about this error:
| | |
| | | *Internal Server Error:
| |
| | | a TransactionError occurred (error 2249), Further commits have
| | | been
| | | disabled
| | | for this session because: 'CorruptObj error'. This session must
| | | logout.
| | | You should contact the system administrator*
| | |
| | | While going through the ObjectLog, i deleted a few entries and
| | | sorted
| | | them
| | | by time and I got the error myself twice within seconds.
| | |
| | | Has anybody experienced this issue? What could be causing it? And
| | | more
| | | importantly, is there a good way to prevent this from happening?
| | |
| | | Many thanks in advance!!
| | | Alejandro
| |
| | |
| | |
| | |
| | | --
| | | View this message in context:
| | | http://forum.world.st/CorruptObj-error-tp4657451.html
| |
| | | Sent from the GLASS mailing list archive at Nabble.com.
| | |
| |
| |
| |
| |
| |
| |
|
| | If you reply to this email, your message will be added to the
| | discussion below:
| | http://forum.world.st/CorruptObj-error-tp4657451p4657555.html
| |
| |
| | To unsubscribe from CorruptObj error, click here .
| | NAML
| |
| |
| | View this message in context: Re: CorruptObj error
|
| | Sent from the GLASS mailing list archive at Nabble.com.
| |
|
|
|
|
|
|
| If you reply to this email, your message will be added to the
| discussion below:
| http://forum.world.st/CorruptObj-error-tp4657451p4657585.html
|
|
| To unsubscribe from CorruptObj error, click here .
| NAML
|
|
| View this message in context: Re: CorruptObj error
| Sent from the GLASS mailing list archive at Nabble.com.
|
keropotter
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: CorruptObj error

keropotter
Thank you very much, Dale!!

I will try this piece of code in my develpment environment and then install it in production. I've had no error reports since yesterday. It's strange, but it appears from time to time, so I guess the error will come back soon and I'll be able to debug it thanks to you.

I will get back to you when I gather some information on the error!

Thank you very much again!!
Alejandro


On Wed, Dec 5, 2012 at 7:26 PM, Dale Henrichs [via Smalltalk] <[hidden email]> wrote:
Alejandro,

The static debug handler should be safe to use in production, but you want to make sure that your handler block is correct by running something like the following in your development enviroment:

    AbstractException
      installDebugBlock: [:ex |
       ex gsNumber = 2741
          ifTrue: [
            GRPlatform current
              logError: ex description
              title: 'Testing ... should log Deprecated not Warning'
              shouldCommit: false].
        ].
    [
        Warning signal: 'skip me'.
        Deprecated signal: 'catch me' ]
                on: Deprecated, Warning
                do: [:ex |
                        Transcript cr; show: 'got here: ', ex gsNumber printString.
                        ex resume . ].

And it should produce an entry in your gem log file like the following:

----------- Testing ... should log Deprecated not Warning LOG ENTRY: anArray-----------
----------- Testing ... should log Deprecated not Warning ERROR Encountered: 2012-12-05T14:21:12.56282901763916-08:00
Deprecated: catch me
1 GRGemStonePlatform >> logError:title:shouldCommit: (envId 0) @2 line 4  [GsNMethod 51113217]
2 [] in  Executed Code  (envId 0) @7 line 6  [GsNMethod 202627841]
3 AbstractException >> _debugException: (envId 0) @2 line 12  [GsNMethod 4520961]
4 AbstractException >> _executeHandler: (envId 0) @2 line 7  [GsNMethod 4524801]
5 AbstractException >> _signalWith: (envId 0) @1 line 1  [GsNMethod 4505857]
6 AbstractException >> signal: (envId 0) @3 line 7  [GsNMethod 4496641]
7 AbstractException class >> signal: (envId 0) @3 line 4  [GsNMethod 4388609]
8 [] in  Executed Code  (envId 0) @3 line 11  [GsNMethod 202627585]
9 ExecBlock >> on:do: (envId 0) @3 line 42  [GsNMethod 3746049]
10 Executed Code            @4 line 11  [GsNMethod 202627329]
11 String >> evaluateInContext:symbolList: (envId 0) @3 line 10  [GsNMethod 2406145]
12 JadeServer >> evaluate:inContext: (envId 0) @4 line 4  [GsNMethod 91699457]
13 JadeServer >> doIt:in: (envId 0) @2 line 3  [GsNMethod 48598529]
14 <Reenter marker>
-----------


Note that the installDebugBlock: is only triggered before an on:do: is executed, which is why the test has to introduce handlers.

The gsNumber of CorruptObj is 2261, so change only that (and the message) in the block that you install in production ... You should get log entries with the stack for any 2261 errors that get thrown and by looking at the methods on the stack find the exception handler that is masking error ...

Good luck,

Dale

----- Original Message -----
| From: "keropotter" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, December 1, 2012 9:34:26 AM
| Subject: Re: [GS/SS Beta] CorruptObj error
|
| Thank you very much, Dale!!
|
|
| I will wait for your advice then!
|
|
|
| On Sat, Dec 1, 2012 at 12:32 PM, Dale Henrichs [via Smalltalk] <
| [hidden email] > wrote:
|
|
| Alejandro,
|
| The installDebugBlock code is going to intercept every exception
| before it is handled, so before installing that code into production
| do some testing to ensure that it won't have an adverse impact on
| your production environment ...
|
| In fact, let me talk to some of the other engineers here (on Monday)
| to see if there might be a less intrusive approach for production...
|
|
| Dale
|
| ----- Original Message -----
| | From: "keropotter" < [hidden email] >
| | To: [hidden email]
|
| | Sent: Saturday, December 1, 2012 6:14:54 AM
| | Subject: Re: [GS/SS Beta] CorruptObj error
| |
|
| | Hello, Dale!
| |
| |
| | Thank you very much for your kind help!! As this is a production
| | environment, and making changes to it involves a fair amount of
| | bureaucracy, I will ask for this to be done on Monday and get back
| | to you with the results as soon as I can. I would do it now on our
| | development environment, but i haven't been able to reproduce it. I
| | will try there too anyway!
| |
| |
| | Thanks again!!
| | Alejandro
| |
| |
| |
| | On Fri, Nov 30, 2012 at 9:52 PM, Dale Henrichs [via Smalltalk] <
|
|
| | [hidden email] > wrote:
| |
| |
| | Alejandro,
| |
| | The Transaction error is occuring because you are getting another
| | error that is not being caught or logged. To force the logging of
| | the "mystery error", put the following chunk of code in the topaz
| | script that launches your fastcgi servers (probably in
| | startSeaside30_Adaptor somewhere before the line that starts
| | `GsFile
| | gciLogServer:`):
| |
| | AbstractException
| | installDebugBlock: [:ex |
| | ex gsNumber = 2261
| | ifTrue: [
| | GRPlatform current
| | logError: ex description
| | title: 'ERROR 2261 caught'
| | shouldCommit: false].
| | ].
| |
| | This installs a static exception handler that will catch and log
| | error 2261 (the 'CorruptObj error') ... the debugBlock is run
| | BEFORE
| | any other exception handlers are fired off ...
| |
| | It is this error that we need to understand, since the Transaction
| | error is a side effect ...
| |
| | Dale
| |
| |
| | ----- Original Message -----
| | | From: "keropotter" < [hidden email] >
| | | To: [hidden email]
| | | Sent: Friday, November 30, 2012 8:07:26 AM
| | | Subject: [GS/SS Beta] CorruptObj error
| | |
| | | Hi, everyone!
| | |
| | | We're running a system on GLASS (Gemstone 3.0.1, Seaside 3.0) and
| | | we're
| | | receiving multiple complains about this error:
| | |
| | | *Internal Server Error:
| |
| | | a TransactionError occurred (error 2249), Further commits have
| | | been
| | | disabled
| | | for this session because: 'CorruptObj error'. This session must
| | | logout.
| | | You should contact the system administrator*
| | |
| | | While going through the ObjectLog, i deleted a few entries and
| | | sorted
| | | them
| | | by time and I got the error myself twice within seconds.
| | |
| | | Has anybody experienced this issue? What could be causing it? And
| | | more
| | | importantly, is there a good way to prevent this from happening?
| | |
| | | Many thanks in advance!!
| | | Alejandro
| |
| | |
| | |
| | |
| | | --
| | | View this message in context:
| | | http://forum.world.st/CorruptObj-error-tp4657451.html
| |
| | | Sent from the GLASS mailing list archive at Nabble.com.
| | |
| |
| |
| |
| |
| |
| |
|
| | If you reply to this email, your message will be added to the
| | discussion below:
| | http://forum.world.st/CorruptObj-error-tp4657451p4657555.html
| |
| |
| | To unsubscribe from CorruptObj error, click here .
| | NAML
| |
| |
| | View this message in context: Re: CorruptObj error
|
| | Sent from the GLASS mailing list archive at Nabble.com.
| |
|
|
|
|
|
|
| If you reply to this email, your message will be added to the
| discussion below:
| http://forum.world.st/CorruptObj-error-tp4657451p4657585.html
|
|
| To unsubscribe from CorruptObj error, click here .
| NAML
|
|
| View this message in context: Re: CorruptObj error
| Sent from the GLASS mailing list archive at Nabble.com.
|


If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/CorruptObj-error-tp4657451p4658220.html
To unsubscribe from CorruptObj error, click here.
NAML

Free forum by Nabble Edit this page