Webkit (Qt::WebView) crashes randomly #51
Comments
|
Seems to work reliably on Windows XP with Ruby 1.9.3p286 and qtbindings 4.8.3.0. I changed your web address to a public site and that displayed correctly as well. I've had success running on a 64 bit version of CentOS but that might have been version 4.6.3.4. Have you tried that version? |
|
I've uninstalled the latest gem and installed 4.6.3.4. |
|
Is this specifically a crash within Webkit? Have you tried another public web address. I didn't have luck with https addresses but www.macrumors.com worked. :-) Is the program stable without the Webkit stuff. I don't have the bandwidth or the machine to try to figure out the underlying problem. |
|
Not sure if this helps, I got the (same kind?) of crash when using |
|
I'm using Mac OS X and got same problem with following simple code. require 'Qt4'
require 'qtwebkit'
Qt::Application.new ARGV do |app|
Qt::WebView.new do |webview|
webview.load Qt::Url.new 'http://google.co.jp/'
webview.show
end
app.exec
end
Has someone any solutions? |
|
I get the cfp consistency crash from this: require 'Qt'
require 'qtwebkit'
class HtmlViewer < Qt::Widget
def initialize
super
resize 1024, 768
move 300, 300
view = Qt::WebView.new self
layout = Qt::VBoxLayout.new(self)
layout.add_widget view
url = 'http://djellemah.com'
view.load Qt::Url.new(url)
end
end
app = Qt::Application.new ARGV
viewer = HtmlViewer.new
viewer.show
app.execSeems fairly random - the same page will work, and then crash 8 or so times in a row, then work again. I have other qt-bindings apps on this box which are working fine.
|
|
Here's the last few lines of a gdb stack trace: |
|
Same crash with ruby-2.0.0 and qtbindings-4.6.3.4 So I built qtbindings with some debug info, including some of the qWarning output in callMethod. Here's the output from running it in gdb: http://pastebin.com/NE5qB93s and here is 'thread apply all bt' http://pastebin.com/ppVV2cXi I'm suspecting some kind of threading issue, because when I run it under valgrind it does not crash. There are a whole lot of potential threading issues identified by helgrind though. I don't know if any of them are relevant. |
|
I've recompiled ruby and qtbindings with debug symbols and no compiler optimisations. I put a breakpoint at the line in ruby that calls rb_bug with "cfp consistency error". Sure enough there are 2 threads in the ruby vm. Which is most likely the problem. My guess is Binding::callMethod (and maybe callMethod on other c++ classes) shouldn't allow more than one thread into the ruby vm. One solution is here: http://burgestrand.se/articles/asynchronous-callbacks-in-ruby-c-extensions.html ffi does this to deal with it: https://github.com/ffi/ffi/wiki/Callbacks |
|
|
This should be resolved with qtbindings 4.8.5.1. Please comment if not. |
|
Hi, Ryan I ran into exactly the same issue as this thread describles, but I'm using openSUSE 13.2 w/ ruby 2.1.4 and ruby-qt4 4.14.2...in your project I didn't see any new release after 4.8.x...so I think it might be quite embarrassed if I report a bug for software I'm not using at all... Can you please take some time and check https://bugzilla.opensuse.org/show_bug.cgi?id=905512 to see if I was barking the same issue? Thanks Marguerite |
|
Hello marguerite - ruby-qt4 is not qtbindings, is is the outdated qtruby. You should probably uninstall that and then: |
|
Haha! I figured it out...at first I thought it was newer than Actually I opened a KDE bugreport here: https://bugs.kde.org/show_bug.cgi?id=340977 because sometimes we just can't require users to install rvm for a working KDE plasmoid...I think porting your fix back to KDE qtruby is still worthy. Of course I've switched my own application (https://github.com/marguerite/BiliGui) to |
The background
Here is what I'm using:
Here is my code:
The problem
Every other time I run the app, it crashes right away. It seems like there is 50% chance that it will crash.
The crash log:
Also, rarely it is not segfaulting, but exiting with this error:
I will provide any additional info if required.
The text was updated successfully, but these errors were encountered: