Re: [Gramps-devel] trunk/master crash

[John R. <jr...@ce...>]

On Apr 12, 2014, at 2:26 PM, John Ralls <jr...@ce...> wrote:

> 
> On Apr 12, 2014, at 1:58 PM, Paul Franklin <pf....@gm...> wrote:
> 
>> I haven't tried to run trunk/master in a long
>> time, months at least.
>> 
>> Today I tried running it, today's git, and I get
>> a segmentation fault when I try to make a PDF
>> Complete Individual report.
>> 
>> Does anybody else get that?
> 
> Maybe similar. Serge reported a cairo crash in geography view to the list last september, and Nick reported the same one in pedigree view to me privately last week. In both cases the stack trace is
> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x000000000054dff5 in _PyCodec_Lookup (encoding=0x918c00 <unicode_default_encoding.28567> "utf8",
>>   encoding@entry=0x0) at ../Python/codecs.c:105
>> 105    ../Python/codecs.c: No such file or directory.
>> (gdb) bt
>> #0  0x000000000054dff5 in _PyCodec_Lookup (encoding=0x918c00 <unicode_default_encoding.28567> "utf8",
>>   encoding@entry=0x0) at ../Python/codecs.c:105
>> #1  codec_getitem.36397 (encoding=0x918c00 <unicode_default_encoding.28567> "utf8", index=index@entry=0)
>>   at ../Python/codecs.c:211
>> #2  0x00000000005b1667 in PyCodec_Encoder (encoding=<optimised out>) at ../Python/codecs.c:275
>> #3  PyCodec_Encode (object=0x750ef30, encoding=<optimised out>, errors=0x0) at ../Python/codecs.c:322
>> #4  0x00000000005b17e1 in PyUnicodeUCS4_AsEncodedString (unicode=0x750ef30,
>>   encoding=encoding@entry=0x0, errors=errors@entry=0x0) at ../Objects/unicodeobject.c:1368
>> #5  0x00000000005b1870 in _PyUnicodeUCS4_AsDefaultEncodedString (unicode=0x750ef30,
>>   errors=errors@entry=0x0) at ../Objects/unicodeobject.c:1391
>> #6  0x00000000005aa97c in PyString_AsStringAndSize (obj=<optimised out>, s=0x7fffffff8680,
>>   len=0x7fffffff8670) at ../Objects/stringobject.c:811
>> #7  0x000000000052aaa3 in string_getbuffer (op=<optimised out>) at ../Objects/stringobject.c:777
>> #8  PyString_AsString (op=<optimised out>) at ../Objects/stringobject.c:794
>> #9  0x00007fffe8334aa2 in ?? () from /usr/lib/python2.7/dist-packages/cairo/_cairo.so
>> #10 0x000000000056170a in call_function (oparg=<optimised out>, pp_stack=0x7fffffff87f0)
>>   at ../Python/ceval.c:4009
> 
> 
> and they’re both running Ubuntu. IIRC the internal PDF generator also draws on a Cairo canvas, so you might be seeing the same thing.
> 
> In Nick’s case it was from not encoding the image path of a thumbnail passed to cairo; apparently the version of _cairo.so in Ubuntu 13.10 passes something wrong to stringobject.c. I can’t replicate the problem here so I’m not able to debug it further than that.
> 
> If you can install the debugging symbols for python and cairo, then run `gdb python Gramps.py` and tell gdb `bt` after you crash it, you can compare the resulting stack trace with what’s above to see if it’s the same bug.

Paul told me privately that he was using Fedora 18, and I have a VM for that. A bit of debugging and looking through the py2cairo commit log reveals that this was fixed in 

http://cgit.freedesktop.org/py2cairo/commit/src/surface.c?id=04ae0c94d1e73ff39d731a44229a6eb079018666

which is included in py2cairo 1.10.0, but not in 1.8.10. The latter is what’s in F18 and Ubuntu 13.04 in spite of 1.10.0 having been released in May 2011.

Since we control the versions in the OSX and Win32 AIOs, I’ve restored the encode() of the pathnames passed to cairo only on Linux, pushed to master and gramps40.

Regards,
John Ralls