[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Object corruption after calling an external shared object
- From: "jonsmirl@..." <jonsmirl@...>
- Date: Mon, 16 Jan 2012 15:53:32 -0500
2012/1/16 Ezequiel García <elezegarcia@gmail.com>:
> Hi,
>
> 2012/1/13, jonsmirl@gmail.com <jonsmirl@gmail.com>:
>> 2012/1/13 Ezequiel García <elezegarcia@gmail.com>:
>>> 2012/1/13, jonsmirl@gmail.com <jonsmirl@gmail.com>:
>>> Which examples are causing the segfault? (The smaller one)
>>
>> These examples all fail...
>>
>> cairo_test4oo.lua
>> cairo_test5.lua
>> cairo_test5oo.lua
>>
>
> I think you should:
> 1. post the complete segfault message
> 2. get the *smallest* example that cause the segfault. These examples are rather
> large.
I have a C program that triggers the fault now which eliminates all of
the lua pieces.
The segfault messages aren't useful, they occur after the memory has
been corrupted.
>
>>
>> ---> comment out the next line and it will work. It seems that
>> changing the font_face causes the corruption
>> cr:select_font_face("Sans", CAIRO.FONT_SLANT_NORMAL,
>> CAIRO.FONT_WEIGHT_NORMAL)
>
> This is odd. Is this happening on a sistematic basis?
> However, the other examples don't use this function so it is odd.
>
> Just for curiosity: having mention you are testing it in an arm
> embedded, what graphic backend
> are you using ?
Not using a backend. I either make PNGs or directly manipulate the
framebuffer without using DirectFB.
I'm been debugging this another day and I believe the problem is in
one of: cairo, fontconfig or ulibc. I'd like to identify a consistent
location in memory that is getting trashed so that I can use a
hardware write break point on it.
>
> Regards,
> Ezequiel.
>
--
Jon Smirl
jonsmirl@gmail.com