[webkit-dev] WebKit on OpenBSD

2008-05-30 Thread James Turner
I've spent the last couple days trying to compile WebKit on OpenBSD
-current.  After adding the signbit function, changing isfinite to
finite and adding the missing pthread_attr_get_np function, I was
finally able to get it to compile.

However, when I try to run the Gtk test browser or midori (another gtk
browser based on webkit), I receive or core dump whenever I click on any
part of a webpage or try to navigate to another.  After inspecting the
core dump with gdb I'm left with this:

#0  0x0d501dc8 in KJS::Collector::markStackObjectsConservatively () from
/usr/local/lib/libwebkit-1.0.so.1.0

Any clue to where I might look to fix this problem, or what might cause
it would be very helpful.  Thank you.

-- 
James Turner
BSD Group Consulting
http://www.bsdgroup.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit on OpenBSD

2008-05-30 Thread Maciej Stachowiak

On May 30, 2008, at 12:15 PM, James Turner wrote:

 On Fri, May 30, 2008 at 12:13:43PM -0700, Maciej Stachowiak wrote:

 On May 30, 2008, at 10:37 AM, James Turner wrote:

 I've spent the last couple days trying to compile WebKit on OpenBSD
 -current.  After adding the signbit function, changing isfinite to
 finite and adding the missing pthread_attr_get_np function, I was
 finally able to get it to compile.

 However, when I try to run the Gtk test browser or midori (another  
 gtk
 browser based on webkit), I receive or core dump whenever I click  
 on any
 part of a webpage or try to navigate to another.  After inspecting  
 the
 core dump with gdb I'm left with this:

 #0  0x0d501dc8 in KJS::Collector::markStackObjectsConservatively  
 () from
 /usr/local/lib/libwebkit-1.0.so.1.0

 Sounds like pthread_attr_get_np is not working as expected. It is  
 used to
 get the stack base, for purposes of the conservative garbage  
 collector.

 - Maciej

 Thanks, I'll look into my implementation and check it with people who
 actually know what they're doing!

pthread_attr_get_np is not really all that important, just any way to  
get the stack base. If OpenBSD has any function at all that works for  
that purpose you could just add another branch to the ifdef.  
Regrettably there is no portable way to do it.

  - Maciej

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


Re: [webkit-dev] WebKit on OpenBSD

2008-05-30 Thread James Turner
On Fri, May 30, 2008 at 12:22:54PM -0700, Maciej Stachowiak wrote:

 On May 30, 2008, at 12:15 PM, James Turner wrote:

 On Fri, May 30, 2008 at 12:13:43PM -0700, Maciej Stachowiak wrote:

 On May 30, 2008, at 10:37 AM, James Turner wrote:

 I've spent the last couple days trying to compile WebKit on OpenBSD
 -current.  After adding the signbit function, changing isfinite to
 finite and adding the missing pthread_attr_get_np function, I was
 finally able to get it to compile.

 However, when I try to run the Gtk test browser or midori (another gtk
 browser based on webkit), I receive or core dump whenever I click on any
 part of a webpage or try to navigate to another.  After inspecting the
 core dump with gdb I'm left with this:

 #0  0x0d501dc8 in KJS::Collector::markStackObjectsConservatively () from
 /usr/local/lib/libwebkit-1.0.so.1.0

 Sounds like pthread_attr_get_np is not working as expected. It is used to
 get the stack base, for purposes of the conservative garbage collector.

 - Maciej

 Thanks, I'll look into my implementation and check it with people who
 actually know what they're doing!

 pthread_attr_get_np is not really all that important, just any way to get 
 the stack base. If OpenBSD has any function at all that works for that 
 purpose you could just add another branch to the ifdef. Regrettably there 
 is no portable way to do it.

  - Maciej

So, I looked through OpenBSD's diff stack function and tried using
pthread_stackseg_np like:

stack_t stack;
pthread_stackseg_np(thread, stack);

But I'm still getting a segfault at the same location.  This again could
be the wrong function to use, but it's the only thing I can find that
looks remotely like it would work :/
-- 
James Turner
BSD Group Consulting
http://www.bsdgroup.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit on OpenBSD

2008-05-30 Thread Maciej Stachowiak

On May 30, 2008, at 1:51 PM, James Turner wrote:

 On Fri, May 30, 2008 at 12:22:54PM -0700, Maciej Stachowiak wrote:

 On May 30, 2008, at 12:15 PM, James Turner wrote:

 On Fri, May 30, 2008 at 12:13:43PM -0700, Maciej Stachowiak wrote:

 On May 30, 2008, at 10:37 AM, James Turner wrote:

 I've spent the last couple days trying to compile WebKit on  
 OpenBSD
 -current.  After adding the signbit function, changing isfinite to
 finite and adding the missing pthread_attr_get_np function, I was
 finally able to get it to compile.

 However, when I try to run the Gtk test browser or midori  
 (another gtk
 browser based on webkit), I receive or core dump whenever I  
 click on any
 part of a webpage or try to navigate to another.  After  
 inspecting the
 core dump with gdb I'm left with this:

 #0  0x0d501dc8 in KJS::Collector::markStackObjectsConservatively  
 () from
 /usr/local/lib/libwebkit-1.0.so.1.0

 Sounds like pthread_attr_get_np is not working as expected. It is  
 used to
 get the stack base, for purposes of the conservative garbage  
 collector.

 - Maciej

 Thanks, I'll look into my implementation and check it with people  
 who
 actually know what they're doing!

 pthread_attr_get_np is not really all that important, just any way  
 to get
 the stack base. If OpenBSD has any function at all that works for  
 that
 purpose you could just add another branch to the ifdef. Regrettably  
 there
 is no portable way to do it.

 - Maciej

 So, I looked through OpenBSD's diff stack function and tried using
 pthread_stackseg_np like:

 stack_t stack;
 pthread_stackseg_np(thread, stack);

 But I'm still getting a segfault at the same location.  This again  
 could
 be the wrong function to use, but it's the only thing I can find that
 looks remotely like it would work :/

It sounds like it should work (looks analogous to the Solaris  
thr_stksegment). Can you try in the debugger? You should be able to  
see if it is trying to access an address outside the stack range, or  
doing an unaligned access, or something.

Regards,
Maciej



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