Re: [webkit-dev] ASSERT crashes on arm platform

[Gustavo Chaves]

> The ASSERT macros are there to _cause_ the crash when something
> unexpected happens. If you're hitting an ASSERT you are probably doing
> something wrong in your code somewhere.

Yeah, that was clear. I was seeking for help because at least one of
them seemed unrelated to the port.

> It may also be the case that the ASSERT is wrong, or wrong specifically
> for your port, but that should be rare.

For now I'm not building with debug enabled, but soon I want to build
with another port, say, Qt, and check
the same sites with their launcher.

Thanks for answering! I'm new to webkit and I really appreciate its
performance :D

> See you,
>
> --
> Gustavo Noronha 
> GNOME contributor
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 
Gustavo Lima Chaves
Computer Engineer @
ProFUSION Embedded Systems
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ASSERT crashes on arm platform

[Gustavo Noronha]

On Tue, 2009-05-05 at 11:22 -0300, Gustavo Chaves wrote:
> Actually not true: my fault not having realised one of the builds had
> --enable-debug
> and the other hadn't. Is anyone maintaining that option, that is,
> tracking those asserts
> so they don't crash? One does not expect to fall on such crashes on
> debug mode...

The ASSERT macros are there to _cause_ the crash when something
unexpected happens. If you're hitting an ASSERT you are probably doing
something wrong in your code somewhere.

It may also be the case that the ASSERT is wrong, or wrong specifically
for your port, but that should be rare.

See you,

-- 
Gustavo Noronha 
GNOME contributor

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] ASSERT crashes on arm platform

[Gustavo Chaves]

> Hi, all.
>
> I'm yet another guy dealing with an arm box (set-top box), which has:
> - XScale3 processor
> - glibc 2.3.6
> - libstdc++ 6.0.3
> - all compiled with gcc 3.4.5
>
> I'm working with the efl port of webkit and I have two bugs which only
> happen on the arm box (never happened on
> the x86 same source build): two ASSERT macros are being triggered. One

Actually not true: my fault not having realised one of the builds had
--enable-debug
and the other hadn't. Is anyone maintaining that option, that is,
tracking those asserts
so they don't crash? One does not expect to fall on such crashes on
debug mode...
Right now I don't have the time to figure out what is wrong with them,
but I can help
when things calm down.

> is at WebCore/page/FrameView.cpp:1227
> (ASSERT(!m_isPainting)) and the other lies on
> WebCore/platform/KURL.cpp:320 (ASSERT(url == m_string)). This second
> one is triggered by some url forms (no trailing slash, for example).
> Having checked that code, I'm not sure *why*
> that ASSERT is there, so I'm asking for possible help by who knows it
> better. The other crash looks like a race
> condition but it is difficult to write a test case to always reproduce
> the bug. Below are backtraces for each of
> the problems cited.
>

Cheers.

-- 
Gustavo Lima Chaves
Computer Engineer @
ProFUSION Embedded Systems
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] ASSERT crashes on arm platform

[Gustavo Chaves]

Hi, all.

I'm yet another guy dealing with an arm box (set-top box), which has:
- XScale3 processor
- glibc 2.3.6
- libstdc++ 6.0.3
- all compiled with gcc 3.4.5

I'm working with the efl port of webkit and I have two bugs which only
happen on the arm box (never happened on
the x86 same source build): two ASSERT macros are being triggered. One
is at WebCore/page/FrameView.cpp:1227
(ASSERT(!m_isPainting)) and the other lies on
WebCore/platform/KURL.cpp:320 (ASSERT(url == m_string)). This second
one is triggered by some url forms (no trailing slash, for example).
Having checked that code, I'm not sure *why*
that ASSERT is there, so I'm asking for possible help by who knows it
better. The other crash looks like a race
condition but it is difficult to write a test case to always reproduce
the bug. Below are backtraces for each of
the problems cited.

Thanks in advance.

#0  0x4122e0a8 in KURL (this=0xbea13a2c, u...@0xbea13a28) at
WebCore/platform/KURL.cpp:320
#1  0x40c4a5f8 in EWebFrame::load (this=0x33288, uri=0xa0ba0
"http://www.google.com";) at WebKit/efl/Api/ewebframe.cpp:116
#2  0x40c4e754 in EWebView::load (this=0x30328, uri=0xa0ba0
"http://www.google.com";) at WebKit/efl/Api/ewebview.cpp:207
#3  0x40c53c8c in _callback_webview_load_url (data=0x30350) at
WebKit/efl/Api/ewebkit.cpp:147
#4  0x425ab924 in _ecore_idler_call () from
/l/p/tecsys/inst-root-285.webkit/usr/local/lib/libecore.so.0
#5  0x425ae7d0 in _ecore_main_loop_iterate_internal () from
/l/p/tecsys/inst-root-285.webkit/usr/local/lib/libecore.so.0
#6  0x425ae9a4 in ecore_main_loop_begin () from
/l/p/tecsys/inst-root-285.webkit/usr/local/lib/libecore.so.0
#7  0xa04c in main ()





#0  0x411d8af8 in WebCore::FrameView::paintContents (this=0x182930,
p=0xbef61e4c, re...@0xbef61e08)
at WebCore/page/FrameView.cpp:1227
#1  0x41240630 in WebCore::ScrollView::paint (this=0x182930,
context=0xbef61e4c, re...@0xbef61e8c)
at WebCore/platform/ScrollView.cpp:693
#2  0x40c4ac24 in EWebFrame::render (this=0x33288, cr=0x2400c8,
re...@0xbef61e8c) at WebKit/efl/Api/ewebframe.cpp:168
#3  0x40c508ac in EWebPage::paint (this=0x30948, cr=0x2400c8, rect=
{m_location = {m_x = 627, m_y = 187}, m_size = {m_width = 17,
m_height = 23}}) at WebKit/efl/Api/ewebpage.cpp:232
#4  0x40c45600 in RepaintQueue::process (this=0x30b60,
surface=0x30948, cr=0x2400c8)
at WebKit/efl/EvasSupport/eobject.cpp:114
#5  0x40c46078 in _eobject_recalculate (o=0x30970) at
WebKit/efl/EvasSupport/eobject.cpp:307
#6  0x425257a0 in evas_call_smarts_calculate () from
/l/p/tecsys/inst-root-285.webkit/usr/local/lib/libevas.so.0
#7  0x4253e3f0 in evas_render_updates_internal () from
/l/p/tecsys/inst-root-285.webkit/usr/local/lib/libevas.so.0
#8  0x414b2bf4 in WebCore::RenderThemeEfl::syncWidgetState
(this=0x424fa8d4, type=WebCore::TextField, stateMask=8)
at WebCore/platform/efl/RenderThemeEfl.cpp:75
#9  0x414b137c in WebCore::RenderThemeEfl::createWidgetImage
(this=0x424fa8d4, type=WebCore::TextField, stateMask=8,
i...@0xbef62174, re...@0xbef62068) at
WebCore/platform/efl/RenderThemeEfl.cpp:280
#10 0x414b1c98 in WebCore::RenderThemeEfl::paintTextField
(this=0x424fa8d4, o=0x261504, i...@0xbef62174, re...@0xbef62068)
at WebCore/platform/efl/RenderThemeEfl.cpp:391
#11 0x4143689c in WebCore::RenderTheme::paintBorderOnly
(this=0x424fa8d4, o=0x261504, paintin...@0xbef62174, r...@0xbef62068)
at WebCore/rendering/RenderTheme.cpp:307
#12 0x4136f154 in WebCore::RenderBox::paintBoxDecorations
(this=0x261504, paintin...@0xbef62174, tx=472, ty=101)
at WebCore/rendering/RenderBox.cpp:680
#13 0x413383d8 in WebCore::RenderBlock::paintObject (this=0x261504,
paintin...@0xbef62174, tx=472, ty=101)
at WebCore/rendering/RenderBlock.cpp:1752
#14 0x41337338 in WebCore::RenderBlock::paint (this=0x261504,
paintin...@0xbef62174, tx=472, ty=101)
at WebCore/rendering/RenderBlock.cpp:1603
#15 0x4142ff9c in WebCore::RenderTextControlSingleLine::paint
(this=0x261504, paintin...@0xbef62174, tx=469, ty=98)
at WebCore/rendering/RenderTextControlSingleLine.cpp:197
#16 0x41315d74 in WebCore::InlineBox::paint (this=0x3117f4,
paintin...@0xbef621c0, tx=469, ty=98)
at WebCore/rendering/InlineBox.cpp:150
#17 0x4131b2bc in WebCore::InlineFlowBox::paint (this=0x311834,
paintin...@0xbef622d4, tx=469, ty=98)
at WebCore/rendering/InlineFlowBox.cpp:669
#18 0x41450948 in WebCore::RootInlineBox::paint (this=0x311834,
paintin...@0xbef622d4, tx=469, ty=98)
at WebCore/rendering/RootInlineBox.cpp:184
#19 0x413c68ec in WebCore::RenderLineBoxList::paint (this=0x260e50,
renderer=0x260de4, paintin...@0xbef62750, tx=469, ty=98)
at WebCore/rendering/RenderLineBoxList.cpp:203
#20 0x41337bc4 in WebCore::RenderBlock::paintContents (this=0x260de4,
paintin...@0xbef62750, tx=469, ty=98)
at WebCore/rendering/RenderBlock.cpp:1689
#21 0x41338524 in WebCore::RenderBlock::paintObject (this=0x260de4,
paintin...@0xbef62750, tx=469, ty=98)