Re: [webkit-dev] Serialize DOM to file
hi you can get the root node of DOM and use XMLSerializer::serializeToString regards zaheer On Thu, Jun 4, 2009 at 11:11 AM, Meryl Silverburgh < silverburgh.me...@gmail.com> wrote: > Hi, > > Is there any debug code/example code snippet to serialize the DOM to a fie? > > Thank you for any tip. > ___ > 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] Serialize DOM to file
Hi, Is there any debug code/example code snippet to serialize the DOM to a fie? Thank you for any tip. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
Addendum: .) IE does NOT honor 'display: ruby' Cheers, Roland On Wed, Jun 3, 2009 at 6:30 PM, Roland Steiner wrote: > Hi Dave, > > thanks for the feedback! To answer some of the questions you raised: > > .) There certainly is a demand for this feature in Japan, China, and other > countries. The only browser that natively supports ruby currently is IE, so > I would assume most of the pages that use ruby today are written at least > with IE in mind. Therefore, the base line would be compatibility with that, > which boils down to implementing the HTML5 spec. > > There are also apparently still be some pages left that adhere to a very > early ruby draft (http://www.w3.org/TR/1999/WD-ruby-19990322/), but I'm > not sure it's worth extra work to try to support that (haven't looked at > that in great detail yet). > > .) IE (at least IE8) honors 'float' and 'position' on ruby elements, and > also 'display:block' works as expected. > > .) Multiple runs within a single element are rendered correctly in > IE (which I would suppose is the original reason for their inclusion in > HTML5). IE also line-breaks those runs. > > > Cheers, > > Roland > > > > On Wed, Jun 3, 2009 at 5:39 PM, David Hyatt wrote: > >> On Jun 3, 2009, at 7:33 PM, David Hyatt wrote: >> >> >>> The CSS3 draft is clearly very incomplete and not ready for primetime, so >>> the more I look at it, the more I'm thinking we should maybe just limit >>> ourselves to an HTML5/IE-compatible implementation. >>> >>> >>> >> In other words I'm thinking we should just make the only way you >> can make these things, and not necessarily support the CSS stuff yet. I am >> concerned about crashes related to crazy interactions of all these new ruby >> display types (every time we add new display types the render tree >> complexity goes up, since any element can implement the display type and be >> put inside any other display type). >> >> For example, I don't even think display:ruby should be the right way to >> make a ruby in CSS, since a ruby clearly can be either block-level or >> inline-level. You need two display types and not just one. >> >> How the ruby box model works in CSS is woefully underspecified as well. >> >> For now we could just hardcode the creation of the specific renderers when >> the tag names are encountered. This has the added benefit of allowing you >> to make a ruby inline or block by changing the display type. I'd suggest >> testing in IE in fact to see what happens when you float/position a ruby or >> when you specifically put "display:block" on a ruby. >> >> dave >> (hy...@apple.com) >> >> >> >> >> >> ___ >> 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] Ruby design document
Hi Dave, thanks for the feedback! To answer some of the questions you raised: .) There certainly is a demand for this feature in Japan, China, and other countries. The only browser that natively supports ruby currently is IE, so I would assume most of the pages that use ruby today are written at least with IE in mind. Therefore, the base line would be compatibility with that, which boils down to implementing the HTML5 spec. There are also apparently still be some pages left that adhere to a very early ruby draft (http://www.w3.org/TR/1999/WD-ruby-19990322/), but I'm not sure it's worth extra work to try to support that (haven't looked at that in great detail yet). .) IE (at least IE8) honors 'float' and 'position' on ruby elements, and also 'display:block' works as expected. .) Multiple runs within a single element are rendered correctly in IE (which I would suppose is the original reason for their inclusion in HTML5). IE also line-breaks those runs. Cheers, Roland On Wed, Jun 3, 2009 at 5:39 PM, David Hyatt wrote: > On Jun 3, 2009, at 7:33 PM, David Hyatt wrote: > > >> The CSS3 draft is clearly very incomplete and not ready for primetime, so >> the more I look at it, the more I'm thinking we should maybe just limit >> ourselves to an HTML5/IE-compatible implementation. >> >> >> > In other words I'm thinking we should just make the only way you can > make these things, and not necessarily support the CSS stuff yet. I am > concerned about crashes related to crazy interactions of all these new ruby > display types (every time we add new display types the render tree > complexity goes up, since any element can implement the display type and be > put inside any other display type). > > For example, I don't even think display:ruby should be the right way to > make a ruby in CSS, since a ruby clearly can be either block-level or > inline-level. You need two display types and not just one. > > How the ruby box model works in CSS is woefully underspecified as well. > > For now we could just hardcode the creation of the specific renderers when > the tag names are encountered. This has the added benefit of allowing you > to make a ruby inline or block by changing the display type. I'd suggest > testing in IE in fact to see what happens when you float/position a ruby or > when you specifically put "display:block" on a ruby. > > dave > (hy...@apple.com) > > > > > > ___ > 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] Ruby design document
On Jun 3, 2009, at 7:33 PM, David Hyatt wrote: The CSS3 draft is clearly very incomplete and not ready for primetime, so the more I look at it, the more I'm thinking we should maybe just limit ourselves to an HTML5/IE-compatible implementation. In other words I'm thinking we should just make the only way you can make these things, and not necessarily support the CSS stuff yet. I am concerned about crashes related to crazy interactions of all these new ruby display types (every time we add new display types the render tree complexity goes up, since any element can implement the display type and be put inside any other display type). For example, I don't even think display:ruby should be the right way to make a ruby in CSS, since a ruby clearly can be either block-level or inline-level. You need two display types and not just one. How the ruby box model works in CSS is woefully underspecified as well. For now we could just hardcode the creation of the specific renderers when the tag names are encountered. This has the added benefit of allowing you to make a ruby inline or block by changing the display type. I'd suggest testing in IE in fact to see what happens when you float/position a ruby or when you specifically put "display:block" on a ruby. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
On Jun 3, 2009, at 7:15 PM, Maciej Stachowiak wrote: On Jun 3, 2009, at 5:12 PM, Peter Kasting wrote: On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner > wrote: However, if the consensus is that we should rather take those objects out (Ian Hickson doesn't seem to be a fan of complex ruby, either), then of course I can remove them from the code. The resulting object model would probably look like: ruby : RenderInline or RenderBlock (inline-block) ruby-run : RenderBlock (inline-block with inline children) - 1 or more ruby-base : RenderInline -> InlineFlowBox - 1 ruby-text : RenderInline -> InlineFlowBox - 0 or 1 (could even allow 2, for both 'before' and 'after' positions) Seems like it wouldn't be hard to add the complexity in later (as a second pass) if we decide there's value there; in the meantime, writing the simplest possible implementation has testing and code readability benefits. I suggest sticking with the simple stuff that's sufficient to do HTML5 as a first pas. When everything is in, tested and working, you can evaluate if more complex support a la the current CSS3 spec is a good idea. If so it'd probably make sense to get HTMLx (whatever x is by then, perhaps 6) to agree so that other browsers are all on board too. I had the same reaction. Handling simple ruby seems like a good first step, even if we decide later that we want to add complex support. I guess what I'm getting at is that if you remove the complex ruby concept of being able to break across multiple lines, then couldn't simple ruby could just be implemented using slightly specialized table subclasses? I also think it's good to question what is in both of these specs rather than simply implementing them. I don't think there is any serious implementation of yet, so we have the freedom I think to question just about everything. For example, is it an IE compatibility constraint that you can have one or more groups of annotated phrasing content inside a ? If it is, then I guess we're stuck with it, but if that's something Ian invented I'm inclined to push back on it and limit to 1. I think knowing the high level reason why we're implementing in WebKit would be helpful. Is the primary goal compatibility with IE? Is it to implement HTML5? The CSS3 draft is clearly very incomplete and not ready for primetime, so the more I look at it, the more I'm thinking we should maybe just limit ourselves to an HTML5/IE-compatible implementation. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
Ok, in that case should I also remove the code and constants for the complex-ruby-specific CSS3 properties and HTML 'span' attribute, or should I leave them in the code (and they just get ignored)? Cheers, Roland On Wed, Jun 3, 2009 at 5:15 PM, Maciej Stachowiak wrote: > > On Jun 3, 2009, at 5:12 PM, Peter Kasting wrote: > > On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner > wrote: > >> However, if the consensus is that we should rather take those objects out >> (Ian Hickson doesn't seem to be a fan of complex ruby, either), then of >> course I can remove them from the code. The resulting object model would >> probably look like: >> >> ruby : RenderInline or RenderBlock (inline-block) >> ruby-run : RenderBlock (inline-block with inline children) - 1 or >> more >> ruby-base : RenderInline -> InlineFlowBox - 1 >> ruby-text : RenderInline -> InlineFlowBox - 0 or 1 (could even >> allow 2, for both 'before' and 'after' positions) >> > > Seems like it wouldn't be hard to add the complexity in later (as a second > pass) if we decide there's value there; in the meantime, writing the > simplest possible implementation has testing and code readability benefits. > I suggest sticking with the simple stuff that's sufficient to do HTML5 as a > first pas. When everything is in, tested and working, you can evaluate if > more complex support a la the current CSS3 spec is a good idea. If so it'd > probably make sense to get HTMLx (whatever x is by then, perhaps 6) to agree > so that other browsers are all on board too. > > > I had the same reaction. Handling simple ruby seems like a good first step, > even if we decide later that we want to add complex support. > > Cheers, > Maciej > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
On Jun 3, 2009, at 5:12 PM, Peter Kasting wrote: On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner > wrote: However, if the consensus is that we should rather take those objects out (Ian Hickson doesn't seem to be a fan of complex ruby, either), then of course I can remove them from the code. The resulting object model would probably look like: ruby : RenderInline or RenderBlock (inline-block) ruby-run : RenderBlock (inline-block with inline children) - 1 or more ruby-base : RenderInline -> InlineFlowBox - 1 ruby-text : RenderInline -> InlineFlowBox - 0 or 1 (could even allow 2, for both 'before' and 'after' positions) Seems like it wouldn't be hard to add the complexity in later (as a second pass) if we decide there's value there; in the meantime, writing the simplest possible implementation has testing and code readability benefits. I suggest sticking with the simple stuff that's sufficient to do HTML5 as a first pas. When everything is in, tested and working, you can evaluate if more complex support a la the current CSS3 spec is a good idea. If so it'd probably make sense to get HTMLx (whatever x is by then, perhaps 6) to agree so that other browsers are all on board too. I had the same reaction. Handling simple ruby seems like a good first step, even if we decide later that we want to add complex support. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner wrote: > However, if the consensus is that we should rather take those objects out > (Ian Hickson doesn't seem to be a fan of complex ruby, either), then of > course I can remove them from the code. The resulting object model would > probably look like: > > ruby : RenderInline or RenderBlock (inline-block) > ruby-run : RenderBlock (inline-block with inline children) - 1 or > more > ruby-base : RenderInline -> InlineFlowBox - 1 > ruby-text : RenderInline -> InlineFlowBox - 0 or 1 (could even > allow 2, for both 'before' and 'after' positions) > Seems like it wouldn't be hard to add the complexity in later (as a second pass) if we decide there's value there; in the meantime, writing the simplest possible implementation has testing and code readability benefits. I suggest sticking with the simple stuff that's sufficient to do HTML5 as a first pas. When everything is in, tested and working, you can evaluate if more complex support a la the current CSS3 spec is a good idea. If so it'd probably make sense to get HTMLx (whatever x is by then, perhaps 6) to agree so that other browsers are all on board too. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
[+Ian] Hi Dave, I just added all elements from both specs, as it was easy and straightforward enough. Code-wise, the RubyBaseContainer & RubyTextContainer objects don't add much complexity (the multiple runs within a single ruby element from the HTML5 spec pose more of a challenge, tbh). Now, I don't know of any concrete use cases, but I still left them in for the time being, for the following, admittedly rather flimsy, reasons: .) being able to have ruby text both in before and after positions seems like it could be useful .) it seemed useful to have a wrapping block element in case the input is malformed, has extraneous elements, or tries to do cute tricks (e.g., adding line breaks). *) .) the Firefox plugin honors them .) there are several sites that detail how to use CSS inline-table to get complex ruby rendering, so I thought that perhaps there are actual use cases out there after all *) If those elements are removed, the number of box model objects are reduced, but the code required for layouting and error handling might get rather more involved. However, if the consensus is that we should rather take those objects out (Ian Hickson doesn't seem to be a fan of complex ruby, either), then of course I can remove them from the code. The resulting object model would probably look like: ruby : RenderInline or RenderBlock (inline-block) ruby-run : RenderBlock (inline-block with inline children) - 1 or more ruby-base : RenderInline -> InlineFlowBox - 1 ruby-text : RenderInline -> InlineFlowBox - 0 or 1 (could even allow 2, for both 'before' and 'after' positions) Cheers, Roland On Wed, Jun 3, 2009 at 3:43 PM, David Hyatt wrote: > On Jun 3, 2009, at 4:59 PM, Roland Steiner wrote: > > Hi Peter, >> >> You're right, that was an oversight, I added the reference to the >> introduction part, and highlighted the differences as you mentioned. >> >> My current implementation aims to be forward-compatible with both HTML5 >> and CSS3, which seems to be rather straightforward from the pure object >> model. It allows for several runs as per the HTML5 spec, and some variations >> in the positioning as per the CSS3 spec. I'm not currently implementing CSS3 >> complex ruby, line stacking or ruby overhang. >> > > It seems like the design could be simplified considerably if we just say > we're not going to do complex ruby. Given that it's not in HTML5 and that > IE doesn't do it, is complex ruby something we even want to worry about? > > dave > (hy...@apple.com) > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
On Jun 3, 2009, at 4:59 PM, Roland Steiner wrote: Hi Peter, You're right, that was an oversight, I added the reference to the introduction part, and highlighted the differences as you mentioned. My current implementation aims to be forward-compatible with both HTML5 and CSS3, which seems to be rather straightforward from the pure object model. It allows for several runs as per the HTML5 spec, and some variations in the positioning as per the CSS3 spec. I'm not currently implementing CSS3 complex ruby, line stacking or ruby overhang. It seems like the design could be simplified considerably if we just say we're not going to do complex ruby. Given that it's not in HTML5 and that IE doesn't do it, is complex ruby something we even want to worry about? dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] About Win32/Cairo port
Hi Everyone, 2009/5/15 Joonghoon Kim : > 3) I can't see context-menu localized strings, for > CreateBundle() with WebKit.resources/ fails. It's due > to Open CF-Lite. _CFGetFileProperties() returns -1 > for createFileA() fails. > GetLastError() reports ERROR_ACCESS_DENIED. > Anyone know why this happens? I tracked down the cause of this problem. Updated DLL's are now available from my iDisk (http://files.me.com/bfulgham/iay8p5), and the SVN sources at the OpenCFLite (http://sourceforge.net/projects/opencflite/) project include this fix. We will produce an official download in a few days. The problem turned out to be incorrect file handling. For reasons locked in Microsoft's dark underbelly, the CreateFile call requires that you pass the flag FILE_FLAG_BACKUP_SEMANTICS (instead of the more obvious-seeming NULL used in all the example programs.) If you use this flag, then it will create a file handle to the directory. Correcting this bug opened up a ton of functionality in the Cairo port, including access to the web inspector and a myriad of other right-click (contextual) menu features. Thanks for making me feel guilty enough to fix this -- I had no idea how much cool stuff I was missing because of this long-standing bug. :-) Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
Hi Peter, You're right, that was an oversight, I added the reference to the introduction part, and highlighted the differences as you mentioned. My current implementation aims to be forward-compatible with both HTML5 and CSS3, which seems to be rather straightforward from the pure object model. It allows for several runs as per the HTML5 spec, and some variations in the positioning as per the CSS3 spec. I'm not currently implementing CSS3 complex ruby, line stacking or ruby overhang. Thanks, Roland On Wed, Jun 3, 2009 at 2:17 PM, Peter Kasting wrote: > On Wed, Jun 3, 2009 at 2:12 PM, Roland Steiner > wrote: > >> I am in the process of implementing ruby (text annotations, mainly used in >> East-Asian text), and would welcome if folks could give me feedback on my >> design document, esp. regarding the rendering/layouting: >> >> http://docs.google.com/View?id=dcgd8hk6_0ccsw4td4 > > > Your doc mentions the CSS3 ruby specs, but not the HTML5 specs (e.g. > http://www.whatwg.org/specs/web-apps/current-work/#the-ruby-element ). It > would be good to link to the HTML5 doc, and perhaps note differences between > the specs (I suggest implementing HTML5 in any cases where HTML5 and CSS3 > differ). > > PK > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] stack alignment bug
Zoltan, I filed a bug here: https://bugs.webkit.org/show_bug.cgi?id=26164 Stack is originally aligned then jit code destroys it; and, some data structure or point to double is not aligned and I'm still trying to find where they are. I'm not sure how the fake stack would be, would you mind explains a bit more? Did you face same problem? Thanks also for your articles that gives new ideas. rgds joe --- On Wed, 6/3/09, Zoltan Herczeg wrote: > From: Zoltan Herczeg > Subject: Re: [webkit-dev] stack alignment bug > To: "x yz" > Cc: webkit-dev@lists.webkit.org > Date: Wednesday, June 3, 2009, 7:35 PM > Hi, > > true, some architectures have strict policies for stack > handling. Perhaps > the worst one is PowerPC with its organized stack frame > (back chains, > pre-defined register save areas, etc). I think a fake stack > pointer for > JIT can solve the x86 compatibility problem. > > 1) allocate enough aligned stack space for the worst case > when you enter > to JIT > 2) the fake stack pointer should use this pre-allocated > stack frame. > > Zoltan > > > I don't know how to file bug so I posted here. > > In privateCompileCTIMachineTrampolines() there are > multiple align() to > > align code on 16byte margin, yet, the stack can be put > on 32bit margin > > that causes crush. > > Suppose original stack is aligned to 8/16bytes, the > above function > > frequently pop/push regT3 that makes stack > mis-aligned. Then int to double > > conversion uses stack that will fail. > > rgds > > joe > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ruby design document
On Wed, Jun 3, 2009 at 2:12 PM, Roland Steiner wrote: > I am in the process of implementing ruby (text annotations, mainly used in > East-Asian text), and would welcome if folks could give me feedback on my > design document, esp. regarding the rendering/layouting: > > http://docs.google.com/View?id=dcgd8hk6_0ccsw4td4 Your doc mentions the CSS3 ruby specs, but not the HTML5 specs (e.g. http://www.whatwg.org/specs/web-apps/current-work/#the-ruby-element ). It would be good to link to the HTML5 doc, and perhaps note differences between the specs (I suggest implementing HTML5 in any cases where HTML5 and CSS3 differ). PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Ruby design document
Hi all, I am in the process of implementing ruby (text annotations, mainly used in East-Asian text), and would welcome if folks could give me feedback on my design document, esp. regarding the rendering/layouting: http://docs.google.com/View?id=dcgd8hk6_0ccsw4td4 Thanks, Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] stack alignment bug
Hi, true, some architectures have strict policies for stack handling. Perhaps the worst one is PowerPC with its organized stack frame (back chains, pre-defined register save areas, etc). I think a fake stack pointer for JIT can solve the x86 compatibility problem. 1) allocate enough aligned stack space for the worst case when you enter to JIT 2) the fake stack pointer should use this pre-allocated stack frame. Zoltan > I don't know how to file bug so I posted here. > In privateCompileCTIMachineTrampolines() there are multiple align() to > align code on 16byte margin, yet, the stack can be put on 32bit margin > that causes crush. > Suppose original stack is aligned to 8/16bytes, the above function > frequently pop/push regT3 that makes stack mis-aligned. Then int to double > conversion uses stack that will fail. > rgds > joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] does jit uses self-modifying code?
Hi,
I don't know what is happening there, but since JSObject->put() is
connected with property caching, and property caching does use
self-modifying code, perhaps you should look around at
JITStubs::tryCachePutByID.
I wrote a little text about property caching in JIT last week. You can
find it here: http://webkit.sed.hu/node/18
Zoltan
> Hi,
> Appreciate for help. If the answer is yes may I know here are they.
>
> MIPS webkit-1.1.1, cmd using: jsc shell.js
> In JavaScriptCore/runtime/JSObject.h:527
> asCell()->put(exec, propertyName, value, slot);
> this one will call a function, yet the function entry address got is
> invalid.
> 0x006b17ec527 asCell()->put(exec, propertyName, value, slot);
> (gdb) x/10i $pc
> 0x6b17ec
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+196>:
> lw gp,24(s8)
> 0x6b17f0
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+200>:
> movev1,v0
> 0x6b17f4
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+204>:
> lw a0,0(v1)
> 0x6b17f8
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+208>:
> lw a3,60(s8)
> 0x6b17fc
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+212>:
> lw v0,64(s8)
> 0x6b1800
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+216>:
> sw v0,16(sp)
> 0x6b1804
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+220>:
> lw t9,68(a0)
> 0x6b1808
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+224>:
> movea0,v1
> 0x6b180c
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+228>:
> lw a1,52(s8)
> 0x6b1810
> <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+232>:
> lw a2,56(s8)
>
>
> the entry got is $t9=0x2bc that is wrong.
> rgds
> joe
> --- On Sat, 5/9/09, x yz wrote:
>
>> From: x yz
>> Subject: Re: [webkit-dev] random seg fault on MIPS platform
>> To: webkit-dev@lists.webkit.org
>> Date: Saturday, May 9, 2009, 1:24 AM
>>
>> Hi,
>> >50% of time when I use gdb then arith functions works.
>> it may fail at 1st, or 3rd try, and 100% fail w/o gdb. I
>> just use jsc to do sth like 5%2, 5*3, etc.
>>
>> It is with in call of ctiTrampoline(code, registerFile,
>> callFrame, jexception, pptr, globalData), jit code executed
>> and may be in last line of op_mod() when it tried to convert
>> result, gdb simply shows segment fault, or PC stops at an
>> non-coded area, w/o gdb it says invalid instruction. It may
>> be in JITcell,h in
>> ALWAYS_INLINE double JSValuePtr::toNumber(ExecState* exec)
>> const
>> {
>> return
>> JSImmediate::isImmediate(asValue()) ?
>> JSImmediate::toDouble(asValue()) :
>> asCell()->toNumber(exec);
>> }
>> due to exec pointer wrong.
>>
>> if I continue to use same arithmatic function the generated
>> jit code won't call op_mod() unless it is the 1st time, I
>> think it is because jit code is already there. If another
>> thread handles the real operation and not sync'd then it may
>> be the case. Note I use BCM chip with two CPUs - BCM
>> customized SMP and BCM Linux.
>>
>> when it works, before and after ctiTrampoline() the stack
>> is balanced and registers are ok. where is the jit stack and
>> how to check its balance?
>>
>> when it fails, stacks shows we are nearby jit code - the
>> code w/o calling OP_mod() CPP function as it fails at 3rd
>> try. But PC points to a data structure:
>> any comments? thanks a lot!!
>> rgds
>> joe
>>
>> //
>> (gdb) c
>> Continuing.
>>
>> Program received signal SIGILL, Illegal instruction.
>> 0x2aacd000 in ?? ()
>> (gdb) where
>> #0 0x2aacd000 in ?? ()
>> warning: GDB can't find the start of the function at
>> 0x2aacd000.
>> ...
>> #1 0x2aacd000 in ?? ()
>> warning: GDB can't find the start of the function at
>> 0x2aaccfff.
>> Backtrace stopped: previous frame identical to this frame
>> (corrupt stack?)
>> (gdb) backtrace
>> #0 0x2aacd000 in ?? ()
>> #1 0x2aacd000 in ?? ()
>> Backtrace stopped: previous frame identical to this frame
>> (corrupt stack?)
>> (gdb) p/x $sp
>> $1 = 0x7fa439d8
>> (gdb) p/x $pc
>> $2 = 0x2aacd000
>> (gdb) p/x $t9
>> $3 = 0x2aac9588
>> (gdb) x/10i $t9 = jit code, no actual call to op_mod() cpp
>> function
>> 0x2aac9588: sw
>> ra,-40(s5)
>> 0x2aac958c: lui s7,0x0
>> 0x2aac9590: ori
>> s7,s7,0xa
>> 0x2aac9594: sw
>> s7,0(s5)
>> 0x2aac9598: lui s7,0x0
>> 0x2aac959c: ori
>> s7,s7,0xa
>> 0x2aac95a0: sw
>> s7,8(s5)
>> 0x2aac95a4: lui v0,0x0
>> 0x2aac95a8: ori
>> v0,v0,0xa
>> 0x2aac95ac: sw
>> v0,32(s5)
>> (gdb)
>> 0x2aac95b0: lui
>> v0,0x
>> 0x2aac95b4: ori
>> v0,v0,0x
>> 0x2aac95b8: sw
>> v0,32(s5)
>> 0x2aac95bc:
Re: [webkit-dev] Does anyone know why http/tests/appcache/fallback.html is failing?
I'm sorry. This was my fault. I landed this patch, but I didn't think the patch caused the test failure because I mistaken believed the patch only added a new test. I didn't realize the patch modified a PHP file shared with this test. In the future, I'll be more apt to revert patches to try to fix redness. Apologies, Adam 2009/6/2 David Levin : > Based on this: http://build.webkit.org/waterfall?last_time=1243932987 > It looks like http://trac.webkit.org/changeset/44350 caused the test to fail. > > On Tue, Jun 2, 2009 at 10:39 PM, Darin Adler wrote: >> >> This test is failing on all the Mac buildbots. >> >> --- layout-test-results/http/tests/appcache/fallback-expected.txt >> 2009-06-02 20:27:35.0 -0700 >> +++ layout-test-results/http/tests/appcache/fallback-actual.txt 2009-06-02 >> 20:27:35.0 -0700 >> @@ -2,5 +2,6 @@ >> >> Should say SUCCESS: >> >> -SUCCESS >> +FAIL: Loading an URL from fallback namespace when network is disabled >> returned unexpected response >> +FAILURE >> >> Does anyone know why? Can we roll out the change that caused this to start >> failing? Or fix it? >> >> -- Darin >> >> ___ >> 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] Question about detach Render Tree from DOM
Hi, I am reading webcore rendering basic, http://webkit.org/blog/114/webcore-rendering-i-the-basics/ It talks about detaching Render Tree from DOM. My question is after I detached Render Tree from DOM, is the DOM still a 'valid' DOM? meaning, can I still use JavaScript to modify the DOM and webkit won't crash (since the RenderTree is already detached)? Thank you. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
