[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-devel] Recent font problem

From: Heinrich Mueller
Subject: Re: [Pan-devel] Recent font problem
Date: Sun, 18 Dec 2011 07:47:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111108 Thunderbird/8.0

Am 17.12.2011 23:55, schrieb walt:
Heinrich Müller<address@hidden>  writes:

Also, could you try to pull from their git and compile that version of
Good old gentoo makes it trivial :)

I installed the latest git cairo and the assertion was never hit.
I notice that the function cairo_surface_get_device_offset no longer
calls the matrix_invert function where the assertion was, so I dunno
if that tells us anything.
Well, the error has something to do with matrix inversion, but I'm not familiar
as to why cairo would use that and how. Well, perhaps someday ;)

Second, could you try to use an older version of libgcrypt
Yes!  I 'downdated' to libgcrypt-1.4.6 from 1.5.0 and that fixed the
assertion in both places I've been hitting it.
I saw a mention of that downgrade fixing the same assertion in another
program. It could have something to do with global locks libgcrypt has
to use that belong to the openssl context. But that's a little voodoo,
but OpenSSL is pretty obscure, anyway. Don't even ask ;)

The first place is when I dismiss the accept certificate dialog box.
This change isn't surprising because (at least) that activity involves

But the other case where the cairo assertion is now fixed/avoided is
when downloading a single part of a multipart binary from an nzb file.
The binary part is neither encrypted nor cryptographically signed, but
*is* yencoded, FWIW.
Again, perhaps it has something to do with openssl. I have _no_ idea
how cairo comes into play here, but good to see it gone.
Can you think of a section of pan code that might use libgcrypt code
to download a yencoded (single) part of a non-encrypted multi-part?
The y-decoding is done in workerthreads in TaskArticle, so no. OpenSSL
just reads from the socket and that's it. This is even before the whole
gmime/header/nntp stuff takes place.
(This is only mid-way through downloading the multi-part, so it's
way too early for pan to try to y-decode it, right?  And also, pan
hits the cairo assertion before the binary part is even saved to the
Yes. The article cache saves plain-text btw, the decoding is done on-the-fly. I don't think it has anything to do with yenc, rather with something odd happening
with threads.
Well, we _could_ try to disable threads by setting server connections to 1 and disabling the global mutexes in OpenSSL, but I'm not really motivated. As long as the error is gone for good, it's a sisyphean task. But feel free to investigate further if you have the time.
Thanks for your observations so far. See you.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]