[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Font-Related Segfault



Maybe my cStringIO has been transparently replaced by StringIO for
some reason. I would think that cStringIO would be available on this
platform but perhaps not.

On Mon, Nov 23, 2009 at 7:03 PM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
> Strange. cStringIO works for me. I have localized the problem to the first
> call to the file like object's tell method. But since this is the first
> method called, it might not be limited to it.
>
> Lenard Lindstrom
>
> Bryce Schroeder wrote:
>>
>> cStringIO seems to have the same problem for me.
>> It is already using open with 'rb'.
>> Thanks for all your help, I will await the next version / patch I guess.
>>
>> On Mon, Nov 23, 2009 at 5:24 PM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
>>
>>>
>>> Hi Bryce,
>>>
>>> Try using cStringIO instead. And make sure to open the file 'rb' (this
>>> won't
>>> matter on Linux, but will on Windows). I reproduced your problem with a
>>> modified pygame.examples.fonty, and yes, it appears to be a bug. StringIO
>>> instances should work.
>>>
>>> Lenard Lindstrom
>>>
>>> Bryce Schroeder wrote:
>>>
>>>>
>>>> This code reproduces the problem. It is also as an attachment.
>>>>
>>>> My system:
>>>> uname -a:
>>>> Linux thales 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC
>>>> 2009 x86_64 GNU/Linux
>>>>
>>>>
>>>> -------file: tester.py --------------
>>>> import pygame, StringIO, sys
>>>> pygame.font.init()
>>>> if len(sys.argv) != 2:
>>>>       print >> sys.stderr, "Usage: python tester.py font.ttf"
>>>>       sys.exit(1)
>>>>
>>>> font = pygame.font.Font(sys.argv[1], 12)
>>>> print "Loaded the font as a file:", font
>>>>
>>>> test = open(sys.argv[1]).read()
>>>> stio = StringIO.StringIO(test)
>>>> font2 = pygame.font.Font(stio, 12)
>>>> print "Loaded the font as a StringIO:", font2
>>>> -------------------------------------------------
>>>>
>>>> On Mon, Nov 23, 2009 at 2:27 PM, Bryce Schroeder
>>>> <bryce.schroeder@xxxxxxxxx> wrote:
>>>>
>>>>
>>>>>
>>>>> Okay:
>>>>> I wrote the string (self.parts['font']) out to a temporary file and
>>>>> diff'd it against the original file, and they are identical.
>>>>> Pygame successfully loads the font from the temporary file, and the
>>>>> font works normally. However I would definitely like to
>>>>> find a less kludgish solution to the problem.
>>>>>
>>>>> The particular font does not appear to matter, or at least, a wide
>>>>> variety of truetype fonts are affected - I can't load Junius Unicode
>>>>> or Free Serif from a StringIO either, but I can load them from files.
>>>>>
>>>>> It worked about six to eight months ago. Sorry I can't be more
>>>>> specific - I sort of mothballed the project for a while.
>>>>>
>>>>> Sorry I didn't provide a "demonstration program" I will try to keep
>>>>> that in mind in the future.
>>>>>
>>>>> - Bryce
>>>>>
>>>>>
>>>>> On Mon, Nov 23, 2009 at 2:05 PM, Brian Fisher
>>>>> <brian@xxxxxxxxxxxxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Pygame should be supporting a file-like object no problem, so this
>>>>>> seems
>>>>>> like it could be a bug.
>>>>>>
>>>>>> Can you be more specific on when in the past it worked, and what
>>>>>> happened
>>>>>> between then and when it segfaults now?
>>>>>>
>>>>>> Also, it's not clear from your problem description whether the problem
>>>>>> is
>>>>>> that pygame crashes when loading from a file-like object, or if pygame
>>>>>> crashes on a specific set of font data.
>>>>>>
>>>>>> So I would suggest doing a sanity check here by writing the
>>>>>> self.parts['font'] string to a temp file, and trying to load from
>>>>>> that,
>>>>>> as a
>>>>>> way of being able to determine if the crash is caused by the file-like
>>>>>> object reading, or by some problem with the contents of the file-like
>>>>>> object.
>>>>>>
>>>>>> So something like:
>>>>>> ------------
>>>>>> class Font(Resource):
>>>>>>  ....
>>>>>>  def pygame_font(self,size):
>>>>>>     file(temp_file_name, "w").write(self.parts['font'])
>>>>>>     return pygame.font.Font(temp_file_name, size)
>>>>>>     os.unlink(temp_file_name)
>>>>>> ------------
>>>>>> If that still crashes, then pygame has trouble with that font content,
>>>>>> and
>>>>>> then the question would be to figure out what about that font content
>>>>>> is
>>>>>> causing problems. If that doesn't crash, then the problem would be
>>>>>> with
>>>>>> accessing the content as a file-like object.
>>>>>>
>>>>>>
>>>>>> ... finally, as general advice to all people posting problems - if you
>>>>>> can
>>>>>> send a completely self-contained reproducible case, then you are much
>>>>>> more
>>>>>> likely to get good help and results faster. As an example in this
>>>>>> case,
>>>>>> providing the contents of the self.parts['font'] string in an attached
>>>>>> file
>>>>>> with a simple script that tries to load from a StringIO using that
>>>>>> file's
>>>>>> contents, would make this easily reproducible and testable by fellow
>>>>>> mailing
>>>>>> listers - but without knowing what the contents of the string in
>>>>>> question
>>>>>> are, it may actually be practically impossible for anyone else to test
>>>>>> themselves.
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 23, 2009 at 12:38 PM, Bryce Schroeder
>>>>>> <bryce.schroeder@xxxxxxxxx> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> (My apologies if this is a double-post. I didn't get a copy of the
>>>>>>> message or see it in the archive, so I'm trying again.)
>>>>>>>
>>>>>>>  I have a pygame program that worked in the past on both Linux and
>>>>>>> Windows, but now results in a segfault, at least on Linux.  (I can't
>>>>>>> test it on Windows.)
>>>>>>> The segfault occurs in this code:
>>>>>>>
>>>>>>> class Font(Resource):
>>>>>>>  ....
>>>>>>>  def pygame_font(self,size):
>>>>>>>     return pygame.font.Font(StringIO.StringIO(self.parts['font']),
>>>>>>> size) # Segfaults here
>>>>>>>
>>>>>>>
>>>>>>> self.parts['font'] is a string containing a truetype font loaded from
>>>>>>> a file. I have checked that the string contains the file like it is
>>>>>>> supposed too. Any suggestions?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>
>