Re: [webkit-dev] Terminate handler for WebKit

[Michael Catanzaro]

On Fri, 2016-09-09 at 11:03 -0700, JF Bastien wrote:
>    - The state of the stack when std::terminate is called is
> implementation
>    defined (it could be unwound, unwound partially, or not unwound at
> all).

Hi, I think it's very unlikely to ever be unwound because we compile
with -fno-exceptions?

>    - std::terminate can be called from atexit or at_quick_exit which
> means
>    that global state can be partially broken.

In fact, that's exactly what's occurring in the crash that prompted me
to look into this.

>    - CRASH sometimes behaves in a manner which will cause signals to
> be
>    generated, and installSignalHandlersForFatalErrors registers
> signal
>    handlers (which sometimes calls dumpBacktraceSignalHandler which
> then calls
>    exit, leading us back to atexit).

Hm, installSignalHandlersForFatalErrors is only called
from WTFInstallReportBacktraceOnCrashHook, which is not called from
anywhere on any port, so this can't happen.

Anyone know why we have these unused functions? Are they there to be
used in modified debug builds, or should they be removed?

> The chance for undefined behavior, weirdly circular call graphs,
> exploitable behavior, or all three, seems pretty high here and very
> dependent on configuration at compile-time.

Maybe it makes sense to do this only in debug builds? I agree that
playing with undefined behavior doesn't seem wise, but in practice it
worked very well to get a backtrace for a bug that would otherwise be
difficult to debug.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminate handler for WebKit

[Michael Catanzaro]

On Fri, 2016-09-09 at 10:47 -0700, Anders Carlsson wrote:
> On macOS and iOS, we already get this by setting
> NSApplicationCrashOnExceptions in our initialize function.
> 
> - Anders

OK, so we'd have to do it in ChildProcess::platformInitialize to not
disturb you then.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Terminate handler for WebKit

[Anders Carlsson]

On macOS and iOS, we already get this by setting NSApplicationCrashOnExceptions 
in our initialize function.

- Anders

> On Sep 9, 2016, at 10:14 AM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> The GTK+ port currently has an interesting web process crash on exit:
> 
> pure virtual method called
> terminate called without an active exception
> 
> I found the easiest way to debug it was to rebuild with a terminate
> handler set:
> 
> std::set_terminate([] {
> CRASH();
> });
> 
> Even if such issues are very rare, I think it makes sense to set this
> up always, since a simple backtrace is a lot better than nothing in
> such cases. Are there any objections to always setting this terminate
> handler? For my debugging today, I put it in
> WebKit::ChildProcess::initialize, which seems like a decent place, but
> maybe not the best place. Are there any other suggestions for where to
> put this code? I presume this would be desired for all ports, but we
> could certainly do it somewhere platform-specific if that's not the
> case.
> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Terminate handler for WebKit

[Michael Catanzaro]

Hi,

The GTK+ port currently has an interesting web process crash on exit:

pure virtual method called
terminate called without an active exception

I found the easiest way to debug it was to rebuild with a terminate
handler set:

    std::set_terminate([] {
CRASH();
});

Even if such issues are very rare, I think it makes sense to set this
up always, since a simple backtrace is a lot better than nothing in
such cases. Are there any objections to always setting this terminate
handler? For my debugging today, I put it in
WebKit::ChildProcess::initialize, which seems like a decent place, but
maybe not the best place. Are there any other suggestions for where to
put this code? I presume this would be desired for all ports, but we
could certainly do it somewhere platform-specific if that's not the
case.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Point within WebKit API to extract Bitmaps

[Konstantin Tokarev]

09.09.2016, 17:46, "Mark Gilbert" :
> Hi Folks
>
> We have code which extracts RGB+A bitmaps from WebKit pages in real time. 
> Currently we do this via an OSX WebKit View in a window and by requesting the 
> bitmap through the OSX View mechanism (not directly from WebKit). It works 
> well and we get clean RGB+A in real time from the WebKit structure (usually..)
>
> However, we are finding that this approach does not always give us the 
> *performance* that we need, particularly where we have things like deep 
> opacity changes (eg fading things on and off). We have to disable some of the 
> 3d acceleration stuff in the WebKit view to ensure we continue to see changes 
> on the CPU side (otherwise the change happens on the GPU and we only see the 
> completed transition at the CPU side)
>
> I have seen other systems which are more deeply knitted into the guts of 
> WebKit which have better performance and I wondered if any WebKit experts 
> here could tell me where in the API of webkit I should look to pull out 
> bitmaps repeatedly (eg 25 FPS)
>
> I am reasonably familiar with the overall components of WebKit, but the 
> render layer / context arrangement is fairly complicated to unpick, I 
> understand that QT has a call something like:
> QWebElement::render(QPainter*, QRect const&) (in QtWebKit)
>
> and this may be doing approximately what I want, but I dont want to use QT

For what reason?

>, so I need to understand which WebKit calls this QWebElement::render is 
>digging into.

Basically, it calls FrameView::paintContents(), for more details look at the 
code of QWebElement::render():

https://github.com/annulen/webkit/blob/qtwebkit-stable/Source/WebKit/qt/Api/qwebelement.cpp#L1467

>
> Any ideas ?
>
> Thanks
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Point within WebKit API to extract Bitmaps

[Mark Gilbert]

Hi Folks

We have code which extracts RGB+A bitmaps from WebKit pages in real time.  
Currently we do this via an OSX WebKit View in a window and by requesting the 
bitmap through the OSX View mechanism (not directly from WebKit).  It works 
well and we get clean RGB+A in real time from the WebKit structure (usually..)

However, we are finding that this approach does not always give us the 
*performance* that we need, particularly where we have things like deep opacity 
changes (eg fading things on and off). We have to disable some of the 3d 
acceleration stuff in the WebKit view to ensure we continue to see changes on 
the CPU side (otherwise the change happens on the GPU and we only see the 
completed transition at the CPU side)

I have seen other systems which are more deeply knitted into the guts of WebKit 
which have better performance and I wondered if any WebKit experts here could 
tell me where in the API of webkit I should look to pull out bitmaps repeatedly 
(eg 25 FPS)

I am reasonably familiar with the overall components of WebKit, but the render 
layer / context  arrangement is fairly complicated to unpick, I understand that 
QT has a call something like:
QWebElement::render(QPainter*, QRect const&)  (in QtWebKit)

and this may be doing approximately what I want, but I dont want to use QT, so 
I need to understand which WebKit calls this  QWebElement::render is digging 
into.

Any ideas ?

Thanks


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

Re: [webkit-dev] Terminology for giving up ownership: take, release, move

[Daniel Olegovich Lazarenko]

>> "Pure OOP style is always the right way"
Sorry, that's a typo, I meant "not always" of course. The examples clarify
that.

My point was that "release", "take" and "move" have well-established and
different meanings (with connotations that may or may not be logical
without the same background):
* release will free the memory if ref_count = 0 (Obj-C/CF on Mac/iOS)
* move just moves the ownership without freeing (C++)
* take removes and item from the collection and returns it (the ownership
is implicitly passed as well) (Java, C#, but not only). So map.take() means
that I still need that object most likely, and map.remove() means that :
feel free to throw the object to trash.
That are connotations I've seen in my practice.

On Tue, Sep 6, 2016 at 6:14 PM, Alfonso Guerra 
wrote:

>
>
> On Tue, Sep 6, 2016 at 4:29 AM, Daniel Olegovich Lazarenko <
> dani...@opera.com> wrote:
>
> ..
>
>
>> * "take" - a typical name for collections like a blocking queue, heap and
>> some others (usually ordered). If it's a collection's method, it's
>> logically expected to return an item. The key distinction between
>> fred.takeCandy() and say bowl.takeCandy() is that bowl is passive.
>>
>
> That doesn't make sense to me. Why would the object "bowl" be passive, but
> not "fred"?
>
> We treat bowl as a passive bag of data, and expect others to take from it.
>>
>
> I see. Like an actual bowl in the real world?
>
>
>> It's pretty easy to understand and remember, it makes intention more
>> clear than say "bowl.removeCandy()".
>>
>
> Not to me. When I read or write object-oriented code, I think of it as
> sending messages of what I want done to the object. I see the object as
> being an intermediator performing actions on behalf of the caller.
> Containers and collections are classes that group a set of functions the
> caller needs done, so it's more convenient to view them as being a
> mediator, if you will, for the caller.
>
> I think trying to map real-world behaviors into object interfaces is
> trying too hard to mirror the real world. I see it as imposing additional
> cognitive load on comprehension by requiring me to remember if it's passive
> or not. In fact, if it's passive that would violate the OOP and real-world
> paradigms: why would I be sending it a message?
>
> Especially in this day and age of smart appliances and IoT I think it's
> more consistent to think of the bowl as a "smart" bowl that responds to my
> messages. "Give me all the green candy", "sort candy by size", etc.
>
>
>> Pure OOP style is always the right way when it comes to readability. A
>> good example mentioned by Stroustrup once that it should be sqrt(5), not
>> 5.sqrt().
>>
>
> Do you have a link for that? The closest thing I see to that example (
> https://isocpp.org/blog/2014/12/myths-2) is demonstrating the exact
> opposite, that a non-OOP solution provides better performance by
> eliminating the dereferencing of a pointer.
>
>
>> Naming is fun.
>>
>
> Learning how to communicate across cultures of all types is fun. ;-)
>
>
> --
> Alfonso Guerra
> Founder/CEO
> Apokalypse Software Corp.
> (626) 667-4285
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 08:54 +0200, Carlos Garcia Campos escribió:
> El lun, 29-08-2016 a las 10:01 -0700, Darin Adler escribió:
> > 
> > > 
> > > On Aug 29, 2016, at 1:16 AM, Carlos Garcia Campos  > > t.
> > > org> wrote:
> > > 
> > > Does that mean than from the WebIDL point of view all methods can
> > > now
> > > raise a exception? If don't tell the code generator that a method
> > > can
> > > raise a exception, we assume all could return a Exception?
> > 
> > Correct.
> > 
> > Once the transition is done, the IDL will no longer indicate which
> > functions can raise exceptions; the return types of C++ member
> > functions will, instead. During the transition, exceptions can be
> > indicated in either way.
> > 
> > > 
> > > It actually depends on whether this is an exception or not.
> > 
> > I’m not sure exactly what you mean. But I expect us to keep driving
> > JavaScript DOM bindings forward in lots of ways. Here are a few:
> > 
> > - We will add support for more WebIDL features. There are many
> > still
> > to go. In some cases that means removing code that is currently in
> > the DOM that is doing part of the bindings work and using WebIDL to
> > implement this things. For example, translation of strings into
> > enum
> > values. WebIDL includes a specification of how all these features
> > are
> > reflected in JavaScript, but for non-JavaScript bindings we have to
> > define how to reflect each feature.
> > 
> > - We will add better exception messages, which means DOM code has
> > to
> > provide more than an exception code.
> > 
> > - We will update bindings with changes to move the web platform
> > forward, with JavaScript-specific strategies for backward
> > compatibility that won’t necessarily work for other languages such
> > as
> > Objective-C. For example, the latest specifications turn
> > DOMImplementation.hasFeature into a function that ignores its
> > arguments and always returns true. That’s easy to implement with
> > WebIDL for JavaScript, but for GObject and Objective-C we need code
> > somewhere that remembers what the old argument list was.
> > 
> > - We will update bindings with changes that have minimal observable
> > effect in the JavaScript type system but have effects on types of
> > arguments or return values in GObject bindings, such as making a
> > return type more specific (Attr instead of Node) or changing which
> > numeric type is used.
> > 
> > - We will move things currently done in the DOM itself into the
> > bindings.
> > 
> > - We would like to change the bindings generation scripts to run
> > more
> > quickly and so that fewer run when a given IDL source file is
> > changed.
> > 
> > > 
> > > If you really think that build is going to be broken often
> > > because
> > > of things very difficult to do in the GObject bindings, then we
> > > should indeed find a more general solution. Otherwise I prefer to
> > > solve this problem now, and keep the existing way of generating
> > > the
> > > bindings. We can add a rule that you can break the GObject DOM
> > > bindings build, to not block your work, and I'll try to fix it
> > > asap
> > > as we currently do with WebKit2.
> > 
> > Something like this might work. But coping with these changes is
> > going to be challenging.
> > 
> > I expect we are going to continue to run into many things we want
> > to
> > do for JavaScript that are difficult to do in the GObject bindings.
> > It’s taken many people hundreds of hours already to add these
> > various
> > WebIDL features for the JavaScript bindings, and each one involved
> > changing both the bindings and the underlying DOM implementation.
> > 
> > I think the 88 already existing #if statements in the IDL are one
> > indication that the IDL-based code generation strategy isn’t
> > working
> > very well; *many* features that are simply not supported outside
> > the
> > JavaScript code generator because they use one of the newer IDL
> > features are another.
> > 
> > If you read the latest WebIDL draft  > l/
> > > 
> > > you will see lots of features that are tricky to deal
> > with—dictionary types, enumeration types, callback function types,
> > promise types, union types, regular expressions, frozen arrays,
> > stringifiers, serializers, indexed properties, named properties,
> > overloading, map like, setlike—the only reason this is not a crisis
> > is that many web APIs are old and so not built on any of these new
> > concepts. Over time, critical features are being built on them.
> 
> Ok, I think we can freeze the GObject bindings too, and then see how
> things go and decide what to do. From the users point of view there
> will be no difference, the current API will be available and working.
> Then, you can add any new features to WebIDL without having to worry
> about GObject bindings and we can take our time to discuss what to
> do.
> 
> > 
> > I am OK with the “it is OK to break the GObject bindings build”
> >