[webkit-dev] Can someone explain tx/ty?
I believe int tx, int ty -- which we see sprinkled around the rendering tree -- are the offset from the top left corner of the current renderer's parent to the containing block. Is that correct? In SVG we use IntSize containingBlockOffset in the rare places we have to deal with this RenderBoxModelObject-only concept. I've long considered fixing renders to use IntPoint and IntSize instead of x, y, tx, ty, but to do that, I need to make sure I understand what tx, ty are, and what name they should have as an IntSize. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] AXObjectCache memory management?
On Aug 23, 2010, at 12:47 AM, Eric Seidel wrote: Does anyone know why AXObjectCache is not ref counted? It has some manual scheme which seems likely to have bugs in it. http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp#L1742 There just seems to be a lot of code in Document to manage this simple cache. I don't know the history of this code, but I suspect refcounting would work. Note: a bunch of the complexity there is to ensure there is only one AXObjectCache per frame/document tree, but still keep it in a member of Document. Using refcounting would get rid of the explicit new/delete calls, but would not greatly simplify the overall logic. If there is only supposed to be one per top-level document rather than one per document, perhaps it should live off of Page. Then it could follow single ownership and be held by an OwnPtr. It would add more indicrection to accessing it, but would save multiple function calls and branches, so probably not a performance issue. I believe there is no need to ever get AXObjects for a Document that is not currently held by a Frame that belongs to a Page. Of course, refcounting would still be fine in this case, these objects are not so common that a refcount field is an extravagant expense. My point is mainly this: I believe the key design problem is that the AXObject cache is held by Document instead of Page even though our goal is to have one per Page. I expect we have enough regression tests for accessibility to try this change. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Not enough space message when linking webkit (lots of free disk space)
The Kernel usually reserves 1/4 (but up to 3/4 on some OSes) of the address space for itself + you can get fragmentation. So the linker only can use part of the 4gb of ram in your machine. So switching to a 64 bit linker would probably fix the problem for now. Another option is to disable some parts of WebKit you don't need (like SVG). J On Mon, Aug 23, 2010 at 3:26 AM, Chris Hatko cha...@gmail.com wrote: Hi Nico, Yes, I've got 32 bit MSVS2005. I found that turning off /LTCG and /GL optimization allowed me to get past this error. Do we now need more than 4Gigs of RAM to compile webkit with release optimizations? Chris On Sun, Aug 22, 2010 at 4:09 PM, Nico Weber tha...@chromium.org wrote: Are you using a 32 bit linker? Maybe it's running out of address space. Nico On Sun, Aug 22, 2010 at 12:32 PM, Chris Hatko cha...@gmail.com wrote: I'm running revision 65648 and building cairo-win32 release I'm getting Not enough space when linking WebKit project. I have 40Gig free space on this drive and 4Gigs of ram. Linking... 11fatal error C1083: Cannot open compiler intermediate file: 'C:\cygwin\home\HATKO\WebKit\WebKitBuild\lib\WebKitLib.lib': Not enough space 11LINK : fatal error LNK1257: code generation failed 11Build log was saved at file://C:\cygwin\home\HATKO\WebKit\WebKitBuild\obj\WebKit\Release_Cairo\BuildLog.htm 11WebKit - 1 error(s), 1 warning(s). Any idea what I can try? Thanks, Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can someone explain tx/ty?
On Aug 23, 2010, at 12:51 AM, Eric Seidel wrote: I believe int tx, int ty -- which we see sprinkled around the rendering tree -- are the offset from the top left corner of the current renderer's parent to the containing block. Is that correct? In SVG we use IntSize containingBlockOffset in the rare places we have to deal with this RenderBoxModelObject-only concept. I've long considered fixing renders to use IntPoint and IntSize instead of x, y, tx, ty, but to do that, I need to make sure I understand what tx, ty are, and what name they should have as an IntSize. I think it would be good to use IntPoint and IntSize in more places in the render tree. My understanding of tx/ty is imperfect so you may want to have a rendering guru weigh in, but I believe it works like this: - x(), y() are a renderer's position in the coordinate system of its parent - tx, ty are the origin of the parent's coordinate system relative to the origin for its layer. When a layer paints, it establishes a CTM such that its own origin is 0, 0 (I think). When a renderer paints, the first thing it does is add its own x() and y() to tx and ty, and it passes the new values of tx and ty to its children. There's two ways to express this in size/point terms. First, some rules for Point / Size math: - You can add a Size to a Point to get a new Point. - You can add a Size to a Size to get a new Size. - It doesn't make logical sense to add two Points, so the operation doesn't exist. Points are absolute and Sizes are relative; you can't add two absolutes. The more obvious way, given the variable names, would be to make x(), y() an IntPoint, with a name like originInParentCoordinates() (hopefully less verbose, but you get the idea). tx, ty could be named parentOffsetFromLayerCoordinates or something. This seems to be the intent of the names - that x,y is a point and tx, ty is a translation. But this doesn't work in point/size logic. You repeatedly add x(), y() to tx, ty to get a new tx, ty. But that means you're adding a point to a size and expecting to get a new size - but that's not how it works. The way that works is to reverse the logic. tx, ty becomes IntPoint parentOrigin. x(), y() becomes IntSize offsetFromParent(). You add your offsetFromParent() to your parentOrigin to get the parentOrigin you pass from your children. This reverses the idea of which is the point and which is the offset, but it fits the axioms of point/size arithmetic and I believe it is ultimately more logical. You can see this in part from the shorter names. The first line in a ::paint() method would be IntPoint origin = parentOrigin + offsetFromParent(). How sweet is that? (Note: I omitted many details here, such as accounting for scroll offsets. Renderers that are scrolled account for the scroll offset in the tx, ty they pass their children even though this is not strictly their *own* origin.) BTW I have rewritten parts of render tree logic before to use IntPoint, IntSize, and point/size operations instead of dealing with individual coordinates, and I always found the code far more readable. This is particularly so when I stopped to figure out what should be a size and what should be a point based on the axioms of point/size arithmetic. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Not enough space message when linking webkit (lots of free disk space)
SVG gets such a bad wrap. :) Wouldn't breaking WebCore into smaller libraries fix these linker problems longer-term? For example, breaking out platform into a .a, or the JS bindings? I guess we'd have to make them .dylib instead of .a if we wanted to actually make the linker happier. On Mon, Aug 23, 2010 at 2:26 AM, Jeremy Orlow jor...@chromium.org wrote: The Kernel usually reserves 1/4 (but up to 3/4 on some OSes) of the address space for itself + you can get fragmentation. So the linker only can use part of the 4gb of ram in your machine. So switching to a 64 bit linker would probably fix the problem for now. Another option is to disable some parts of WebKit you don't need (like SVG). J On Mon, Aug 23, 2010 at 3:26 AM, Chris Hatko cha...@gmail.com wrote: Hi Nico, Yes, I've got 32 bit MSVS2005. I found that turning off /LTCG and /GL optimization allowed me to get past this error. Do we now need more than 4Gigs of RAM to compile webkit with release optimizations? Chris On Sun, Aug 22, 2010 at 4:09 PM, Nico Weber tha...@chromium.org wrote: Are you using a 32 bit linker? Maybe it's running out of address space. Nico On Sun, Aug 22, 2010 at 12:32 PM, Chris Hatko cha...@gmail.com wrote: I'm running revision 65648 and building cairo-win32 release I'm getting Not enough space when linking WebKit project. I have 40Gig free space on this drive and 4Gigs of ram. Linking... 11fatal error C1083: Cannot open compiler intermediate file: 'C:\cygwin\home\HATKO\WebKit\WebKitBuild\lib\WebKitLib.lib': Not enough space 11LINK : fatal error LNK1257: code generation failed 11Build log was saved at file://C:\cygwin\home\HATKO\WebKit\WebKitBuild\obj\WebKit\Release_Cairo\BuildLog.htm 11WebKit - 1 error(s), 1 warning(s). Any idea what I can try? Thanks, Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Not enough space message when linking webkit (lots of free disk space)
On Aug 23, 2010, at 2:38 AM, Eric Seidel wrote: SVG gets such a bad wrap. :) Wouldn't breaking WebCore into smaller libraries fix these linker problems longer-term? For example, breaking out platform into a .a, or the JS bindings? I guess we'd have to make them .dylib instead of .a if we wanted to actually make the linker happier. Making multiple .a files wouldn't really do anything - they are just archives of .o files and linking them into a shared library would still be just as expensive. Splitting into multiple .dylib/.so/.dll's would impose a runtime cost, which I think is not a good tradeoff for faster linking (and easier linking with less memory). A long time ago in the mysterious pre-history of WebKit, I had the WebCore build set up to build a separate relocatable object file per directory, and then link them all into a final dynamic library. This does partial linking, making the final linker step less expensive, though I don't know how much less memory it would use. The command-line tools know how to do this, but Xcode does not, so we lost this feature once we adopted Xcode. It made linking significantly faster with no runtime cost. I am not sure if it would still work today or if there is a similar approach on Windows. To be more specific, what I used is 'ld -r', which works with both the Mac OS X linker and GNU ld. I believe Visual Studio also has an incremental linking feature, but I don't know how it works or whether we are using it currently. Regards, Maciej On Mon, Aug 23, 2010 at 2:26 AM, Jeremy Orlow jor...@chromium.org wrote: The Kernel usually reserves 1/4 (but up to 3/4 on some OSes) of the address space for itself + you can get fragmentation. So the linker only can use part of the 4gb of ram in your machine. So switching to a 64 bit linker would probably fix the problem for now. Another option is to disable some parts of WebKit you don't need (like SVG). J On Mon, Aug 23, 2010 at 3:26 AM, Chris Hatko cha...@gmail.com wrote: Hi Nico, Yes, I've got 32 bit MSVS2005. I found that turning off /LTCG and /GL optimization allowed me to get past this error. Do we now need more than 4Gigs of RAM to compile webkit with release optimizations? Chris On Sun, Aug 22, 2010 at 4:09 PM, Nico Weber tha...@chromium.org wrote: Are you using a 32 bit linker? Maybe it's running out of address space. Nico On Sun, Aug 22, 2010 at 12:32 PM, Chris Hatko cha...@gmail.com wrote: I'm running revision 65648 and building cairo-win32 release I'm getting Not enough space when linking WebKit project. I have 40Gig free space on this drive and 4Gigs of ram. Linking... 11fatal error C1083: Cannot open compiler intermediate file: 'C:\cygwin\home\HATKO\WebKit\WebKitBuild\lib\WebKitLib.lib': Not enough space 11LINK : fatal error LNK1257: code generation failed 11Build log was saved at file://C:\cygwin\home\HATKO\WebKit\WebKitBuild\obj\WebKit\Release_Cairo\BuildLog.htm 11WebKit - 1 error(s), 1 warning(s). Any idea what I can try? Thanks, Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DeviceOrientation/Motion on Document rather than Page
- it would allow the client to live in WebCore. FWIW, Geolocation seems to take both approaches. One implementation is down in Navigator/Document/DOMWindow, but the mock controller is on Page. I've found the low-level approach much easier to implement. My understanding was that clients for these platform-specific features should live in the WebKit layer. The original Geolocation implementation used a platform-specific GeolocationService in WebCore, but a client-based implementation was later added by Sam to avoid the layering violations of the former approach. See https://bugs.webkit.org/show_bug.cgi?id=32499#c10. I'm currently working to remove the old non-client-based Geolocation implementation, see https://bugs.webkit.org/show_bug.cgi?id=40373. Please let me know if this is the wrong approach! I assume one of the advantages of having them on Page is that it allows a Mock Controller to be easily created for testing from Dump Render Tree. Am I right? Is this that important? Yes, that is also part of the motivation. The non-client-based Geolocation implementation provides a mock in WebCore, but setting and configuring this mock from DumpRenderTree is ugly. For this sort of thing, it seems reasonable to me that there is a layer of the implementation that is a per-document controller, and then below that a singleton object in case we don't need things to happen multiple times per document. I don't have a strong opinion regarding Page vs Document, but it seems that other platform-specific clients of this type belong to the Page. I agree that it's likely that a platform will use a singleton at the lowest level, but the platform can provide the multiplexing whether the client is provided to the Page or the Document. Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Not enough space message when linking webkit (lots of free disk space)
On Mon, Aug 23, 2010 at 2:26 AM, Jeremy Orlow wrote: The Kernel usually reserves 1/4 (but up to 3/4 on some OSes) of the address space for itself + you can get fragmentation. So the linker only can use part of the 4gb of ram in your machine. So switching to a 64 bit linker would probably fix the problem for now. Another option is to disable some parts of WebKit you don't need (like SVG). J On Mon, Aug 23, 2010 at 3:26 AM, Chris Hatko wrote: Hi Nico, Yes, I've got 32 bit MSVS2005. I found that turning off /LTCG and /GL optimization allowed me to get past this error. Do we now need more than 4Gigs of RAM to compile webkit with release optimizations? If you do a google search on that error number you get some suggestions others have observed this, http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/a9fc5fea-41f8-4bce-8d64-afbe92ac2c41 ( you could edit this by hand or type error into goog if this no work ) http://www.google.com/#hl=ensafe=offq=LNK1257aq=faqi=aql=oq=gs_rfai=fp=a2523ac2264f1e8f The reason I'm contributing a response here is not due to great insight but because I just got a Debian build to go on a 768M emachines and the cygwin build was just fine on a somewhat more capable machine ( actually it is a server and probably many G's so that may not be informative). In any case, I seem to have foggy memories of many years ago running into a problem like this on MSVC but honestly it could have been the INTC linker my memory is so bad. And, it wasn't clear from the discussion what memory you were talking about- the target exe memory map or the physical memory available to the linker which shouldnt have any problem using VM( who cares how much physical memory you have, just wait wait wait). In general out of memory errors can occur due to algorithm failure ( often infinite loop that depletes heap before stack) or data failure ( you see this a lot when trying to open image data and dimensions are random data that often are large numbers when taken as width and height LOL). So, no practical amount of memory addition is likely to fix anything in those cases. FWIW HTH. Chris On Sun, Aug 22, 2010 at 4:09 PM, Nico Weber wrote: Are you using a 32 bit linker? Maybe it's running out of address space. Nico On Sun, Aug 22, 2010 at 12:32 PM, Chris Hatko wrote: I'm running revision 65648 and building cairo-win32 release I'm getting Not enough space when linking WebKit project. I have 40Gig free space on this drive and 4Gigs of ram. Linking... 11fatal error C1083: Cannot open compiler intermediate file: 'C:\cygwin\home\HATKO\WebKit\WebKitBuild\lib\WebKitLib.lib': Not enough space 11LINK : fatal error LNK1257: code generation failed 11Build log was saved at ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Making GRefPtr more general
Recently there was a need to make the smart pointer wrapping GLib reference-counted types more general. In this case it was to extend it to Cairo. Here is the bug for that: https://bugs.webkit.org/show_bug.cgi?id=44354 It struck me that the name GRefPtr wasn't very applicable to this type any longer, so I changed it to PlatformRefPtr in my patch. That seemed a bit wordy and others have suggested PRefPtr. Since this naming affects more than just the GTK+ port, I thought I would get some opinions on a name that is easy to type and fitting. Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making GRefPtr more general
Would this then combine with the Mac/Win port's RetainPtr in some way? On Mon, Aug 23, 2010 at 9:49 AM, Martin Robinson mrobin...@webkit.org wrote: Recently there was a need to make the smart pointer wrapping GLib reference-counted types more general. In this case it was to extend it to Cairo. Here is the bug for that: https://bugs.webkit.org/show_bug.cgi?id=44354 It struck me that the name GRefPtr wasn't very applicable to this type any longer, so I changed it to PlatformRefPtr in my patch. That seemed a bit wordy and others have suggested PRefPtr. Since this naming affects more than just the GTK+ port, I thought I would get some opinions on a name that is easy to type and fitting. Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can someone explain tx/ty?
On Aug 23, 2010, at 4:33 AM, Maciej Stachowiak wrote: - tx, ty are the origin of the parent's coordinate system relative to the origin for its layer. When a layer paints, it establishes a CTM such that its own origin is 0, 0 (I think). They are relative to a painting root, which will basically either be the document or a compositing layer. The more obvious way, given the variable names, would be to make x(), y() an IntPoint, with a name like originInParentCoordinates() It already is an IntPoint internally. There's already a method to access it as a point. IntPoint location() const (hopefully less verbose, but you get the idea). tx, ty could be named parentOffsetFromLayerCoordinates or something. This seems to be the intent of the names - that x,y is a point and tx, ty is a translation. But this doesn't work in point/size logic. You repeatedly add x(), y() to tx, ty to get a new tx, ty. But that means you're adding a point to a size and expecting to get a new size - but that's not how it works. I think a helper method that does the right thing solves this problem (rather than having to flip what x/y and tx/ty mean just to do some math operation). dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can someone explain tx/ty?
On Aug 23, 2010, at 12:11 PM, David Hyatt wrote: (hopefully less verbose, but you get the idea). tx, ty could be named parentOffsetFromLayerCoordinates or something. This seems to be the intent of the names - that x,y is a point and tx, ty is a translation. But this doesn't work in point/size logic. You repeatedly add x(), y() to tx, ty to get a new tx, ty. But that means you're adding a point to a size and expecting to get a new size - but that's not how it works. I think a helper method that does the right thing solves this problem (rather than having to flip what x/y and tx/ty mean just to do some math operation). dave Just to clarify, if tx/ty turned into an IntSize offset, I think you could just add a helper method like .asOffset() to IntPoint to solve this particular problem. Instead of tx += x(); ty += y(); You could write: offset += location().asOffset(); I'd also have no objection to just building that right into RenderBox... offset += locationOffset(); dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKitTools/Script/generate-coverage-data
Has anyone looked at our coverage-generating scripts in a while? Seems to die trying to build libANGLE these days, but I believe the scripts have been dead for much longer. I'm interested in finding (and removing) dead code from WebCore. There is a whole bunch more dead code now that the LegacyHTMLDocumentParser has been removed. I'd like to rip it out. I was hoping gcov / generate-coverage-data would help me do that. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Layout Tests Crashing on Snow Leopard
Started yesterday. A bunch of layout tests crash in some ASSERT in
WebKitPluginHost / testnetscapeplugin.
// Entry points
extern C
NPError STDCALL NP_Initialize(NPNetscapeFuncs *browserFuncs)
{
#if XP_WIN
// Simulate Flash and QuickTime's behavior of crashing when
NP_Initialize is called before NP_GetEntryPoints.
if (!getEntryPointsWasCalled)
CRASH();
#elif XP_MACOSX
// Simulate Silverlight's behavior of crashing when
NP_GetEntryPoints is called before NP_Initialize.
if (getEntryPointsWasCalled)
CRASH(); // THIS IS THE CRASH WE'RE HITTING.
#endif
Seems someone borked something this weekend. Thoughts?
I'm also happy to file a bug.
ccing plugin folks.
-eric
Process: WebKitPluginHost [28100]
Path:
/System/Library/Frameworks/WebKit.framework/WebKitPluginHost.app/Contents/MacOS/WebKitPluginHost
Identifier: com.apple.WebKit.PluginHost
Version: 6533 (6533.13)
Build Info: WebKitPluginHost-75331300~7
Code Type: X86-64 (Native)
Parent Process: WebKitPluginAgent [28095]
Date/Time: 2010-08-23 13:11:23.797 -0700
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6
Interval Since Last Report: 78444 sec
Crashes Since Last Report: 209
Per-App Interval Since Last Report: 10302 sec
Per-App Crashes Since Last Report: 20
Anonymous UUID: A1F25920-3E56-4095-8E69-3069478CA352
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xbbadbeef
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.testnetscapeplugin0x0001022858b0 NP_Initialize +
28 (main.cpp:64)
1 com.apple.WebKit.PluginHost 0x000117d82188 0x117d6f000 + 78216
2 com.apple.WebKit.PluginHost 0x000117d769e1 0x117d6f000 + 31201
3 com.apple.WebKit.PluginHost 0x000117d71ad3 0x117d6f000 + 10963
4 com.apple.CoreFoundation0x7fff80817e09 __CFRunLoopDoBlocks
+ 297
5 com.apple.CoreFoundation0x7fff807da906 __CFRunLoopRun + 3046
6 com.apple.CoreFoundation0x7fff807d984f CFRunLoopRunSpecific
+ 575
7 com.apple.HIToolbox 0x7fff8313091a
RunCurrentEventLoopInMode + 333
8 com.apple.HIToolbox 0x7fff8313071f
ReceiveNextEventCommon + 310
9 com.apple.HIToolbox 0x7fff831305d8
BlockUntilNextEventMatchingListInMode + 59
10 com.apple.AppKit0x7fff8500229e _DPSNextEvent + 708
11 com.apple.AppKit0x7fff85001bed -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
12 com.apple.AppKit0x7fff84fc78d3 -[NSApplication run]
+ 395
13 com.apple.WebKit.PluginHost 0x000117d734c1 0x117d6f000 + 17601
14 com.apple.WebKit.PluginHost 0x000117d70a94 0x117d6f000 + 6804
Thread 1: Dispatch queue: com.apple.libdispatch-manager
0 libSystem.B.dylib 0x7fff85cd808a kevent + 10
1 libSystem.B.dylib 0x7fff85cd9f5d _dispatch_mgr_invoke
+ 154
2 libSystem.B.dylib 0x7fff85cd9c34
_dispatch_queue_invoke + 185
3 libSystem.B.dylib 0x7fff85cd975e
_dispatch_worker_thread2 + 252
4 libSystem.B.dylib 0x7fff85cd9088 _pthread_wqthread +
353
5 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread + 13
Thread 2:
0 libSystem.B.dylib 0x7fff85cd8eaa __workq_kernreturn +
10
1 libSystem.B.dylib 0x7fff85cd92bc _pthread_wqthread +
917
2 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread + 13
Thread 3:
0 libSystem.B.dylib 0x7fff85cd8eaa __workq_kernreturn +
10
1 libSystem.B.dylib 0x7fff85cd92bc _pthread_wqthread +
917
2 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread + 13
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0xbbadbeef rbx: 0x000102285894 rcx:
0x000102295d27 rdx: 0x
rdi: 0x000100412e48 rsi: 0x rbp:
0x7fff5fbfe5f0 rsp: 0x7fff5fbfe5e0
r8: 0x7fff70b19748 r9: 0x000102296ab0 r10:
0x000102295d18 r11: 0x000102296ab0
r12: 0x000100412dc0 r13: 0x0001022858d2 r14:
0x0001 r15: 0x0001001121b0
rip: 0x0001022858b0 rfl: 0x00010202 cr2: 0xbbadbeef
Binary Images:
0x102283000 -0x102291ff7 com.apple.testnetscapeplugin
1.0 (1.0) B0DFFFBA-0627-909D-5522-019409554EE1
/Projects/build/Debug/TestNetscapePlugIn.plugin/Contents/MacOS/TestNetscapePlugIn
0x10c80 -0x10cb03ff7 com.apple.JavaScriptCore 534+
(534.6+) 781F7088-7B81-DD29-313E-FBAF603F3EBC
/Projects/build/Debug/JavaScriptCore.framework/Versions/A/JavaScriptCore
0x10cf29000 -0x10d1a6fe7
Re: [webkit-dev] Layout Tests Crashing on Snow Leopard
This is gonna kill me. Does no one else run the layout tests...?
On Mon, Aug 23, 2010 at 1:43 PM, Ryosuke Niwa rn...@webkit.org wrote:
FYI, there was a series of plugin patches committed this weekend:
http://trac.webkit.org/search?q=pluginnoquickjump=1changeset=onwiki=on
Best,
Ryosuke Niwa
Software Engineer
Google Inc.
On Mon, Aug 23, 2010 at 1:14 PM, Eric Seidel e...@webkit.org wrote:
Started yesterday. A bunch of layout tests crash in some ASSERT in
WebKitPluginHost / testnetscapeplugin.
// Entry points
extern C
NPError STDCALL NP_Initialize(NPNetscapeFuncs *browserFuncs)
{
#if XP_WIN
// Simulate Flash and QuickTime's behavior of crashing when
NP_Initialize is called before NP_GetEntryPoints.
if (!getEntryPointsWasCalled)
CRASH();
#elif XP_MACOSX
// Simulate Silverlight's behavior of crashing when
NP_GetEntryPoints is called before NP_Initialize.
if (getEntryPointsWasCalled)
CRASH(); // THIS IS THE CRASH WE'RE HITTING.
#endif
Seems someone borked something this weekend. Thoughts?
I'm also happy to file a bug.
ccing plugin folks.
-eric
Process: WebKitPluginHost [28100]
Path:
/System/Library/Frameworks/WebKit.framework/WebKitPluginHost.app/Contents/MacOS/WebKitPluginHost
Identifier: com.apple.WebKit.PluginHost
Version: 6533 (6533.13)
Build Info: WebKitPluginHost-75331300~7
Code Type: X86-64 (Native)
Parent Process: WebKitPluginAgent [28095]
Date/Time: 2010-08-23 13:11:23.797 -0700
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6
Interval Since Last Report: 78444 sec
Crashes Since Last Report: 209
Per-App Interval Since Last Report: 10302 sec
Per-App Crashes Since Last Report: 20
Anonymous UUID: A1F25920-3E56-4095-8E69-3069478CA352
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xbbadbeef
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.testnetscapeplugin 0x0001022858b0 NP_Initialize +
28 (main.cpp:64)
1 com.apple.WebKit.PluginHost 0x000117d82188 0x117d6f000 +
78216
2 com.apple.WebKit.PluginHost 0x000117d769e1 0x117d6f000 +
31201
3 com.apple.WebKit.PluginHost 0x000117d71ad3 0x117d6f000 +
10963
4 com.apple.CoreFoundation 0x7fff80817e09
__CFRunLoopDoBlocks + 297
5 com.apple.CoreFoundation 0x7fff807da906 __CFRunLoopRun
+ 3046
6 com.apple.CoreFoundation 0x7fff807d984f
CFRunLoopRunSpecific + 575
7 com.apple.HIToolbox 0x7fff8313091a
RunCurrentEventLoopInMode + 333
8 com.apple.HIToolbox 0x7fff8313071f
ReceiveNextEventCommon + 310
9 com.apple.HIToolbox 0x7fff831305d8
BlockUntilNextEventMatchingListInMode + 59
10 com.apple.AppKit 0x7fff8500229e _DPSNextEvent +
708
11 com.apple.AppKit 0x7fff85001bed -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
12 com.apple.AppKit 0x7fff84fc78d3 -[NSApplication
run] + 395
13 com.apple.WebKit.PluginHost 0x000117d734c1 0x117d6f000 +
17601
14 com.apple.WebKit.PluginHost 0x000117d70a94 0x117d6f000 +
6804
Thread 1: Dispatch queue: com.apple.libdispatch-manager
0 libSystem.B.dylib 0x7fff85cd808a kevent + 10
1 libSystem.B.dylib 0x7fff85cd9f5d
_dispatch_mgr_invoke + 154
2 libSystem.B.dylib 0x7fff85cd9c34
_dispatch_queue_invoke + 185
3 libSystem.B.dylib 0x7fff85cd975e
_dispatch_worker_thread2 + 252
4 libSystem.B.dylib 0x7fff85cd9088
_pthread_wqthread + 353
5 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread
+ 13
Thread 2:
0 libSystem.B.dylib 0x7fff85cd8eaa
__workq_kernreturn + 10
1 libSystem.B.dylib 0x7fff85cd92bc
_pthread_wqthread + 917
2 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread
+ 13
Thread 3:
0 libSystem.B.dylib 0x7fff85cd8eaa
__workq_kernreturn + 10
1 libSystem.B.dylib 0x7fff85cd92bc
_pthread_wqthread + 917
2 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread
+ 13
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0xbbadbeef rbx: 0x000102285894 rcx:
0x000102295d27 rdx: 0x
rdi: 0x000100412e48 rsi: 0x rbp:
0x7fff5fbfe5f0 rsp: 0x7fff5fbfe5e0
r8: 0x7fff70b19748 r9: 0x000102296ab0 r10:
0x000102295d18 r11: 0x000102296ab0
r12: 0x000100412dc0 r13: 0x0001022858d2 r14:
0x0001 r15: 0x0001001121b0
rip: 0x0001022858b0 rfl:
[webkit-dev] Layout bug with table align=center?
Hi, there seems to be a bug in webkit (affecting webkitgtk, qtwebit and chromium) which leads to incorrect rendering of: http://www.flumotion.com/first_webm_live_event.php I can reproduce it with midori (webkitgtk), arora (qtwebkit) and chromium, haven't tried anything else. Looks like the problem lies in interpretation of align=center inside table element. It behaves differently from what I'd expect after trying other options (like align=left or align=right) and it is different from firefox. The reason I'm asking here first before filling a bug is to be 100 % sure it's a bug in webkit and not in the above mentioned page +firefox... webkitgtk is 1.2.3, qtwebkit is the one shipped with 4.6.3 (arora says it's webkit 532.4) and chromium 6.0.476.0 (0). Martin 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] Layout bug with table align=center?
A reduction would be useful. My general approach is: file a bug first, ask questions later. :) Once we have a bug, we can attach a reduction and work towards resolution (even if that means no change to WebKit). -eric On Mon, Aug 23, 2010 at 3:06 PM, Martin Sourada martin.sour...@gmail.com wrote: Hi, there seems to be a bug in webkit (affecting webkitgtk, qtwebit and chromium) which leads to incorrect rendering of: http://www.flumotion.com/first_webm_live_event.php I can reproduce it with midori (webkitgtk), arora (qtwebkit) and chromium, haven't tried anything else. Looks like the problem lies in interpretation of align=center inside table element. It behaves differently from what I'd expect after trying other options (like align=left or align=right) and it is different from firefox. The reason I'm asking here first before filling a bug is to be 100 % sure it's a bug in webkit and not in the above mentioned page +firefox... webkitgtk is 1.2.3, qtwebkit is the one shipped with 4.6.3 (arora says it's webkit 532.4) and chromium 6.0.476.0 (0). Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Layout Tests Crashing on Snow Leopard
FYI, I was seeing this too over the weekend.
Simon
On Aug 23, 2010, at 2:54 PM, Eric Seidel wrote:
This is gonna kill me. Does no one else run the layout tests...?
On Mon, Aug 23, 2010 at 1:43 PM, Ryosuke Niwa rn...@webkit.org wrote:
FYI, there was a series of plugin patches committed this weekend:
http://trac.webkit.org/search?q=pluginnoquickjump=1changeset=onwiki=on
Best,
Ryosuke Niwa
Software Engineer
Google Inc.
On Mon, Aug 23, 2010 at 1:14 PM, Eric Seidel e...@webkit.org wrote:
Started yesterday. A bunch of layout tests crash in some ASSERT in
WebKitPluginHost / testnetscapeplugin.
// Entry points
extern C
NPError STDCALL NP_Initialize(NPNetscapeFuncs *browserFuncs)
{
#if XP_WIN
// Simulate Flash and QuickTime's behavior of crashing when
NP_Initialize is called before NP_GetEntryPoints.
if (!getEntryPointsWasCalled)
CRASH();
#elif XP_MACOSX
// Simulate Silverlight's behavior of crashing when
NP_GetEntryPoints is called before NP_Initialize.
if (getEntryPointsWasCalled)
CRASH(); // THIS IS THE CRASH WE'RE HITTING.
#endif
Seems someone borked something this weekend. Thoughts?
I'm also happy to file a bug.
ccing plugin folks.
-eric
Process: WebKitPluginHost [28100]
Path:
/System/Library/Frameworks/WebKit.framework/WebKitPluginHost.app/Contents/MacOS/WebKitPluginHost
Identifier: com.apple.WebKit.PluginHost
Version: 6533 (6533.13)
Build Info: WebKitPluginHost-75331300~7
Code Type: X86-64 (Native)
Parent Process: WebKitPluginAgent [28095]
Date/Time: 2010-08-23 13:11:23.797 -0700
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6
Interval Since Last Report: 78444 sec
Crashes Since Last Report: 209
Per-App Interval Since Last Report: 10302 sec
Per-App Crashes Since Last Report: 20
Anonymous UUID: A1F25920-3E56-4095-8E69-3069478CA352
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xbbadbeef
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.testnetscapeplugin0x0001022858b0 NP_Initialize +
28 (main.cpp:64)
1 com.apple.WebKit.PluginHost 0x000117d82188 0x117d6f000 +
78216
2 com.apple.WebKit.PluginHost 0x000117d769e1 0x117d6f000 +
31201
3 com.apple.WebKit.PluginHost 0x000117d71ad3 0x117d6f000 +
10963
4 com.apple.CoreFoundation0x7fff80817e09
__CFRunLoopDoBlocks + 297
5 com.apple.CoreFoundation0x7fff807da906 __CFRunLoopRun
+ 3046
6 com.apple.CoreFoundation0x7fff807d984f
CFRunLoopRunSpecific + 575
7 com.apple.HIToolbox 0x7fff8313091a
RunCurrentEventLoopInMode + 333
8 com.apple.HIToolbox 0x7fff8313071f
ReceiveNextEventCommon + 310
9 com.apple.HIToolbox 0x7fff831305d8
BlockUntilNextEventMatchingListInMode + 59
10 com.apple.AppKit0x7fff8500229e _DPSNextEvent +
708
11 com.apple.AppKit0x7fff85001bed -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
12 com.apple.AppKit0x7fff84fc78d3 -[NSApplication
run] + 395
13 com.apple.WebKit.PluginHost 0x000117d734c1 0x117d6f000 +
17601
14 com.apple.WebKit.PluginHost 0x000117d70a94 0x117d6f000 +
6804
Thread 1: Dispatch queue: com.apple.libdispatch-manager
0 libSystem.B.dylib 0x7fff85cd808a kevent + 10
1 libSystem.B.dylib 0x7fff85cd9f5d
_dispatch_mgr_invoke + 154
2 libSystem.B.dylib 0x7fff85cd9c34
_dispatch_queue_invoke + 185
3 libSystem.B.dylib 0x7fff85cd975e
_dispatch_worker_thread2 + 252
4 libSystem.B.dylib 0x7fff85cd9088
_pthread_wqthread + 353
5 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread
+ 13
Thread 2:
0 libSystem.B.dylib 0x7fff85cd8eaa
__workq_kernreturn + 10
1 libSystem.B.dylib 0x7fff85cd92bc
_pthread_wqthread + 917
2 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread
+ 13
Thread 3:
0 libSystem.B.dylib 0x7fff85cd8eaa
__workq_kernreturn + 10
1 libSystem.B.dylib 0x7fff85cd92bc
_pthread_wqthread + 917
2 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread
+ 13
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0xbbadbeef rbx: 0x000102285894 rcx:
0x000102295d27 rdx: 0x
rdi: 0x000100412e48 rsi: 0x rbp:
0x7fff5fbfe5f0 rsp: 0x7fff5fbfe5e0
r8: 0x7fff70b19748 r9: 0x000102296ab0 r10:
0x000102295d18 r11: 0x000102296ab0
r12:
Re: [webkit-dev] Layout Tests Crashing on Snow Leopard
I wonder if its related to Safari 5.0.1. The bots are seeing
failures, but not nearly a many as I'm seeing. Adam Barth is also
seeing a whole bunch of plugin-related crashes.
On Mon, Aug 23, 2010 at 3:09 PM, Simon Fraser simon.fra...@apple.com wrote:
FYI, I was seeing this too over the weekend.
Simon
On Aug 23, 2010, at 2:54 PM, Eric Seidel wrote:
This is gonna kill me. Does no one else run the layout tests...?
On Mon, Aug 23, 2010 at 1:43 PM, Ryosuke Niwa rn...@webkit.org wrote:
FYI, there was a series of plugin patches committed this weekend:
http://trac.webkit.org/search?q=pluginnoquickjump=1changeset=onwiki=on
Best,
Ryosuke Niwa
Software Engineer
Google Inc.
On Mon, Aug 23, 2010 at 1:14 PM, Eric Seidel e...@webkit.org wrote:
Started yesterday. A bunch of layout tests crash in some ASSERT in
WebKitPluginHost / testnetscapeplugin.
// Entry points
extern C
NPError STDCALL NP_Initialize(NPNetscapeFuncs *browserFuncs)
{
#if XP_WIN
// Simulate Flash and QuickTime's behavior of crashing when
NP_Initialize is called before NP_GetEntryPoints.
if (!getEntryPointsWasCalled)
CRASH();
#elif XP_MACOSX
// Simulate Silverlight's behavior of crashing when
NP_GetEntryPoints is called before NP_Initialize.
if (getEntryPointsWasCalled)
CRASH(); // THIS IS THE CRASH WE'RE HITTING.
#endif
Seems someone borked something this weekend. Thoughts?
I'm also happy to file a bug.
ccing plugin folks.
-eric
Process: WebKitPluginHost [28100]
Path:
/System/Library/Frameworks/WebKit.framework/WebKitPluginHost.app/Contents/MacOS/WebKitPluginHost
Identifier: com.apple.WebKit.PluginHost
Version: 6533 (6533.13)
Build Info: WebKitPluginHost-75331300~7
Code Type: X86-64 (Native)
Parent Process: WebKitPluginAgent [28095]
Date/Time: 2010-08-23 13:11:23.797 -0700
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6
Interval Since Last Report: 78444 sec
Crashes Since Last Report: 209
Per-App Interval Since Last Report: 10302 sec
Per-App Crashes Since Last Report: 20
Anonymous UUID: A1F25920-3E56-4095-8E69-3069478CA352
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xbbadbeef
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.testnetscapeplugin 0x0001022858b0 NP_Initialize +
28 (main.cpp:64)
1 com.apple.WebKit.PluginHost 0x000117d82188 0x117d6f000 +
78216
2 com.apple.WebKit.PluginHost 0x000117d769e1 0x117d6f000 +
31201
3 com.apple.WebKit.PluginHost 0x000117d71ad3 0x117d6f000 +
10963
4 com.apple.CoreFoundation 0x7fff80817e09
__CFRunLoopDoBlocks + 297
5 com.apple.CoreFoundation 0x7fff807da906 __CFRunLoopRun
+ 3046
6 com.apple.CoreFoundation 0x7fff807d984f
CFRunLoopRunSpecific + 575
7 com.apple.HIToolbox 0x7fff8313091a
RunCurrentEventLoopInMode + 333
8 com.apple.HIToolbox 0x7fff8313071f
ReceiveNextEventCommon + 310
9 com.apple.HIToolbox 0x7fff831305d8
BlockUntilNextEventMatchingListInMode + 59
10 com.apple.AppKit 0x7fff8500229e _DPSNextEvent +
708
11 com.apple.AppKit 0x7fff85001bed -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
12 com.apple.AppKit 0x7fff84fc78d3 -[NSApplication
run] + 395
13 com.apple.WebKit.PluginHost 0x000117d734c1 0x117d6f000 +
17601
14 com.apple.WebKit.PluginHost 0x000117d70a94 0x117d6f000 +
6804
Thread 1: Dispatch queue: com.apple.libdispatch-manager
0 libSystem.B.dylib 0x7fff85cd808a kevent + 10
1 libSystem.B.dylib 0x7fff85cd9f5d
_dispatch_mgr_invoke + 154
2 libSystem.B.dylib 0x7fff85cd9c34
_dispatch_queue_invoke + 185
3 libSystem.B.dylib 0x7fff85cd975e
_dispatch_worker_thread2 + 252
4 libSystem.B.dylib 0x7fff85cd9088
_pthread_wqthread + 353
5 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread
+ 13
Thread 2:
0 libSystem.B.dylib 0x7fff85cd8eaa
__workq_kernreturn + 10
1 libSystem.B.dylib 0x7fff85cd92bc
_pthread_wqthread + 917
2 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread
+ 13
Thread 3:
0 libSystem.B.dylib 0x7fff85cd8eaa
__workq_kernreturn + 10
1 libSystem.B.dylib 0x7fff85cd92bc
_pthread_wqthread + 917
2 libSystem.B.dylib 0x7fff85cd8f25 start_wqthread
+ 13
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0xbbadbeef rbx: 0x000102285894 rcx:
0x000102295d27 rdx:
Re: [webkit-dev] Layout bug with table align=center?
On Mon, 2010-08-23 at 15:09 -0700, Eric Seidel wrote: A reduction would be useful. My general approach is: file a bug first, ask questions later. :) Once we have a bug, we can attach a reduction and work towards resolution (even if that means no change to WebKit). https://bugs.webkit.org/show_bug.cgi?id=44462 Reduction: https://bug-44462-attachments.webkit.org/attachment.cgi?id=65173 Not sure if this reduction is good enough, but at least it's rather small and shares the (probably) broken behaviour. Hope that helps. Thanks, Martin 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
