[Users] [Bug 2656] crash: claws-mail assert failure when using SSL or STARTTLS with SMTP

[noreply at thewildbeast.co.uk]

http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2656

--- Comment #13 from dev at diy-biogas.eu ---
Please help to bring this forward.

> Let me quote the (shortened) source:
> 
> void
> cairo_surface_set_device_offset (cairo_surface_t *surface, double
> x_offset, double y_offset) {
>     cairo_status_t status;
> 
>     if (unlikely (surface->status))
>  return;
> 
> [...]
> 
>     surface->device_transform.x0 = x_offset;
>     surface->device_transform.y0 = y_offset;
> 
>     surface->device_transform_inverse = surface->device_transform;
>     status = cairo_matrix_invert (&surface->device_transform_inverse);
>     /* should always be invertible unless given pathological input */
>     assert (status == CAIRO_STATUS_SUCCESS);
> 
> [...]
> }
> 
> You can see different things:
> - This function doesn't do anything on error surface (=> cairo
> correctly ignores operations on error surfaces)
> - The only assert() in there has a comment which says "it's virtually
> impossible for this to fail"
> 
> I agree with this assert(). The device_transform should always be a
> translation matrix and those are always invertible. So unless I missed
> something, this leaves "random memory corruption" as the most likely
> case for this assert() to trigger (and debugging random memory
> corruption is hard and most likely not a bug in cairo).
> 
> Also, this is why I asked for someone to ask gdb which values the
> device_transform contains after a crash.
(https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/887850/comments/34)

I sent my gdb output to him and find him baffled:

> this looks a lot like what Sergio showed before and I still have no
> clue what this would mean. The device_transform is all set to -NaN
> which is quite weird. Sadly, this doesn't look like memory
> corruption. No idea how to figure out where those NaNs are coming
> from. Sorry.

He referred to
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/887850/comments/41

> What Chris meant to say was this:
> This problem can only happen with broken applications.
> Cairo 1.8 was written in a way to cope with these breakages. But
> somewhere along the way we lost that feature, because we don't test
> broken applications (and I don't think we intend to).
> 
> But in this case, the particular error message and the resulting abort
> is due to the application (or a library it's using) calling
> cairo_surface_set_device_offset() when the cairo context is already in
> an error state.

Can you tell how to check if this is true via gdb or somethin else?

-- 
You are receiving this mail because:
You are the assignee for the bug.