Weird pointer errors... Stackless problem? PyString_InternIn Place Fatal error

[Mike Fletcher]

Hmm, by that description (assuming I understood it, I got lost somewhere in
there), the uthread lock should be fine...  i.e. if the lock-state is stored
in the continuation (which you seem to say it is), then it is restored when
the continuation is called (the thread is woken up).  The finally clause
around atomic should be altering a different frame than the one encoded in
the continuation... I think...

Note, it's not a try-except clause (at least, not in uthread9), it's a
try-finally.  My code has try-except clauses, should I try removing those
(difficult, but I might be able to try it in a week).

Urgh.  Really not sure here, and not enough time to play.  I've got a
deadline in two days, so I'll likely just try to back out my work until I
find something that doesn't trigger the error (looks like a few weeks so far
<eeps!>).

Ah, to stop the world,
that I might walk through pastures green again, 
might sign the songs I loved back then, 
might dig toes in moist soil smiling, 
might dream cloud palaces and sunshine heros
might dream of days when I will grow
and live this life I live.

Enjoy all,
Mike

-----Original Message-----
From: Christian Tismer [mailto:tismer at appliedbiometrics.com]
Sent: Saturday, September 16, 2000 6:15 AM
To: Mike Fletcher
Cc: Python List (E-mail)
Subject: Re: Weird pointer errors... Stackless problem?
PyString_InternInPlace Fatal error




Mike Fletcher wrote:
...
Clarification on the lock:
No, it is much much simpler.
The thread_state has a single flag, which tells whether
automatic context switching is allowed or not.
Every new interpreter incarnation starts with this
flag set, so by default there are no running uthreads.
After a recursive interpreter finishes, it restores the
lock value which was there before it was run. So far on
recursive behavior. (nightingale, do I hear yor whispering?)
...
Anyway, wrong or not, the system may not crash under any
circumstances, and I'm sure that I'm missing some cases
here. Now, can it be that you are unlocking while you
are in an interpreter recursion?
This should normally work until your frame chain returns
to the caller of the recursion by a continuation. The frame
is hit in an unsane state, which is prevented. Nobody can
create a continuation of a frame that is waiting for
completion of a ceval recursion. Instead, an exception
is thrown.
But I realize that you are catching every exception.
Can you try to remove the try..except, or be more specific?

I can imagine that I wind up in a situation where I cannot
run the current frame, but I don't handle the above situation
correctly, causing refcount problems.
...