Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined?

[Zoltan Herczeg]

Hi,

they generate instructions, which size is known in advance.

Think about the following sequence:
hotPathBegin:
  mov regX, 32bit_const <- 6 bytes (*) (**)
  add regX, regY <- 2 bytes
  jo 32bit_addr <- 5 bytes (*)

* (Note) : these instructions will be modified during runtime.

** (Note) : there is a short form for "mov regX, 8bit_const", which length
is only 3 bytes, but they force the longer version in such cases to keep
the size of the instruction.

As you can see, the address of "jo" is always (hotPathBegin + 6 + 2). They
simply introduce a new constant: patchOffsetXXX = 8, and use this constant
to access the "jo" instruction later.

In ARM we can't rely on such constant, because the constant pool can be
placed after any instruction.

hotPathBegin:
  ldr rX, [pc + const_pool_addr] ; 32 bit const
  [...] <- the const pool can be placed here
  add rX, rX, rY
  [...] <- the const pool can be placed here
hotPath2:
  ldr pc, [pc + const_pool_addr] ; 32 bit target address

We need to store both pointers (hotPathBegin and hotPath2).

Zoltan

> Zoltan,
> Thanks for reply, I'm trying to understand your example. But,X86
> instruction size is from 1 to 17bytes, not constant. I may misunderstand
> your comments?
> Many X86 instruction can have imm32 at the end, thus this pointer can be
> used for patch as well as next address after call. Does Arm have similar
> things? or else you still need to figure out why
> "patchOffsetOpCallCompareToJump = 9;"? may be some instruction lengths
> relates to the 9?
> rgds
> joe
>
>
> --- On Wed, 3/4/09, Zoltan Herczeg  wrote:
>
>> From: Zoltan Herczeg 
>> Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset*
>> constant determined?
>> To: webkit-dev@lists.webkit.org
>> Date: Wednesday, March 4, 2009, 3:45 AM
>> On x86, the size of the instructions are fixed. If you want
>> to access
>> multiple instructions in the instruction stream, you only
>> need to store
>> the address of the first one, and can access the others by
>> their relative
>> address. This saves a little memory.
>>
>> Example (see JIT::linkCall):
>>   instruction at callLinkInfo->hotPathBegin: points to
>> callee comparison
>>   instruction at
>> callLinkInfo->hotPathBegin +
>> patchOffsetOpCallCompareToJump:
>>points to the slow case entry jump
>>
>> Zoltan
>>
>> > in jit.h, for example:
>> > static const int
>> patchOffsetOpCallCompareToJump = 9;
>> > static const int patchOffsetPutByIdStructure =
>> 7;
>> > static const int
>> patchOffsetPutByIdPropertyMapOffset = 22;
>> > static const int
>> patchOffsetGetByIdBranchToSlowCase = 13;
>> > thanks for help, I'm stucked here now.
>> > joe
>> >
>> >
>> > --- On Sat, 2/28/09, Gavin Barraclough
>>  wrote:
>> >
>> >> From: Gavin Barraclough
>> 
>> >> Subject: Re: [webkit-dev] want to port JIT to MIPS
>> - JIT reg usage clean
>> >> up?
>> >> To: "WebKit Development"
>> 
>> >> Date: Saturday, February 28, 2009, 12:19 PM
>> >> On Feb 27, 2009, at 4:55 PM, x yz wrote:
>> >>
>> >> > The regTx seems to be working registers here,
>> yet
>> >> their definition are regparm(3) registers for
>> function
>> >> arugments. Such usage would cause conflict on
>> other
>> >> platforms. May I suggest that we use individual
>> defined set
>> >> of regs for func i/o argument and working?
>> >>
>> >> First up, I think you're getting slightly
>> confused
>> >> about regparm(3).  This is not used anywhere in
>> the JS
>> >> language JIT, only in WREC.  In some
>> configurations of the
>> >> JIT we use fastcall semantics on x86... but none
>> of this is
>> >> really relevant to MIPS.  Just ignore all this.
>> Stick to
>> >> the default MIPS ABI for stub functions.
>> >>
>> >> Reading between the lines, I'm guessing your
>> concern
>> >> here is that in setting up arguments for a JIT
>> stub call you
>> >> may trample the JIT's temporary registers?  If
>> so, I
>> >> think you need to look at the argument passing
>> more closely.
>> >>  The mechanisms to pass arguments to stub
>> functions pass all
>> >> arguments in memory – typically passing a single
>> pointer
>> >> to the stub functions, which can be used to
>> retrieve the
>> >> arguments.  This pointer argument can be set up
>> immediately
>> >> prior to the call, so it does not interfere with
>> the regT?
>> >> temporaries.  We follow this pattern on x86-64,
>> where the
>> >> ABI is typically to pass arguments in registers.
>> You cannot
>> >> trivially change the way this works, since the
>> argument
>> >> pointer is used for other purposes too (e.g.
>> retrieving the
>> >> arguments passed into the JIT code from within the
>> stubs).
>> >>
>> >> We strongly prefer small, simple, incremental
>> changes.  A
>> >> patch that tried to both port the JIT to a new
>> platform and
>> >> to introduce a new argument passing interface to
>> the JIT
>> >> stub functions sounds unlikely to get anywhere (a
>> patch
>> >> porting the JIT to a new platform is on its own
>> very likely

Re: [webkit-dev] Detecting paste with cmd-v on Mac

[Alexey Proskuryakov]

03.03.2009, в 23:21, Rush Manbert написал(а):

I checked the values of the DOM even modifiers alyKey, ctrlKey, and  
shiftKey and they are all false on a cmd-v paste


That's expected, Cmd maps to metaKey.


Is the difference between Safari and WebKit expected?



Yes, WebKit preserves legacy keyboard event behavior for applications  
linked against old SDK, see . The behavior was changed to be IE-compatible in version 3.1.


I expect that checking for evt.metaKey will make it easy to filter out  
Cmd+V.


- WBR, Alexey Proskuryakov


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

[webkit-dev] how to implement the flash block for webkit on linux?

[Suk Zhong]

Hi All:

  At present, we want to implement the flash block for webkit on linux
like flash block extension for firefox.

  We find the implemention of firefox, it's based on xbl, it's very easy
to understand.Through checking after sometime we find the branches/xbl2  of
webkit svn includes the xbl2 implemention, but don't know the degree of xbl
support and its current status, and the layouttest related to xbl is so
simple. some people know using xbl in webkit can implement the flash block?

  We also know the clicktoflash to block flash for safari on Mac,but we
need it on linux, because i can't understand xcode etc, some people can tell
me the main idea of its implemention?

 We'll appreciate for any other informations about implemention of flash
block for webkit.

Thanks and Best Regards.

Suk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined?

[x yz]

Zoltan,
Thanks for reply, I'm trying to understand your example. But,X86 instruction 
size is from 1 to 17bytes, not constant. I may misunderstand your comments?
Many X86 instruction can have imm32 at the end, thus this pointer can be used 
for patch as well as next address after call. Does Arm have similar things? or 
else you still need to figure out why "patchOffsetOpCallCompareToJump = 9;"? 
may be some instruction lengths relates to the 9?
rgds
joe


--- On Wed, 3/4/09, Zoltan Herczeg  wrote:

> From: Zoltan Herczeg 
> Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* 
> constant determined?
> To: webkit-dev@lists.webkit.org
> Date: Wednesday, March 4, 2009, 3:45 AM
> On x86, the size of the instructions are fixed. If you want
> to access
> multiple instructions in the instruction stream, you only
> need to store
> the address of the first one, and can access the others by
> their relative
> address. This saves a little memory.
> 
> Example (see JIT::linkCall):
>   instruction at callLinkInfo->hotPathBegin: points to
> callee comparison
>   instruction at
> callLinkInfo->hotPathBegin +
> patchOffsetOpCallCompareToJump:
>points to the slow case entry jump
> 
> Zoltan
> 
> > in jit.h, for example:
> > static const int
> patchOffsetOpCallCompareToJump = 9;
> > static const int patchOffsetPutByIdStructure =
> 7;
> > static const int
> patchOffsetPutByIdPropertyMapOffset = 22;
> > static const int
> patchOffsetGetByIdBranchToSlowCase = 13;
> > thanks for help, I'm stucked here now.
> > joe
> >
> >
> > --- On Sat, 2/28/09, Gavin Barraclough
>  wrote:
> >
> >> From: Gavin Barraclough
> 
> >> Subject: Re: [webkit-dev] want to port JIT to MIPS
> - JIT reg usage clean
> >> up?
> >> To: "WebKit Development"
> 
> >> Date: Saturday, February 28, 2009, 12:19 PM
> >> On Feb 27, 2009, at 4:55 PM, x yz wrote:
> >>
> >> > The regTx seems to be working registers here,
> yet
> >> their definition are regparm(3) registers for
> function
> >> arugments. Such usage would cause conflict on
> other
> >> platforms. May I suggest that we use individual
> defined set
> >> of regs for func i/o argument and working?
> >>
> >> First up, I think you're getting slightly
> confused
> >> about regparm(3).  This is not used anywhere in
> the JS
> >> language JIT, only in WREC.  In some
> configurations of the
> >> JIT we use fastcall semantics on x86... but none
> of this is
> >> really relevant to MIPS.  Just ignore all this. 
> Stick to
> >> the default MIPS ABI for stub functions.
> >>
> >> Reading between the lines, I'm guessing your
> concern
> >> here is that in setting up arguments for a JIT
> stub call you
> >> may trample the JIT's temporary registers?  If
> so, I
> >> think you need to look at the argument passing
> more closely.
> >>  The mechanisms to pass arguments to stub
> functions pass all
> >> arguments in memory – typically passing a single
> pointer
> >> to the stub functions, which can be used to
> retrieve the
> >> arguments.  This pointer argument can be set up
> immediately
> >> prior to the call, so it does not interfere with
> the regT?
> >> temporaries.  We follow this pattern on x86-64,
> where the
> >> ABI is typically to pass arguments in registers. 
> You cannot
> >> trivially change the way this works, since the
> argument
> >> pointer is used for other purposes too (e.g.
> retrieving the
> >> arguments passed into the JIT code from within the
> stubs).
> >>
> >> We strongly prefer small, simple, incremental
> changes.  A
> >> patch that tried to both port the JIT to a new
> platform and
> >> to introduce a new argument passing interface to
> the JIT
> >> stub functions sounds unlikely to get anywhere (a
> patch
> >> porting the JIT to a new platform is on its own
> very likely
> >> to be too much more than we'd want to land in
> one
> >> chunk).  I'd suggest that a port would be wise
> to
> >> engineer it's initial solution to fit one of
> the
> >> existing argument passing mechanisms (these are
> selected by
> >> JIT_STUB_ARGUMENT_* switches, to help find the
> relevant
> >> code).  (Alternatively, you're welcome to
> attempt to
> >> port x86-64 to make use of an in-register argument
> passing
> >> solution, which could be hugely useful.  With this
> landed
> >> first and separately, a port could then build on
> top of
> >> this.)
> >>
> >> As a more direct answer to your question, you
> could
> >> endeavour to make the set of hardware registers
> used as JIT
> >> temporaries non-overlapping with ABI function
> argument
> >> registers on MIPS, but this is unlikely to be a
> general
> >> solution to anything for all platforms, due to
> limited
> >> register availability on some architectures.
> >>
> >> > we would put all these definition in a file
> named
> >> regMap.h, then we can remove all "X86::"
> from
> >> other JIT files.
> >>
> >> I don't think we'll be keen on taking
> preemptive
> >> changes so far ahead in preparation of a port. 

[webkit-dev] Debugger shows empty javascript file when reloading page

[Husam Senussi]

Hi,

for some reason the debugger in the web inspector shows blank script  
when I reload the page, also

the resource tab shows the file with wrong type.

I tried it with the latest nightly build as will getting the same  
thing, I only see the script when open and close the

browser.


Thanks 
  
___

webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Detecting paste with cmd-v on Mac

[Rush Manbert]

I was testing some JavaScript code that a colleague wrote that does  
special handling when a user attempts to pastes a string into a text  
input box. He had developed it using Safari.


There s a routine that processes keyDown events. In it, he gets the  
charCode value from the keyEvent like this:
var charCode = (evt.charCode) ? evt.charCode : ((evt.keyCode) ?  
evt.keyCode : ((evt.which ? evt.which : 0)));


After that, he checks for the WebKit browser, then does this:
if(charCode == 86)
return; // Don't mess around with the paste keyCode

This worked for Safari, but didn't work in my custom browser that uses  
WebKit. The difference is that in Safari, evt.charCode == 0, and  
evt.keyCode == 86, so charCode ends up with the value 86. However,  
when I use WebKit, I see evt.charCode == 118 and evt.keyCode == 86, so  
charCode ends up with the value of 118.


I checked the values of the DOM even modifiers alyKey, ctrlKey, and  
shiftKey and they are all false on a cmd-v paste


Further testing reveals that the code shown above cannot detect the  
difference between cmd-v and v, and detects shift-v as a cmd-v paste  
because evt.charCode == 86 in that case.


I tried to handle this by adding code that detects keyDown/keyUp and  
uses a state variable. I set it true when I see a keyDown event with  
evt.charCode == 91 and I set it false when I see a keyUp event with  
evt.charCode == 91. Then I check for the state variable true and  
charCode == 118 when I'm looking for a paste.


That seems to work for both WebKit and Safari.

Is there another way to handle this? Is the difference between Safari  
and WebKit expected?


- Rush

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

Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined?

[Zoltan Herczeg]

On x86, the size of the instructions are fixed. If you want to access
multiple instructions in the instruction stream, you only need to store
the address of the first one, and can access the others by their relative
address. This saves a little memory.

Example (see JIT::linkCall):
  instruction at callLinkInfo->hotPathBegin: points to callee comparison
  instruction at
callLinkInfo->hotPathBegin + patchOffsetOpCallCompareToJump:
   points to the slow case entry jump

Zoltan

> in jit.h, for example:
> static const int patchOffsetOpCallCompareToJump = 9;
> static const int patchOffsetPutByIdStructure = 7;
> static const int patchOffsetPutByIdPropertyMapOffset = 22;
> static const int patchOffsetGetByIdBranchToSlowCase = 13;
> thanks for help, I'm stucked here now.
> joe
>
>
> --- On Sat, 2/28/09, Gavin Barraclough  wrote:
>
>> From: Gavin Barraclough 
>> Subject: Re: [webkit-dev] want to port JIT to MIPS - JIT reg usage clean
>> up?
>> To: "WebKit Development" 
>> Date: Saturday, February 28, 2009, 12:19 PM
>> On Feb 27, 2009, at 4:55 PM, x yz wrote:
>>
>> > The regTx seems to be working registers here, yet
>> their definition are regparm(3) registers for function
>> arugments. Such usage would cause conflict on other
>> platforms. May I suggest that we use individual defined set
>> of regs for func i/o argument and working?
>>
>> First up, I think you're getting slightly confused
>> about regparm(3).  This is not used anywhere in the JS
>> language JIT, only in WREC.  In some configurations of the
>> JIT we use fastcall semantics on x86... but none of this is
>> really relevant to MIPS.  Just ignore all this.  Stick to
>> the default MIPS ABI for stub functions.
>>
>> Reading between the lines, I'm guessing your concern
>> here is that in setting up arguments for a JIT stub call you
>> may trample the JIT's temporary registers?  If so, I
>> think you need to look at the argument passing more closely.
>>  The mechanisms to pass arguments to stub functions pass all
>> arguments in memory – typically passing a single pointer
>> to the stub functions, which can be used to retrieve the
>> arguments.  This pointer argument can be set up immediately
>> prior to the call, so it does not interfere with the regT?
>> temporaries.  We follow this pattern on x86-64, where the
>> ABI is typically to pass arguments in registers.  You cannot
>> trivially change the way this works, since the argument
>> pointer is used for other purposes too (e.g. retrieving the
>> arguments passed into the JIT code from within the stubs).
>>
>> We strongly prefer small, simple, incremental changes.  A
>> patch that tried to both port the JIT to a new platform and
>> to introduce a new argument passing interface to the JIT
>> stub functions sounds unlikely to get anywhere (a patch
>> porting the JIT to a new platform is on its own very likely
>> to be too much more than we'd want to land in one
>> chunk).  I'd suggest that a port would be wise to
>> engineer it's initial solution to fit one of the
>> existing argument passing mechanisms (these are selected by
>> JIT_STUB_ARGUMENT_* switches, to help find the relevant
>> code).  (Alternatively, you're welcome to attempt to
>> port x86-64 to make use of an in-register argument passing
>> solution, which could be hugely useful.  With this landed
>> first and separately, a port could then build on top of
>> this.)
>>
>> As a more direct answer to your question, you could
>> endeavour to make the set of hardware registers used as JIT
>> temporaries non-overlapping with ABI function argument
>> registers on MIPS, but this is unlikely to be a general
>> solution to anything for all platforms, due to limited
>> register availability on some architectures.
>>
>> > we would put all these definition in a file named
>> regMap.h, then we can remove all "X86::" from
>> other JIT files.
>>
>> I don't think we'll be keen on taking preemptive
>> changes so far ahead in preparation of a port.  The first
>> logical step in porting to a new platform is still to start
>> with WREC, and this requires no changes in the JIT
>> directory.  Any refactoring of the existing JIT would make
>> more sense more directly prior to work in that area.
>>
>> cheers,
>> G.
>>
>> >
>> > I'd apperciate if sb can do it or help me to do
>> it.
>> > rgds
>> > joe
>> >
>> >
>> >
>> >
>> > --- On Sat, 2/28/09, x yz 
>> wrote:
>> >
>> >> From: x yz 
>> >> Subject: Re: [webkit-dev] want to port JIT to MIPS
>> - which calling convention is used here?
>> >> To: webkit-dev@lists.webkit.org, "Zoltan
>> Herczeg" 
>> >> Date: Saturday, February 28, 2009, 7:40 AM
>> >> Hi,
>> >> Thanks for your help in advance:)
>> >> in JITPropertyAccess.cpp:
>> >>if
>> (transitionWillNeedStorageRealloc(oldStructure,
>> >> newStructure)) {
>> >>pop(X86::ebx);  ///pop return address,
>> why? for
>> >> exception?
>> >> #if PLATFORM(X86_64)///which convention is
>> this?
>> >>
>> >>
>> move(Imm32(

Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined?

[x yz]

in jit.h, for example:
static const int patchOffsetOpCallCompareToJump = 9;
static const int patchOffsetPutByIdStructure = 7;
static const int patchOffsetPutByIdPropertyMapOffset = 22;
static const int patchOffsetGetByIdBranchToSlowCase = 13;
thanks for help, I'm stucked here now.
joe


--- On Sat, 2/28/09, Gavin Barraclough  wrote:

> From: Gavin Barraclough 
> Subject: Re: [webkit-dev] want to port JIT to MIPS - JIT reg usage clean up?
> To: "WebKit Development" 
> Date: Saturday, February 28, 2009, 12:19 PM
> On Feb 27, 2009, at 4:55 PM, x yz wrote:
> 
> > The regTx seems to be working registers here, yet
> their definition are regparm(3) registers for function
> arugments. Such usage would cause conflict on other
> platforms. May I suggest that we use individual defined set
> of regs for func i/o argument and working?
> 
> First up, I think you're getting slightly confused
> about regparm(3).  This is not used anywhere in the JS
> language JIT, only in WREC.  In some configurations of the
> JIT we use fastcall semantics on x86... but none of this is
> really relevant to MIPS.  Just ignore all this.  Stick to
> the default MIPS ABI for stub functions.
> 
> Reading between the lines, I'm guessing your concern
> here is that in setting up arguments for a JIT stub call you
> may trample the JIT's temporary registers?  If so, I
> think you need to look at the argument passing more closely.
>  The mechanisms to pass arguments to stub functions pass all
> arguments in memory – typically passing a single pointer
> to the stub functions, which can be used to retrieve the
> arguments.  This pointer argument can be set up immediately
> prior to the call, so it does not interfere with the regT?
> temporaries.  We follow this pattern on x86-64, where the
> ABI is typically to pass arguments in registers.  You cannot
> trivially change the way this works, since the argument
> pointer is used for other purposes too (e.g. retrieving the
> arguments passed into the JIT code from within the stubs).
> 
> We strongly prefer small, simple, incremental changes.  A
> patch that tried to both port the JIT to a new platform and
> to introduce a new argument passing interface to the JIT
> stub functions sounds unlikely to get anywhere (a patch
> porting the JIT to a new platform is on its own very likely
> to be too much more than we'd want to land in one
> chunk).  I'd suggest that a port would be wise to
> engineer it's initial solution to fit one of the
> existing argument passing mechanisms (these are selected by
> JIT_STUB_ARGUMENT_* switches, to help find the relevant
> code).  (Alternatively, you're welcome to attempt to
> port x86-64 to make use of an in-register argument passing
> solution, which could be hugely useful.  With this landed
> first and separately, a port could then build on top of
> this.)
> 
> As a more direct answer to your question, you could
> endeavour to make the set of hardware registers used as JIT
> temporaries non-overlapping with ABI function argument
> registers on MIPS, but this is unlikely to be a general
> solution to anything for all platforms, due to limited
> register availability on some architectures.
> 
> > we would put all these definition in a file named
> regMap.h, then we can remove all "X86::" from
> other JIT files.
> 
> I don't think we'll be keen on taking preemptive
> changes so far ahead in preparation of a port.  The first
> logical step in porting to a new platform is still to start
> with WREC, and this requires no changes in the JIT
> directory.  Any refactoring of the existing JIT would make
> more sense more directly prior to work in that area.
> 
> cheers,
> G.
> 
> > 
> > I'd apperciate if sb can do it or help me to do
> it.
> > rgds
> > joe
> > 
> > 
> > 
> > 
> > --- On Sat, 2/28/09, x yz 
> wrote:
> > 
> >> From: x yz 
> >> Subject: Re: [webkit-dev] want to port JIT to MIPS
> - which calling convention is used here?
> >> To: webkit-dev@lists.webkit.org, "Zoltan
> Herczeg" 
> >> Date: Saturday, February 28, 2009, 7:40 AM
> >> Hi,
> >> Thanks for your help in advance:)
> >> in JITPropertyAccess.cpp:
> >>if
> (transitionWillNeedStorageRealloc(oldStructure,
> >> newStructure)) {
> >>pop(X86::ebx);  ///pop return address,
> why? for
> >> exception?
> >> #if PLATFORM(X86_64)///which convention is
> this?
> >> 
> >>
> move(Imm32(newStructure->propertyStorageCapacity()),
> >> regT1);  //edx
> >> 
> >>
> move(Imm32(oldStructure->propertyStorageCapacity()),
> >> X86::esi);
> >>move(regT0, X86::edi);
> >>callTarget = call();
> >> #else   ///__cdecl, yet how
> can I know
> >> resizePropertyStorage() use __cdecl?
> >> 
> >>
> push(Imm32(newStructure->propertyStorageCapacity()));
> >> 
> >>
> push(Imm32(oldStructure->propertyStorageCapacity()));
> >>push(regT0);
> >>callTarget = call();
> >>addPtr(Imm32(3 * sizeof(void*)), X86::esp);
> >> ///clean stack
> >> #end

Re: [webkit-dev] Gtklauncher crashes when WML is turned ON

[George Staikos]

Bug reports should be filed at bugs.webkit.org

On 3-Mar-09, at 5:02 PM, mwas wrote:


Hi

I used WebKit rev-40777 and turned ON WML support. The build goes  
successfully.


Lauching GtkLauncher gives segmentation fault with the following BT

Program received signal SIGSEGV, Segmentation fault.
0x4023c9d4 in WebCore::Document::cacheDocumentElement () from /usr/ 
local/lib/libwebkit-1.0.so.1

Current language: auto; currently asm
(gdb) bt
#0 0x4023c9d4 in WebCore::Document::cacheDocumentElement () from / 
usr/local/lib/libwebkit-1.0.so.1
#1 0x403483f0 in WebCore::HTMLParser::handleError () from /usr/ 
local/lib/libwebkit-1.0.so.1
#2 0x40349790 in WebCore::HTMLParser::insertNode () from /usr/local/ 
lib/libwebkit-1.0.so.1

#3 0x40a3dc60 in ?? () from /usr/local/lib/libwebkit-1.0.so.1

I think there is some problem while inserting nodes

Pl. suggest anything i can solve this problem.



--
George Staikos
Torch Mobile Inc.
http://www.torchmobile.com/

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

[webkit-dev] how to store javascript identifier

[zhenghe zhang]

Hi all
Now I have a diffcult problem, and I don't how to solve it.
I hope you help me, thank you!
When running a webpage, and the javascriptcore will parse the
javascript function, and will obtain some identifiers.  I don't know how to
store these identifiers and where to store these identifiers.
Thank you
Regards
zh

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

[webkit-dev] Gtklauncher crashes when WML is turned ON

[mwas]

Hi

I used WebKit rev-40777 and turned ON WML support. The build goes
successfully.

Lauching GtkLauncher gives segmentation fault with the following BT

Program received signal SIGSEGV, Segmentation fault.
0x4023c9d4 in WebCore::Document::cacheDocumentElement () from
/usr/local/lib/libwebkit-1.0.so.1
Current language: auto; currently asm
(gdb) bt
#0 0x4023c9d4 in WebCore::Document::cacheDocumentElement () from
/usr/local/lib/libwebkit-1.0.so.1
#1 0x403483f0 in WebCore::HTMLParser::handleError () from
/usr/local/lib/libwebkit-1.0.so.1
#2 0x40349790 in WebCore::HTMLParser::insertNode () from
/usr/local/lib/libwebkit-1.0.so.1
#3 0x40a3dc60 in ?? () from /usr/local/lib/libwebkit-1.0.so.1

I think there is some problem while inserting nodes

Pl. suggest anything i can solve this problem.

thanks

mwas
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev