Bug 90095 - SIGBUS in polygon_add_edge on sparc
Summary: SIGBUS in polygon_add_edge on sparc
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: png functions (show other bugs)
Version: unspecified
Hardware: SPARC Linux (All)
: high normal
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-19 12:34 UTC by Peter Spiess-Knafl
Modified: 2015-04-21 20:08 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Peter Spiess-Knafl 2015-04-19 12:34:38 UTC
Hi!

We recently detected a bug in the debian package of libcairo2 on the
sparc architecture.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767858

In short, a SIGBUS occurs in cairo-tor-scan-converter.c:1504

Program received signal SIGBUS, Bus error.
0xf7c163c8 in polygon_add_edge (edge=<optimized out>, polygon=0x37f58)
at ../../../../src/cairo-tor-scan-converter.c:1504


This usually means there is an alignment error somewhere inside the
struct edge.

Maybe there is something incorrect in pool_alloc function?

The version is 1.14.0 (which was not selectable in the Version box).

Thanks in advance
Greetings
Comment 1 Uli Schlachter 2015-04-19 17:33:20 UTC
Could you check if commit 40201f4b1ab52c85922b2b7ae05dd862159a1aa0 fixes your issue?

commit 40201f4b1ab52c85922b2b7ae05dd862159a1aa0
Author: Uli Schlachter <psychon@znc.in>
Date:   Fri Dec 5 14:43:26 2014 +0100

    tor-scan-converter: Correctly align 64bit types
    
    On 32bit SPARC the scan converter was causing a SIGBUS due to an unaligned
    memory access while accessing an int64_t. This memory accessing was to struct
    quorem's rem member.
    
    This crash occurred because the tor-scan-converter contains its own
    implementation of a memory pool. This implementation only guarantees an
    alignment of sizeof(void *), which is less than what a 64 bit type requires on
    32bit platforms. This 4 byte alignment is guaranteed, because struct _pool_chunk
    (which is the struct that is used for managing free space) contains elements of
    that size and so the size of that struct is a multiple of this size as well.
    
    This problem was introduced with commit 03c3d4b7c15.
    
    To fix this problem, this commit introduces a int64_t member to struct
    _pool_chunk that marks the beginning of the free data space. Thanks to this, the
    compiler ensures proper alignment and sizeof(struct _pool_chunk) becomes a
    multiple of 8.
    
    However, previously the end of the struct marked the beginning of the data and
    sizeof() was used for correctly calculating offsets to the data section. So,
    just adding such a member would work, but would also waste some memory. To avoid
    this, this commit also changes the rest of the pool implementation to
    accommodate.
    
    Reported-by: Nicolas Setton <setton@adacore.com>
    Signed-off-by: Uli Schlachter <psychon@znc.in>
    Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Comment 2 Peter Spiess-Knafl 2015-04-21 20:08:39 UTC
It worked. Thank you.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.