wiredfool added the comment:
Run on 64bit:
Breakpoint 1, getfont (self_=0x0, args=0x77faa130, kw=0x77faa120) at
_imagingft.c:142
142 if (!error)
(gdb) p ((TT_CMap)self->face->charmap)[0]
$4 = {cmap = {charmap = {face = 0x3036da0, encoding = FT_ENCODING_UNICODE,
platform_id = 3
New submission from dmlockhart :
I have some code which performs transformations of python ast objects. The
code
executes as expected in CPython 2.7, but when run with the pypy interpreter, I
receive the following traceback:
Traceback (most recent call last):
File "app_main.py", line 72, i
wiredfool added the comment:
Running under gdb, with symbols compiled into libfreetype, breaking in
_imagingft.c when
the font is created, and then just prior to the segfault.
(vpypy)erics@builder-1310-x86:~/Pillow$ gdb python
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 Free Software Foun
Armin Rigo added the comment:
Try again with tomorrow's build: http://buildbot.pypy.org/nightly/trunk/ . I
hope it should be a bit faster, but I don't know how much.
Note that our goal is to ensure that itertools is not massively slower than
plain Python, but we don't really care about making
Armin Rigo added the comment:
I cannot find anything wrong in PyPy (I ran it with MALLOC_CHECK_=3 in a special
mode to detect usage of memory after free()). I'd suggest to try to print all
operations done on this particular "face" object from C code, and comparing the
results on CPython and on
Armin Rigo added the comment:
It turned out to be unrelated. I tried compiling the .c files of Pillow with
the "-g -O0" flags. The crash occurs in libfreetype.so when in the call
"FT_Get_Char_Index(face, ch);" from _imagingft.c:222. As far as I can tell,
"face" and "ch" look reasonable. The
Armin Rigo added the comment:
A possibly related bug: when compiled with lldebug, pypy immediately crashes on
"import cpyext" with "in pypy_check_stack_count: bad stacks_counter or
non-closed stacks around".
--
nosy: +arigo
status: unread -> chatting
___
