[webkit-dev] Announcing new port: EFL
Hi. I'm proud to announce a new WebKit port: to the Enlightenment Foundation Libraries (EFL). This port was made by ProFUSION on behalf of Samsung Electronics, which now wants to contribute it back upstream. It is based on the previous work by INdT, but most of WebKit/efl has been rewritten to fit better to the EFL architecture. The files that include INdT's work have their copyright listed accordingly. Some patches are already on the bugzilla, awaiting review: #35059, #35084 and #35087. There are more on their way. Regards, Leandro ProFUSION embedded systems signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] global new/delete operator in WebKit
Hi; Picking up and old thread I know... On Wed, Jan 13, 2010 at 7:19 PM, Darin Adler da...@apple.com wrote: Yong Li also asked about standard library functions calling new and delete, specifically STL. I believe we have been avoiding calling these functions in WebKit, but I may be mistaken. Recently I came across some memory corruption issues and turns out that WebKit uses std::stable_sort which uses the operator new(nothrow) . I am not sure if there is a useful replacement but its good to know about this. Regards, İsmail ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] global new/delete operator in WebKit
Hi Stephan; On Thu, Feb 18, 2010 at 5:30 PM, Stephan Assmus supersti...@gmx.de wrote: Hi, On 2010-02-18 at 15:59:35 [+0100], İsmail Dönmez ism...@namtrac.org wrote: Picking up and old thread I know... On Wed, Jan 13, 2010 at 7:19 PM, Darin Adler da...@apple.com wrote: Yong Li also asked about standard library functions calling new and delete, specifically STL. I believe we have been avoiding calling these functions in WebKit, but I may be mistaken. Recently I came across some memory corruption issues and turns out that WebKit uses std::stable_sort which uses the operator new(nothrow) . I am not sure if there is a useful replacement but its good to know about this. Can you elaborate on this? Were these the cause for your memory corruption? If yes, where and how did you solve it? For my own WinCE port I override new delete globally via a special memory pool. I override all 8 signatures of new delete so its supposed to work fine. But... std::stable_sort calls operator new(nothrow) which somehow does not pick up my replacement but it does use my delete replacement. So I end up deleting memory I didn't allocate which as expected crashes. I am still debugging why STL would not use my replacement function, but meanwhile beware about this :-) Regards, İsmail ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problems with using XPath functionality to query DOM
Your question is not about WebKit development, so it should be directed to webkit-help mailing list. I've answered below, but please choose a correct e-mail list in the future. Please note that linking directly to WebCore is most definitely unsupported and extremely fragile. One should always be using platform- specific WebKit APIs. On 17.02.2010, at 18:27, Steve Hanna wrote: 136 WebCore::XPathResult* xpr = doc-evaluate(query, dynamic_castWebCore::Node*(doc), NULL, The XPathResult object is destroyed at this point, so the rest of the code operates on freed memory. One needs to keep the reference in RefPtr. Also, you don't need dynamic_cast when downcasting - and we build WebCore with RTTI disabled anyway. RefPtrWebCore::XPathResult xpr = doc-evaluate(query, doc, 0, WebCore::XPathResult::UNORDERED_NODE_ITERATOR_TYPE, NULL, ec); - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] FontPlatformData, FontCache and HashMap
Hi all,
currently, I am investigating some weirdness with regards to
FontPlatformData and the FontCache which I see in my debugging output on
the Haiku port. I am not even 100% sure that what I see is a weirdness, but
at least I don't understand it and I was wondering if anyone could help me
shed some light into this.
So I understand these things:
1) SimpleFontData has a member m_platformData of type FontPlatformData,
which is always instantiated by passing it a const reference of another
FontPlatformData.
2) The FontCache maintains SimplaFontData instances in a HashMap, and looks
these up and compares them by using FontPlatformData objects as keys into
the map.
3) FontCache has a static empty FontPlatformData instance in
FontDataCacheKeyTraits:
static const FontPlatformData emptyValue()
{
DEFINE_STATIC_LOCAL(FontPlatformData, key, (0.f, false, false));
return key;
}
Don't yet know how this comes into play, but possibly it's of relevance.
My analysis is a bit awkward, since I cannot use a source level debugger on
Haiku, and I won't bore you with the embarrasing details of why. So I added
printf() statements in all my constructors of FontPlatformData, and printed
among other things the memory address of the FontPlatformData instance
(this). Also, I am printing this in a number of other places, operator=()
for example. The output I am getting is a little weird, since it shows that
operator=() is called on objects, for which no constructor has been called.
Basically, I've narrowed it down to SimpleFontData*
FontCache::getCachedFontData(const FontPlatformData* platformData) in
FontCache.cpp. In this method, a new SimpleFontData instance is to be
created and inserted into the HashMap. I will show you the output from the
program start. It printed which FontPlatformData instances have been
created up to Kill Thread (I let it drop into the debugger from the first
invokation of FontPlatformData::operator=()):
The first font is created:
getCachedFontPlatformData(0)
createFontPlatformData(const FontDescription)
0x18018660-FontPlatformData(const FontDescription(16.0, Myriad Pro))
0x18019bf0-FontPlatformDataPrivate()
created result: 0x18018660
getCachedFontPlatformData() - done: 0x18018660
Next, getCachedFontData() is called to insert a new SimpleFontData for this
FontDescription:
getCachedFontData(0x18018660)
Next comes the output from line 289 of FontCache.cpp:
pairSimpleFontData*, unsigned newValue(new SimpleFontData(*platformData),
1);
A new SimpleFontData object is created with it's m_fontData member at
address 0x2f4c6a8:
0x2f4c6a8-FontPlatformData(const FontPlatformData 0x18018660)
0x18019bf0-addRef()
new: 0x2f4c680
Next comes the call to HashMap::set(), which results in this output:
0x18018970-FontPlatformData(0.0, 0, 0)
This is probably the key created from HashMap::inlineAdd(). And next,
HashMap::set() invokes operator=() on the key (line 250) which gives this
output:
0x2ec8594 ((nil), 0.0, 0, 0) -operator=(0x18018660, 0x18019bf0)
nil is a pointer to FontPlatformDataPrivate, which is ok. But 0x2ec8594
should be the pointer to the FontPlatformData instance created in
inlineAdd().
How can I be doing something wrong there? Nothing happens in my constructor
for FontPlatformData() when the empty key values are used. Maybe the usage
of the HashMap is broken in FontCache, since it would seem that such a
low-level utility class as HashMap would not likely contain any bugs.
Could someone help me shed some light on this? Thanks a bunch for reading
this far!
Best regards,
-Stephan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] global new/delete operator in WebKit
On 18.02.2010, at 6:59, İsmail Dönmez wrote: Recently I came across some memory corruption issues and turns out that WebKit uses std::stable_sort which uses the operator new(nothrow) . I am not sure if there is a useful replacement but its good to know about this. We definitely need a replacement - another problematic place is JSArray::sort, which should be a stable sort, but isn't on platforms that don't provide mergesort. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] FontPlatformData, FontCache and HashMap
On 2010-02-18 at 18:43:08 [+0100], Stephan Assmus supersti...@gmx.de wrote:
Hi all,
currently, I am investigating some weirdness with regards to
FontPlatformData and the FontCache which I see in my debugging output on
the Haiku port. I am not even 100% sure that what I see is a weirdness, but
at least I don't understand it and I was wondering if anyone could help me
shed some light into this.
So I understand these things:
1) SimpleFontData has a member m_platformData of type FontPlatformData,
which is always instantiated by passing it a const reference of another
FontPlatformData.
2) The FontCache maintains SimplaFontData instances in a HashMap, and looks
these up and compares them by using FontPlatformData objects as keys into
the map.
3) FontCache has a static empty FontPlatformData instance in
FontDataCacheKeyTraits:
static const FontPlatformData emptyValue()
{
DEFINE_STATIC_LOCAL(FontPlatformData, key, (0.f, false, false));
return key;
}
Don't yet know how this comes into play, but possibly it's of relevance.
My analysis is a bit awkward, since I cannot use a source level debugger on
Haiku, and I won't bore you with the embarrasing details of why. So I added
printf() statements in all my constructors of FontPlatformData, and printed
among other things the memory address of the FontPlatformData instance
(this). Also, I am printing this in a number of other places, operator=()
for example. The output I am getting is a little weird, since it shows that
operator=() is called on objects, for which no constructor has been called.
Basically, I've narrowed it down to SimpleFontData*
FontCache::getCachedFontData(const FontPlatformData* platformData) in
FontCache.cpp. In this method, a new SimpleFontData instance is to be
created and inserted into the HashMap. I will show you the output from the
program start. It printed which FontPlatformData instances have been
created up to Kill Thread (I let it drop into the debugger from the first
invokation of FontPlatformData::operator=()):
The first font is created:
getCachedFontPlatformData(0)
createFontPlatformData(const FontDescription)
0x18018660-FontPlatformData(const FontDescription(16.0, Myriad Pro))
0x18019bf0-FontPlatformDataPrivate()
created result: 0x18018660
getCachedFontPlatformData() - done: 0x18018660
Next, getCachedFontData() is called to insert a new SimpleFontData for this
FontDescription:
getCachedFontData(0x18018660)
Next comes the output from line 289 of FontCache.cpp:
pairSimpleFontData*, unsigned newValue(new SimpleFontData(*platformData),
1);
A new SimpleFontData object is created with it's m_fontData member at
address 0x2f4c6a8:
0x2f4c6a8-FontPlatformData(const FontPlatformData 0x18018660)
0x18019bf0-addRef()
new: 0x2f4c680
Next comes the call to HashMap::set(), which results in this output:
0x18018970-FontPlatformData(0.0, 0, 0)
This is probably the key created from HashMap::inlineAdd(). And next,
HashMap::set() invokes operator=() on the key (line 250) which gives this
output:
0x2ec8594 ((nil), 0.0, 0, 0) -operator=(0x18018660, 0x18019bf0)
nil is a pointer to FontPlatformDataPrivate, which is ok. But 0x2ec8594
should be the pointer to the FontPlatformData instance created in
inlineAdd().
How can I be doing something wrong there? Nothing happens in my constructor
for FontPlatformData() when the empty key values are used. Maybe the usage
of the HashMap is broken in FontCache, since it would seem that such a
low-level utility class as HashMap would not likely contain any bugs.
Ok, I've finally figured it out. FontCache.cpp defines the following for use
in the HashMap:
struct FontDataCacheKeyTraits : WTF::GenericHashTraitsFontPlatformData {
static const bool emptyValueIsZero = true;
static const bool needsDestruction = true;
static const FontPlatformData emptyValue()
{
DEFINE_STATIC_LOCAL(FontPlatformData, key, (0.f, false, false));
return key;
}
static void constructDeletedValue(FontPlatformData slot)
{
new (slot) FontPlatformData(HashTableDeletedValue);
}
static bool isDeletedValue(const FontPlatformData value)
{
return value.isHashTableDeletedValue();
}
};
The emptyValueIsZero means the HashTable implementation will not call
constructors for new slots. IMHO, this is a dangerous assumption, since the
porters may not realize this and that this actually works is completely
implementation specific.
Best regards,
-Stephan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
