Summary: | x11-libs/qt-webkit - /usr/share/qt4/demos/browser/browser hangs while loading URLs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | esigra, hppa |
Priority: | Highest | ||
Version: | unspecified | ||
Hardware: | HPPA | ||
OS: | Linux | ||
URL: | https://bugs.webkit.org/show_bug.cgi?id=34037 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 248038, 341703 | ||
Attachments: | /usr/share/qt4/demos/browser/browser gdb backtrace |
Description
Jeroen Roovers (RETIRED)
2008-10-03 14:47:23 UTC
/usr/share/qt4/demos/browser/browser reliably segfaults. I am currently building a debug build of all of x11-libs/qt-* to figure out what happens. The program runs a GUI, the address bar shows a progress bar indicating it's loading <http://www.trolltech.com/>, and then progress stops, the window is destroyed and the app segfaults. Created attachment 167332 [details]
/usr/share/qt4/demos/browser/browser gdb backtrace
Is this a regression since you keyworded 4.4.0? Or a bug that showed up after more testing? Webkit on sparc gives a sigbus, so this may be similar. We could just mask qt-webkit in the profile, and go ahead stabilizing the other qt ebuilds. I don't see what the ebuild has to do with this. (In reply to comment #3) > Is this a regression since you keyworded 4.4.0? Or a bug that showed up after > more testing? It has never worked properly to my knowledge. > Webkit on sparc gives a sigbus, so this may be similar. We could > just mask qt-webkit in the profile, and go ahead stabilizing the other qt > ebuilds. That would be the quickest way about it - everything else Qt seems to work nicely. With www-client/arora-0.4 I have slightly better results. It doesn't segfault but it still loops a lot and doesn't seem to ever end loading pages. I have no idea why arora would behave better, as I would think it basically tries to do the same as the browser demo. Is this bug still relevant with later versions? (In reply to comment #6) > Is this bug still relevant with later versions? Yes, of course. (In reply to comment #7) > (In reply to comment #6) > > Is this bug still relevant with later versions? > > Yes, of course. More specifically, this bug report will remain open as long as the bug isn't fixed. The bug probably isn't going to get fixed until it's reported upstream that, after the fork from khtml, webkit got "optimised" to such an extent that a couple of processor architectures that were previously very well supported are now unable to use the code at all, and that webkit should be ported to those dropped architectures again. (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > Is this bug still relevant with later versions? > > > > Yes, of course. > > More specifically, this bug report will remain open as long as the bug isn't > fixed. The bug probably isn't going to get fixed until it's reported upstream > that, after the fork from khtml, webkit got "optimised" to such an extent that > a couple of processor architectures that were previously very well supported > are now unable to use the code at all, and that webkit should be ported to > those dropped architectures again. > @hppa ping to upstream bug activity Seems the upstream is going do drop hppa from the supported arches Thanks for the update. It seems upstream isn't really aware of Linux/HPPA, if comment #5 [1] has any weight to it. HP-UX is not relevant to this bug report. :) [2] suggests that HP-UX will still be supported, but only on IA64. It does not suggest that PARISC support will be dropped. See also [3]. [1] https://bugs.webkit.org/show_bug.cgi?id=34037#c5 [2] http://doc.trolltech.com/4.6/supported-platforms.html [3] http://doc.trolltech.com/4.6/platform-notes-x11.html#hp-ux HPPA keywording dropped. Well, WONTFIX sounds like a more appropriate resolution... but nevermind... |