Weird pointer errors... Stackless problem? PyString_InternInPlace Fatal error

Christian Tismer tismer at appliedbiometrics.com
Mon Sep 18 04:18:54 EDT 2000


Mike Fletcher wrote:
> 
> 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...

The lock is not in the continuation.
The lock is in the thread_state of your system thread.

> 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).

No, not removing, but make them specific to the exceptions
which you expect, and let others make it through.

NOTE!: The lock flag is also cleared automatically if the
scheduler is run. So, regardless of the lock state:
Whenever a task is run by the scheduler, then there is no lock.

> 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!>).

Why don't you just give me a copy of your code?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com



More information about the Python-list mailing list