Re: Recent font problem
Heinrich Mueller <[email protected]>
| Newsgroups | gmane.comp.gnome.apps.pan.devel |
|---|---|
| Message-ID | <[email protected]> |
Am 17.12.2011 23:55, schrieb walt: > Heinrich Müller<eddie_v@...> 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. _______________________________________________ Pan-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/pan-devel