[Webkit-unassigned] [Bug 52791] Buffer overrun in WebCore::InspectorBasicValue::writeJSON

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=52791





--- Comment #20 from Mikołaj Małecki <m.malecki at samsung.com>  2011-02-07 07:57:59 PST ---
(In reply to comment #19)
> > I understand that you might have not tested the toJSONString method at all, but in order to provide any tests for that, I need some wireframes to pin in my test code. Where can I find that?
> 
> Typically, LayoutTestController harness is being extended to expose additional APIs to the layout test page. I don't think it is worth it in this case though.

That's correct, so in this case you can accept my patch without additional tests, right?

> > First of all, web inspector is implemented such a way that I can always create another type of inspector client, pin in my injected script, which is just a js script, and all these things should work.
> 
> I am very familiar with how inspector works (and more importantly should work) since most of the abstractions you are operating were introduced by myself. In fact, you can't 'pin in' your injected script. Injected script is backend's implementation details.

I'm using setInjectedScriptSource to 'pin in' this injected script. We are using another injected script, which is slightly modified the default one (we needed a bit more information about the objects being inspected).

> Until inspector protocol matures, we'd like to keep its format private to inspector.

What protocol are you talking about? Do you mean the protocol implemented in a generated file @ build-obj/DerivedSources/WebCore/InspectorBackendDispatcher.cpp?

> So strictly speaking, there is no guarantee that the String message you are operating is a JSON string. It will most likely be one since we are working on publishing the protocol.

But there was no other code in WebKit to hang in.

> Speaking of InspectorValue, it is definitely inspector's property and should not be used outside of inspector. It is not a real JSON, if you need one - use JSON object in the JavaScript context instead.

Maybe we haven't used the best source for communication with web inspector, but we have already done it and we don't have infinite time for fixing it or writing it anew. Actually I don't think it's used outside the inspector, although the inspector client we have written is used for external communication using the data.

> Speaking of remote debugging, I know a number of ports that are supporting it already using our front-end (i.e. not cracking the protocol messages) and one Eclipse integration being developed. None of them are cracking inspector messages on the backend side. Why does yours do that?

Because we needed it in webkit itself and we needed that it be implemented in native language, to have it working with another native code. The web inspector's C++ API gives us direct access to the objects and events happening in the web inspector. Practically this was the only thing that was ready for use for it.

I understand that this is maybe not the best way to implement it, but we haven't found any better one. I have opened another bug for discussing it counting for that I will get some help about a best way to do it, but I got no valuable response.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.