I get this error in ACL. What does it mean? Am I just using way too
much memory or something?
Error: Attempt to store into purespace address #xea408400.
[condition type: SIMPLE-ERROR]
Error: Attempt to store into purespace address #xea76ea38.
[condition type: SIMPLE-ERROR]
dave
In article <···············@engc.bu.edu>, David Bakhash <·····@bu.edu> wrote:
>I get this error in ACL. What does it mean? Am I just using way too
>much memory or something?
>
>Error: Attempt to store into purespace address #xea408400.
> [condition type: SIMPLE-ERROR]
'Purespace' is a shared, read-only part of the Allegro image. Attempted
stores into purespace are likely a sign of pointer corruption.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
······@best.com (Chuck Fry) writes:
> In article <···············@engc.bu.edu>, David Bakhash <·····@bu.edu> wrote:
> >I get this error in ACL. What does it mean? Am I just using way too
> >much memory or something?
> >
> >Error: Attempt to store into purespace address #xea408400.
> > [condition type: SIMPLE-ERROR]
>
> 'Purespace' is a shared, read-only part of the Allegro image.
This is correct, although in ACL5 it really only appears as a
separate file.
> Attempted stores into purespace are likely a sign of pointer corruption.
More likely, it is a simple case of trying to modify a string constant.
ANSI CL disallows modification of literal constants of any kind, and we
take advantage of this fact to allow strings and codevectors to be placed
into "purespace", the read-only, shared file that you described.
Modifications should only ever be done on objects you know are not
constants; when in doubt, copy it.
Example:
USER(1): (symbol-name 'car)
"CAR"
USER(2): (setf (aref * 1) #\D)
Error: Attempt to store into purespace address #xea8fddad.
[condition type: SIMPLE-ERROR]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart)
[1] USER(3): (copy-seq *)
"CAR"
[1] USER(4): (progn (setf (aref * 1) #\D) *)
"CDR"
[1] USER(5):
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> ······@best.com (Chuck Fry) writes:
>
> > Attempted stores into purespace are likely a sign of pointer corruption.
>
> More likely, it is a simple case of trying to modify a string constant.
> ANSI CL disallows modification of literal constants of any kind, and we
> take advantage of this fact to allow strings and codevectors to be placed
> into "purespace", the read-only, shared file that you described.
> Modifications should only ever be done on objects you know are not
> constants; when in doubt, copy it.
I highly doubt that this is being done in my code. In My code only
operates on vectors, and does numerical manipulations. Nothing of the
sort you're describing above. Of course, after the stuff compiles, I
have no idea what's hapening.
dave
Beware use of #. as well, if you attempt to modify the result. I'm not what
ANSI says about this, but it has the potential to be considered a literal for
read-only space.
David Bakhash <·····@bu.edu> wrote:
>Duane Rettig <·····@franz.com> writes:
>
>> ······@best.com (Chuck Fry) writes:
>>
>> > Attempted stores into purespace are likely a sign of pointer corruption.
>>
>> More likely, it is a simple case of trying to modify a string constant.
>> ANSI CL disallows modification of literal constants of any kind, and we
>> take advantage of this fact to allow strings and codevectors to be placed
>> into "purespace", the read-only, shared file that you described.
>> Modifications should only ever be done on objects you know are not
>> constants; when in doubt, copy it.
>
>I highly doubt that this is being done in my code. In My code only
>operates on vectors, and does numerical manipulations. Nothing of the
>sort you're describing above. Of course, after the stuff compiles, I
>have no idea what's hapening.
>
>dave
D. Tenny
············@mediaone.net - no spam please