Bug 2907 - SIGTERM for cairo_surface_set_device_offset: status == CAIRO_STATUS_SUCCESS untrue
Summary: SIGTERM for cairo_surface_set_device_offset: status == CAIRO_STATUS_SUCCESS u...
Status: RESOLVED DUPLICATE of bug 2656
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: UI (show other bugs)
Version: 3.8.0
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2013-04-12 18:17 UTC by kardan
Modified: 2013-04-12 19:17 UTC (History)
0 users

See Also:


Attachments
trace for thread apply all bt (8.10 KB, text/plain)
2013-04-12 18:17 UTC, kardan
no flags Details

Description kardan 2013-04-12 18:17:34 UTC
Created attachment 1252 [details]
trace for thread apply all bt

Greetings,

i got a laptop into my hands with ubuntu (natty) installed.
upgraded via oneiric to precise and regularly when sending emails see a
sigterm. mail persists in queue, no data loss thanks to claws.

the problem obviously is related to outdated libs, so maybe some
versions need to be set for packaging in precise?

this is what i see:

send_message.c:364:send_message_smtp(): begin event loop
ssl.c:216:waiting for SSL_connect thread...
ssl.c:234:SSL_connect thread returned 0
ssl_certificate.c:383:got /home/kardan/.claws-mail/certs/ne...net.465.cert
first try ssl_certificate.c:233:got cert! 0xa70f9f0
ssl_certificate.c:393:got cert 0xa7115a0
session.c:184:session (0xa3995b8): connected
[17:40:56] SMTP< 220 netzguerilla.net ESMTP Postfix (Debian/GNU)
[17:40:56] ESMTP> EHLO universum
claws-mail: /build/buildd/cairo-1.10.2/src/cairo-surface.c:1287:
cairo_surface_set_device_offset: Zusicherung »status ==
CAIRO_STATUS_SUCCESS« nicht erfüllt. Abgebrochen (Speicherabzug
geschrieben)

ii  claws-mail                             3.8.0-1ubuntu1
ii  libcairo2                              1.10.2-6.1ubuntu3

it is absolutely reproduceable every time i send a mail. please tell me if you need more info, will keep the install untouched for so long. thanks.

all the best,
kardan
Comment 1 Paul 2013-04-12 19:17:57 UTC
looks very much the same as bug #2656

*** This bug has been marked as a duplicate of bug 2656 ***

Note You need to log in before you can comment on or make changes to this bug.