VAST / Seaside and Glorp: GPF when rolling back old sessions

Hi there,

I have a problem with my VA ST based Glorp/Seaside Application.

Every once in a while, when Seaside decides to tidy up old user sessions, I get the following error:

'Primitive failed in: PlatformFunction>>#callWithArguments: due to General protection fault - read from invalid memory location'

what's failing is the call to OBDC32.DLL / SQLEndTran function. My guess is that what's happening is that my rollback of a transaction in the Seaside Session is happening so late that the ODBC Library has already freed it.

Now if that is true (and I have no idea how I would go about finding out if it is), the question is: what can I do to avoid this? What I currently do is a rollback of the last open transaction before I disconnect the session. This is done in the #unregistered method of my WASession subclass, which means I can not do much about the point in time when it happens. Seaside cleans up old sessions when it needs new ones, not when the their expiry time has come...

I Guess VADatabaseAccessor (or a superclass of it) should check with the ODBC layer if a handle (instvar hdbc) is still valid before it does anything with it. Right? And if so, how could it?

Or am I on a completely wrong track?

Any hint is greatly appreciated

Joachim

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/glorp-group/-/QuYtD62q_icJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.

If you're getting a general protection failure, that sounds like the handle isn't just invalid, but like it may have already been released and zeroed out, though that's not definite.

You won't get any notification of it being timed out at the database or driver level, so normally what you'd need to do is find some test that will confirm if it's connected or not.  If it's explicitly being freed at the Smalltalk level, then you should make sure that whatever frees it also nils out the handle. If it's at the driver level, then it's trickier. But I'd have suspected that at the driver level a rollback transaction would have failed with a you're not connected rather than a general protection fault.

---

[hidden email]
18 October, 2011 9:00 AM

Hi there,

I have a problem with my VA ST based Glorp/Seaside Application.

Every once in a while, when Seaside decides to tidy up old user sessions, I get the following error:

'Primitive failed in: PlatformFunction>>#callWithArguments: due to General protection fault - read from invalid memory location'

what's failing is the call to OBDC32.DLL / SQLEndTran function. My guess is that what's happening is that my rollback of a transaction in the Seaside Session is happening so late that the ODBC Library has already freed it.

Now if that is true (and I have no idea how I would go about finding out if it is), the question is: what can I do to avoid this? What I currently do is a rollback of the last open transaction before I disconnect the session. This is done in the #unregistered method of my WASession subclass, which means I can not do much about the point in time when it happens. Seaside cleans up old sessions when it needs new ones, not when the their expiry time has come...

I Guess VADatabaseAccessor (or a superclass of it) should check with the ODBC layer if a handle (instvar hdbc) is still valid before it does anything with it. Right? And if so, how could it?

Or am I on a completely wrong track?

Any hint is greatly appreciated

Joachim

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/glorp-group/-/QuYtD62q_icJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.

Hi Alan,

It is not zeroed out or nil'd on the Smalltalk side. The PlatformFunction is called with an actual Number.
So I guess there is some situation that needs to be checked before SQLEndTran is called.

>But I'd have suspected that at the driver level a rollback transaction would have failed with a you're not connected >rather than a general protection fault.

So would I. I can see the error code returned from the platform call is 53, and that is a GPF read error.
And it seems it is related to long inactivity, because I only get the error when I haven't started new sessions for quite a while, so that the ones that get unregistered are "very" old. If I constantly work in the app, rolling back works like a charm.

I tend to exitWith: nil the PrimitiveFailed for now, even if it leaves a bitter taste... I cannot be sure that Windows survives the real problem for a long time, because invalid handles are not a good omen... So I'll just see how far I get with it...

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/glorp-group/-/qdFrx9sF28cJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.

Hi again,

I may have found a solution, but I need to test a bit more.
The thing is: My WASession subclass holds on to a GlorpSession which is always in an open (image Transaction), but surely not in a Database transaction, because a DB transaction is only started when GLORP does a transact: or a commitUnitOfWork.

I can be very sure that the sessions that get cleaned up are in the middle of a DB transaction, so what I did was to ask the GlorpSession if it #isInTransaction. If it is not currently issueing any sql to the db, it is not.

So I only send a rollbackUnitOfWork if it isInTransaction. So far, this leads to no additional memory overhead or anything, and it avoids the GPFs.

But to be honest, I have no idea if that is anyway near rational ;-)

Any ideas?

Joachim

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/glorp-group/-/7w7RwKs1KXkJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.

Yes, that seems reasonable.  Presumably the database connection associated with that accessor is dead, so any attempt to do any other operations with it would also fail. But if you're just disposing of it, that should work fine. If you want to reuse it, it might be necessary to re-connect it or otherwise do something that makes sure it's alive.

---

[hidden email]
20 October, 2011 10:17 AM

Hi again,

I may have found a solution, but I need to test a bit more.
The thing is: My WASession subclass holds on to a GlorpSession which is always in an open (image Transaction), but surely not in a Database transaction, because a DB transaction is only started when GLORP does a transact: or a commitUnitOfWork.

I can be very sure that the sessions that get cleaned up are in the middle of a DB transaction, so what I did was to ask the GlorpSession if it #isInTransaction. If it is not currently issueing any sql to the db, it is not.

So I only send a rollbackUnitOfWork if it isInTransaction. So far, this leads to no additional memory overhead or anything, and it avoids the GPFs.

But to be honest, I have no idea if that is anyway near rational ;-)

Any ideas?

Joachim

---

[hidden email]
18 October, 2011 9:32 AM

If you're getting a general protection failure, that sounds like the handle isn't just invalid, but like it may have already been released and zeroed out, though that's not definite.

You won't get any notification of it being timed out at the database or driver level, so normally what you'd need to do is find some test that will confirm if it's connected or not.  If it's explicitly being freed at the Smalltalk level, then you should make sure that whatever frees it also nils out the handle. If it's at the driver level, then it's trickier. But I'd have suspected that at the driver level a rollback transaction would have failed with a you're not connected rather than a general protection fault.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.

---

[hidden email]
18 October, 2011 9:00 AM

Hi there,

I have a problem with my VA ST based Glorp/Seaside Application.

Every once in a while, when Seaside decides to tidy up old user sessions, I get the following error:

'Primitive failed in: PlatformFunction>>#callWithArguments: due to General protection fault - read from invalid memory location'

what's failing is the call to OBDC32.DLL / SQLEndTran function. My guess is that what's happening is that my rollback of a transaction in the Seaside Session is happening so late that the ODBC Library has already freed it.

Now if that is true (and I have no idea how I would go about finding out if it is), the question is: what can I do to avoid this? What I currently do is a rollback of the last open transaction before I disconnect the session. This is done in the #unregistered method of my WASession subclass, which means I can not do much about the point in time when it happens. Seaside cleans up old sessions when it needs new ones, not when the their expiry time has come...

I Guess VADatabaseAccessor (or a superclass of it) should check with the ODBC layer if a handle (instvar hdbc) is still valid before it does anything with it. Right? And if so, how could it?

Or am I on a completely wrong track?

Any hint is greatly appreciated

Joachim

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/glorp-group/-/QuYtD62q_icJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.

Alan,

I guess I have none of these options, because the handle is not valid any more (invalid memory read...), so I can just dispose of the handle by feeding the Smalltalk objects to the GC...

So, once again, thanks for listening and giving your advice. It was helpful.

Joachim

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/glorp-group/-/UAyFeSAt0W0J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/glorp-group?hl=en.