[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Segemantation fault while printing
From: |
Fred Kiefer |
Subject: |
Segemantation fault while printing |
Date: |
Sun, 09 Feb 2003 01:23:06 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903 |
When printing two times form within the same GNUstep applciation I get a
segmentaion fault. This is caused by a rather complex interplay between
the NSFont management and the SetLocal calls for printing. To explain it
I will have to list the involved steps:
1. My computer has a german setup, so the local for numericals uses a
"," to start with.
2. When printing the code switches to "." as the numerical separator.
3. When a NSFont is used it looks up in the cache if a similar font
already exists, here the matrix is printed into the lookup string so
the "." will be used here. And the font will be created as a new one and
stored under this key.
4. At the end of printing, we switch back to "," as the numerical separator.
5. When the NSFont object gets released by the autorelease pool, a key
with "," is used and no object will be freed (or even a wrong one) from
the cache.
6. Next time the same font gets printed there will be still an entry in
the cache, but no font that corresponds to it.
To work around the current problem it would be sufficient to bring the
SetLocal calls and autorelease pool code closer together. But this wont
resolve the general case, where an NSFont object survives longer.
We could also use a well defined local, for the creation of key for fonts.
Or we could store the key with the font itself, so that always the same
key will be used for caching and release.
All of this solutions have their drawbacks so it is hard to decide which
one should be used.
Fred
- Segemantation fault while printing,
Fred Kiefer <=