Re: [Pan-devel] Recent font problem

[Heinrich Mueller]

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
> > cairo.
> 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
> encryption.
>
> 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
> article-cache!)
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.

Cheers.