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

2009-05-07 Thread 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 g...@gnome.org
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

2009-05-05 Thread 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

2009-04-30 Thread 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)
at