I really would not use the builtin cairo sources.
gdk dynamically links agianst cairo and you have static linked in the
library also.
I have no idea what the result of that is.
If you want to static link then you need to static link gdk pango etc etc.
Mike
On 8/22/06, Krzysztof Kowalczyk <[EMAIL PROTECTED]> wrote:
After applying linux build fixes patch () and slight modification to
FontDataGdk.cpp FontData::platformInit() to not use
cairo_scaled_font_text_extents() so that it can build against libcairo
1.0.4 I was able to build gdk version on my Ubuntu 6.05.
However, when I run gdklauncher, I immediately get a crash. I'm quite
perplexed because looking at sources this should really not happen. I
was wondering if someone hacking on gdk version also saw this problem
and knows a solution. I'm leaning towards some configuration issue
with my system.
Details of the crash:
Program received signal SIGSEGV, Segmentation fault.
QualifiedName (this=0xb78e026c, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL
PROTECTED]) at Shared.h:31
31 Shared.h: No such file or directory.
in Shared.h
(gdb) bt
#0 QualifiedName (this=0xb78e026c, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]) at Shared.h:31
#1 0xb741e603 in WebCore::HTMLNames::init () at
../../DerivedSources/WebCore/HTMLNames.cpp:72
#2 0xb74864fd in Frame (this=0x8078380, page=0x0, ownerElement=0x0)
at ../../page/Frame.cpp:158
#3 0xb772114a in FrameGdk (this=0x8078380, gdkdrawable=0x805fd20) at
../../platform/gdk/FrameGdk.cpp:99
#4 0x08048b69 in main ()
(gdb) p *this
$10 = {m_impl = 0x0}
(gdb) info reg
eax 0x0 0
ecx 0x1 1
edx 0xbfa96420 -1079417824
ebx 0xb789b0b0 -1215713104
esp 0xbfa96410 0xbfa96410
ebp 0xbfa96458 0xbfa96458
esi 0xb78e026c -1215430036
edi 0xbfa964a0 -1079417696
eip 0xb7603ec0 0xb7603ec0 <QualifiedName+94>
eflags 0x10282 66178
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) disass $eip-4 $eip+10
Dump of assembler code from 0xb7603ebc to 0xb7603eca:
0xb7603ebc <QualifiedName+90>: mov (%eax),%eax
0xb7603ebe <QualifiedName+92>: mov %eax,(%esi)
0xb7603ec0 <QualifiedName+94>: addl $0x1,(%eax)
0xb7603ec3 <QualifiedName+97>: lea 0xfffffff8(%ebp),%esp
0xb7603ec6 <QualifiedName+100>: pop %ebx
0xb7603ec7 <QualifiedName+101>: pop %esi
0xb7603ec8 <QualifiedName+102>: pop %ebp
0xb7603ec9 <QualifiedName+103>: ret
I speculate that this is the instruction that crashes (I can never
remember if eip points to the intstruction that generated the fault or
the one after it):
0xb7603ec0 <QualifiedName+94>: addl $0x1,(%eax)
because it tries to dereference memory at address 0.
It looks like it comes from void ref() { m_impl->ref(); } which
makes sense given that according to gdb m_impl is 0x0. What doesn't
make sense is that m_impl is 0x0.
It might be because QNAME_DEFAULT_CONSTRUCTOR is defined and somehow a
default constructor got called. BTW: it seems like
QualifiedName::ref() has a bug in this case and should have the same
protection as deref() i.e.
#ifdef QNAME_DEFAULT_CONSTRUCTOR
if (!m_impl)
return;
#endif
All this originates from the macro in HTMLNames.cpp:
#define INITIALIZE_TAG_GLOBAL(name) new ((void*)&name##Tag)
QualifiedName(nullAtom, name##TagString, xhtmlNS);
DOM_HTMLNAMES_FOR_EACH_TAG(INITIALIZE_TAG_GLOBAL)
Which makes stepping through the code in gdb pretty much impossible
i.e. I don't see what code is actually generated by gcc.
Any hint appreciated.
-- kjk
_______________________________________________
webkit-dev mailing list
webkit-dev@opendarwin.org
http://www.opendarwin.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@opendarwin.org
http://www.opendarwin.org/mailman/listinfo/webkit-dev
