[Buildroot] WebKit - Random-crashes ?

[Buildroot] WebKit - Random-crashes ?

[Vellemans, Noel]

Hi,

>>>> Noel Vellemans
>>>>>When I do compile Webkit-1.2.7 (that was working before) with 
>>>>> the same set of libraries/uclibc.... (as I use to build 1.6.3
now), I 
>>>>> do get 'RANDOM'-crashes as well.

>>Arnout Vandecappelle
>> This probably means that Webkit isn't the problem, but one of the
many libraries it 
>>depends upon is.
>>
>> Ideally, you should revert everything to the working situation, and
then upgrade the >>libraries one by one to find the one that is causing
the problem.  Looking at the 
>>backtraces, if must be one of gdk, glib, or uClibc.


Finally got 'something' running, that is not crashing all the time.
What Did I do?
A) Reverted back to older-WebKit 1.2.7. : DID NOT HELP (i.o.w
WebKit/GtkLauncher still crashes 'random') 
A) Reverted back to Uclibc 0.9.32.x     : DID NOT HELP. 
B) Reverted back to glib-2.28.8         : DID NOT HELP.
C) reverted to an older version of GTK (2.24.4): DID NOT HELP.
D) Reverted back to libsoup-2.32.2 (had to remove glib-networking
depends): SEEMS to be STABLE!
{I'll RE-test the complete build overnight}

.. 
Compiling WebKit (and his depends) takes some time, even on
fast-build-machine (some hours in my case).
In order to be sure that everything is recompiled/linked correctly, I
always wipe the complete 'output' directory.
Is there a faster way to do this?
{if I do not wipe the output directory I always have leftovers (in /lib,
/usr/lib ..... ) ... from previous compile cycle(s).}



>>Arnout Vandecappelle
>> A segmentation fault in free() generally indicates either a double
free or freeing 
>>unallocated memory (e.g. a stack variable).  valgrind may help to
pinpoint the problem.

I run Gtklauncher in Val grind as suggested, but I get a Lot of
'console'-output from everywhere. 
For example.... "== Invalid write of size 4" and/or "Address 0x97b6e14
is not stack'd, malloc'd or (recently) free'd" 
Don't know exactly, how valuable this output is ( i.o.w. did not look
into the details yet...)



Regards,
Noel



==1311== Invalid write of size 4
==1311==    at 0x73B269C: _pixman_lookup_composite_function
(pixman-utils.c:135)
==1311==    by 0x737054B: pixman_image_composite32 (pixman.c:682)
==1311==    by 0x595C6BB: _composite_glyphs (cairo-image-surface.c:4002)
==1311==    by 0x595E88B: _clip_and_composite
(cairo-image-surface.c:2316)
==1311==    by 0x595EBCF: _cairo_image_surface_glyphs
(cairo-image-surface.c:4062)
==1311==    by 0x597C587: _cairo_surface_show_text_glyphs
(cairo-surface.c:2640)
==1311==    by 0x595928F: _cairo_gstate_show_text_glyphs
(cairo-gstate.c:1981)
==1311==    by 0x59509C3: cairo_show_glyphs (cairo.c:3509)
==1311==    by 0x4EAAF5B:
WebCore::Font::drawGlyphs(WebCore::GraphicsContext*,
WebCore::SimpleFontData const*, WebCore::GlyphBuffer const&, int, int,
WebCore::FloatPoint const&) const (FontCairo.cpp:108)
==1311==    by 0x4C74ED3:
WebCore::Font::drawGlyphBuffer(WebCore::GraphicsContext*,
WebCore::GlyphBuffer const&, WebCore::TextRun const&,
WebCore::FloatPoint const&) const (FontFastPath.cpp:314)
==1311==    by 0x4C7504F:
WebCore::Font::drawSimpleText(WebCore::GraphicsContext*,
WebCore::TextRun const&, WebCore::FloatPoint const&, int, int) const
(FontFastPath.cpp:287)
==1311==    by 0x4C7A1BB:
WebCore::GraphicsContext::drawText(WebCore::Font const&,
WebCore::TextRun const&, WebCore::IntPoint const&, int, int)
(GraphicsContext.cpp:337)
==1311==  Address 0x97b6e14 is not stack'd, malloc'd or (recently)
free'd
==1311==
==1311== Invalid write of size 4
==1311==    at 0x73B26AC: _pixman_lookup_composite_function
(pixman-utils.c:136)
==1311==    by 0x737054B: pixman_image_composite32 (pixman.c:682)
==1311==    by 0x595C6BB: _composite_glyphs (cairo-image-surface.c:4002)
==1311==    by 0x595E88B: _clip_and_composite
(cairo-image-surface.c:2316)
==1311==    by 0x595EBCF: _cairo_image_surface_glyphs
(cairo-image-surface.c:4062)
==1311==    by 0x597C587: _cairo_surface_show_text_glyphs
(cairo-surface.c:2640)
==1311==    by 0x595928F: _cairo_gstate_show_text_glyphs
(cairo-gstate.c:1981)
==1311==    by 0x59509C3: cairo_show_glyphs (cairo.c:3509)
==1311==    by 0x4EAAF5B:
WebCore::Font::drawGlyphs(WebCore::GraphicsContext*,
WebCore::SimpleFontData const*, WebCore::GlyphBuffer const&, int, int,
WebCore::FloatPoint const&) const (FontCairo.cpp:108)
==1311==    by 0x4C74ED3:
WebCore::Font::drawGlyphBuffer(WebCore::GraphicsContext*,
WebCore::GlyphBuffer const&, WebCore::TextRun const&,
WebCore::FloatPoint const&) const (FontFastPath.cpp:314)
==1311==    by 0x4C7504F:
WebCore::Font::drawSimpleText(WebCore::GraphicsContext*,
WebCore::TextRun const&, WebCore::FloatPoint const&, int, int) const
(FontFastPath.cpp:287)
==1311==    by 0x4C7A1BB:
WebCore::GraphicsContext::drawText(WebCore::Font const&,
WebCore::TextRun const&, WebCore::IntPoint const&, int, int)
(GraphicsContext.cpp:337)
==1311==  Address 0x97b6e18 is not stack'd, malloc'd or (recently)
free'd
==1311==
==1311== Invalid write of size 4
==1311==    at 0x73B26BC: _pixman_lookup_composite_function
(pixman-utils.c:137)
==1311==    by 0x737054B: pixman_image_composite32 (pixman.c:682)
==1311==    by 0x595C6BB: _composite_glyphs (cairo-image-surface.c:4002)

[Buildroot] WebKit - Random-crashes ?

[Thomas Petazzoni]

Le Tue, 20 Mar 2012 10:50:13 +0100,
"Vellemans, Noel" <Noel.Vellemans@visionBMS.com> a ?crit :

> Finally got 'something' running, that is not crashing all the time.
> What Did I do?
> A) Reverted back to older-WebKit 1.2.7. : DID NOT HELP (i.o.w
> WebKit/GtkLauncher still crashes 'random') 
> A) Reverted back to Uclibc 0.9.32.x     : DID NOT HELP. 
> B) Reverted back to glib-2.28.8         : DID NOT HELP.
> C) reverted to an older version of GTK (2.24.4): DID NOT HELP.
> D) Reverted back to libsoup-2.32.2 (had to remove glib-networking
> depends): SEEMS to be STABLE!

Ah, interesting. Then maybe contacting the libsoup developers will be a
good idea.

Another option is to try to upgrade libsoup. We have 2.36.1 in
Buildroot, the latest one is
http://ftp.gnome.org/pub/GNOME/sources/libsoup/2.37/libsoup-2.37.92.tar.xz.

> Compiling WebKit (and his depends) takes some time, even on
> fast-build-machine (some hours in my case).
> In order to be sure that everything is recompiled/linked correctly, I
> always wipe the complete 'output' directory.
> Is there a faster way to do this?
> {if I do not wipe the output directory I always have leftovers (in /lib,
> /usr/lib ..... ) ... from previous compile cycle(s).}

If you want to just rebuild *one* component, you can do:

	rm -rf output/build/<component>-<version>

and do 'make'. But note that it doesn't remove the previous
installation from the target directory, the installation of the new
component version will overwrite the old one, unless the installed
files are different, of course.

Another way of speeding up the build is to use an external toolchain if
you're not already using. You can also enable the ccache feature (be
sure to have the latest ccache fixes, otherwise ccache is basically
unused).

> I run Gtklauncher in Val grind as suggested, but I get a Lot of
> 'console'-output from everywhere. 
> For example.... "== Invalid write of size 4" and/or "Address 0x97b6e14
> is not stack'd, malloc'd or (recently) free'd" 
> Don't know exactly, how valuable this output is ( i.o.w. did not look
> into the details yet...)

valgrind is a big, big hammer, and for any given large software stack,
the number of errors is so huge that it's difficult to find out what's
going on.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] WebKit - Random-crashes ?

[Sagaert Johan]

 
Hi

Libsoup again ....
Hmm remember a few weeks ago a got a problem to with libsoup and the networking used from libglib2

The issue i had was :
 
Run a function from main() - > function works
Run the same function from a thread (either pthread or gthread) functions failed : could not connect..
I traced it down to gsocket.c and then gave up searching...,i have a target date to get the soft ready.

The socket connect() returned with -1 but errno did not contain the error...
If i had set errno=1234 BEFORE the connect, then after the connect() failed it still contained 1234 ...
In reality errno should of been set to EINPROGRESS (115)...
Strange things that i could not explain...

Johan

-----Oorspronkelijk bericht-----
Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens Thomas Petazzoni
Verzonden: dinsdag 20 maart 2012 11:18
Aan: buildroot at busybox.net
Onderwerp: Re: [Buildroot] WebKit - Random-crashes ?

Le Tue, 20 Mar 2012 10:50:13 +0100,
"Vellemans, Noel" <Noel.Vellemans@visionBMS.com> a ?crit :

> Finally got 'something' running, that is not crashing all the time.
> What Did I do?
> A) Reverted back to older-WebKit 1.2.7. : DID NOT HELP (i.o.w 
> WebKit/GtkLauncher still crashes 'random')
> A) Reverted back to Uclibc 0.9.32.x     : DID NOT HELP. 
> B) Reverted back to glib-2.28.8         : DID NOT HELP.
> C) reverted to an older version of GTK (2.24.4): DID NOT HELP.
> D) Reverted back to libsoup-2.32.2 (had to remove glib-networking
> depends): SEEMS to be STABLE!

Ah, interesting. Then maybe contacting the libsoup developers will be a good idea.

Another option is to try to upgrade libsoup. We have 2.36.1 in Buildroot, the latest one is
http://ftp.gnome.org/pub/GNOME/sources/libsoup/2.37/libsoup-2.37.92.tar.xz.

> Compiling WebKit (and his depends) takes some time, even on 
> fast-build-machine (some hours in my case).
> In order to be sure that everything is recompiled/linked correctly, I 
> always wipe the complete 'output' directory.
> Is there a faster way to do this?
> {if I do not wipe the output directory I always have leftovers (in 
> /lib, /usr/lib ..... ) ... from previous compile cycle(s).}

If you want to just rebuild *one* component, you can do:

	rm -rf output/build/<component>-<version>

and do 'make'. But note that it doesn't remove the previous installation from the target directory, the installation of the new
component version will overwrite the old one, unless the installed files are different, of course.

Another way of speeding up the build is to use an external toolchain if you're not already using. You can also enable the ccache
feature (be sure to have the latest ccache fixes, otherwise ccache is basically unused).

> I run Gtklauncher in Val grind as suggested, but I get a Lot of 
> 'console'-output from everywhere.
> For example.... "== Invalid write of size 4" and/or "Address 0x97b6e14 
> is not stack'd, malloc'd or (recently) free'd"
> Don't know exactly, how valuable this output is ( i.o.w. did not look 
> into the details yet...)

valgrind is a big, big hammer, and for any given large software stack, the number of errors is so huge that it's difficult to find
out what's going on.

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] WebKit - Random-crashes ?

[Will Wagner]

On 20/03/2012 12:48, Sagaert Johan wrote:
>
> Hi
>
> Libsoup again ....
> Hmm remember a few weeks ago a got a problem to with libsoup and the networking used from libglib2
>
> The issue i had was :
>
> Run a function from main() ->  function works
> Run the same function from a thread (either pthread or gthread) functions failed : could not connect..
> I traced it down to gsocket.c and then gave up searching...,i have a target date to get the soft ready.
>
> The socket connect() returned with -1 but errno did not contain the error...
> If i had set errno=1234 BEFORE the connect, then after the connect() failed it still contained 1234 ...
> In reality errno should of been set to EINPROGRESS (115)...
> Strange things that i could not explain...

Hi Johan,

This sounds a lot like a linuxthreads errno bug in uClibc. There is an 
open bug report in uClibc somewhere on the issue. If you built your 
toolchain using buildroot then a patch should have been applied 
(uClibc-0.9.32-linuxthreads-errno-fix.patch) but if you built it using 
crosstools-ng then this issue will remain.

Regards
Will

>
> Johan
>
> -----Oorspronkelijk bericht-----
> Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens Thomas Petazzoni
> Verzonden: dinsdag 20 maart 2012 11:18
> Aan: buildroot at busybox.net
> Onderwerp: Re: [Buildroot] WebKit - Random-crashes ?
>
> Le Tue, 20 Mar 2012 10:50:13 +0100,
> "Vellemans, Noel"<Noel.Vellemans@visionBMS.com>  a ?crit :
>
>> Finally got 'something' running, that is not crashing all the time.
>> What Did I do?
>> A) Reverted back to older-WebKit 1.2.7. : DID NOT HELP (i.o.w
>> WebKit/GtkLauncher still crashes 'random')
>> A) Reverted back to Uclibc 0.9.32.x     : DID NOT HELP.
>> B) Reverted back to glib-2.28.8         : DID NOT HELP.
>> C) reverted to an older version of GTK (2.24.4): DID NOT HELP.
>> D) Reverted back to libsoup-2.32.2 (had to remove glib-networking
>> depends): SEEMS to be STABLE!
>
> Ah, interesting. Then maybe contacting the libsoup developers will be a good idea.
>
> Another option is to try to upgrade libsoup. We have 2.36.1 in Buildroot, the latest one is
> http://ftp.gnome.org/pub/GNOME/sources/libsoup/2.37/libsoup-2.37.92.tar.xz.
>
>> Compiling WebKit (and his depends) takes some time, even on
>> fast-build-machine (some hours in my case).
>> In order to be sure that everything is recompiled/linked correctly, I
>> always wipe the complete 'output' directory.
>> Is there a faster way to do this?
>> {if I do not wipe the output directory I always have leftovers (in
>> /lib, /usr/lib ..... ) ... from previous compile cycle(s).}
>
> If you want to just rebuild *one* component, you can do:
>
> 	rm -rf output/build/<component>-<version>
>
> and do 'make'. But note that it doesn't remove the previous installation from the target directory, the installation of the new
> component version will overwrite the old one, unless the installed files are different, of course.
>
> Another way of speeding up the build is to use an external toolchain if you're not already using. You can also enable the ccache
> feature (be sure to have the latest ccache fixes, otherwise ccache is basically unused).
>
>> I run Gtklauncher in Val grind as suggested, but I get a Lot of
>> 'console'-output from everywhere.
>> For example.... "== Invalid write of size 4" and/or "Address 0x97b6e14
>> is not stack'd, malloc'd or (recently) free'd"
>> Don't know exactly, how valuable this output is ( i.o.w. did not look
>> into the details yet...)
>
> valgrind is a big, big hammer, and for any given large software stack, the number of errors is so huge that it's difficult to find
> out what's going on.
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot


-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] WebKit - Random-crashes ?

[Sagaert Johan]

 
Hi Will ;

Good to know, i was using uClibc 0.9.33 so i think it needs to be patched too.

Johan

-----Oorspronkelijk bericht-----
Van: Will Wagner [mailto:will_wagner at carallon.com] 
Verzonden: dinsdag 20 maart 2012 13:56
Aan: Sagaert Johan
CC: 'Thomas Petazzoni'; buildroot at busybox.net; 'Noel Vellemans'
Onderwerp: Re: [Buildroot] WebKit - Random-crashes ?

On 20/03/2012 12:48, Sagaert Johan wrote:
>
> Hi
>
> Libsoup again ....
> Hmm remember a few weeks ago a got a problem to with libsoup and the 
> networking used from libglib2
>
> The issue i had was :
>
> Run a function from main() ->  function works Run the same function 
> from a thread (either pthread or gthread) functions failed : could not connect..
> I traced it down to gsocket.c and then gave up searching...,i have a target date to get the soft ready.
>
> The socket connect() returned with -1 but errno did not contain the error...
> If i had set errno=1234 BEFORE the connect, then after the connect() failed it still contained 1234 ...
> In reality errno should of been set to EINPROGRESS (115)...
> Strange things that i could not explain...

Hi Johan,

This sounds a lot like a linuxthreads errno bug in uClibc. There is an open bug report in uClibc somewhere on the issue. If you
built your toolchain using buildroot then a patch should have been applied
(uClibc-0.9.32-linuxthreads-errno-fix.patch) but if you built it using crosstools-ng then this issue will remain.

Regards
Will

>
> Johan
>
> -----Oorspronkelijk bericht-----
> Van: buildroot-bounces at busybox.net 
> [mailto:buildroot-bounces at busybox.net] Namens Thomas Petazzoni
> Verzonden: dinsdag 20 maart 2012 11:18
> Aan: buildroot at busybox.net
> Onderwerp: Re: [Buildroot] WebKit - Random-crashes ?
>
> Le Tue, 20 Mar 2012 10:50:13 +0100,
> "Vellemans, Noel"<Noel.Vellemans@visionBMS.com>  a ?crit :
>
>> Finally got 'something' running, that is not crashing all the time.
>> What Did I do?
>> A) Reverted back to older-WebKit 1.2.7. : DID NOT HELP (i.o.w 
>> WebKit/GtkLauncher still crashes 'random')
>> A) Reverted back to Uclibc 0.9.32.x     : DID NOT HELP.
>> B) Reverted back to glib-2.28.8         : DID NOT HELP.
>> C) reverted to an older version of GTK (2.24.4): DID NOT HELP.
>> D) Reverted back to libsoup-2.32.2 (had to remove glib-networking
>> depends): SEEMS to be STABLE!
>
> Ah, interesting. Then maybe contacting the libsoup developers will be a good idea.
>
> Another option is to try to upgrade libsoup. We have 2.36.1 in 
> Buildroot, the latest one is http://ftp.gnome.org/pub/GNOME/sources/libsoup/2.37/libsoup-2.37.92.tar.xz.
>
>> Compiling WebKit (and his depends) takes some time, even on 
>> fast-build-machine (some hours in my case).
>> In order to be sure that everything is recompiled/linked correctly, I 
>> always wipe the complete 'output' directory.
>> Is there a faster way to do this?
>> {if I do not wipe the output directory I always have leftovers (in 
>> /lib, /usr/lib ..... ) ... from previous compile cycle(s).}
>
> If you want to just rebuild *one* component, you can do:
>
> 	rm -rf output/build/<component>-<version>
>
> and do 'make'. But note that it doesn't remove the previous 
> installation from the target directory, the installation of the new component version will overwrite the old one, unless the
installed files are different, of course.
>
> Another way of speeding up the build is to use an external toolchain 
> if you're not already using. You can also enable the ccache feature (be sure to have the latest ccache fixes, otherwise ccache is
basically unused).
>
>> I run Gtklauncher in Val grind as suggested, but I get a Lot of 
>> 'console'-output from everywhere.
>> For example.... "== Invalid write of size 4" and/or "Address 
>> 0x97b6e14 is not stack'd, malloc'd or (recently) free'd"
>> Don't know exactly, how valuable this output is ( i.o.w. did not look 
>> into the details yet...)
>
> valgrind is a big, big hammer, and for any given large software stack, 
> the number of errors is so huge that it's difficult to find out what's going on.
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot


--
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] WebKit - Random-crashes ?

[Peter Korsgaard]

>>>>> "Sagaert" == Sagaert Johan <sagaert.johan@skynet.be> writes:

 Sagaert> Hi Will ;

 Sagaert> Good to know, i was using uClibc 0.9.33 so i think it needs to
 Sagaert> be patched too.

Any specific reason why you aren't using NPTL instead of linuxthreads?

-- 
Bye, Peter Korsgaard

[Buildroot] WebKit - Random-crashes ?

[Vellemans, Noel]

<< Sorry re-post... Forgot the subject >>

 
Hi all, 
 
I'm struggling some day's now to get Webkit 1.6.3 (and even some later
versions 1.7.xx.xx ) running on Arm Cortex-A8 (build with GCC 4.5.x, and
uclibc0.9.33 )

Compiling is not a problem, this works (with some patches, depending on
the version of weskit I build I build.)


BUT: I'm having random crashes (when run the GtkLauncher on the target),
that I can not explain, or find where it goes wrong.

It must be in one of the libraries, but because I do not have any
'repetitive' core-dumps, it is hard to figure out what is going on, when
looking at these core dumps. 

I guess some basic-stuff (like fore example, locking.. or whatever...
malloc/free... troubles) that is not working, it is to strange what
happens, in  these core-dumps i never see somthing that is pointing to
the same crash-reason.
 

NOTE: When I do compile Weskit-1.2.7 (that was working before) with the
same set of libraries/uclibc.... (as I use to build 1.6.3 now), I do get
'RANDOM'-crashes as well.

I've included some core-dumps trace-back's (hope this is not to big for
the mailing-list) maybe someone gets a idea where I can take a look at.

Regards, and thanks.
Noel



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash1.txt
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120316/05d46b09/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash2.txt
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120316/05d46b09/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash3.txt
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120316/05d46b09/attachment-0005.txt>