Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#17139 - [freewrl] browser plugin crashes the browser
Attached to Project:
Community Packages
Opened by Giuseppe Borzi (gborzi) - Sunday, 15 November 2009, 00:07 GMT
Last edited by Sergej Pupykin (sergej) - Wednesday, 25 November 2009, 07:59 GMT
Opened by Giuseppe Borzi (gborzi) - Sunday, 15 November 2009, 00:07 GMT
Last edited by Sergej Pupykin (sergej) - Wednesday, 25 November 2009, 07:59 GMT
|
DetailsDescription: After installing freewrl and realising that it has a browser plugin I tried it at this web page
http://cielab3.me.cmu.edu/~soji/aircraft/aircrafte.html upon clicking on one of the links to wrl files the browser crashes. This happens with firefox, midori and epiphany, each one showing the following error message FreeWRL: Fatal problem execing failed FreeWRL: : No such file or directory FreeWRL: Fatal problem execing problem FreeWRL: : No such file or directory after the crash freewrl is still running in the background, in fact the command "ps -ef|grep freewrl" returns gborzi 10015 1 10 00:58 pts/1 00:00:23 freewrl http://cielab3.me.cmu.edu/~soji/aircraft/a4f.wrl --plugin pipe:29 --eai --fd 33 --instance 2655643608 These files open fine in freewrl even giving the url, e.g. freewrl http://cielab3.me.cmu.edu/~soji/aircraft/a4f.wrl FreeWRL: : No such file or directory FreeWRL: Fatal problem execing problem FreeWRL: : No such file or directory happens with other websites. Additional info: * package version(s): freewrl 1.22.5-3 * config and/or log files etc. Steps to reproduce: open the above website and click on a picture. |
This task depends upon
I reported the bug upstream and after some discussion on the mailing list I've found a fix. Here is the text of the email with the fix
From: Giuseppe Borzi <xxxxx@xxxx.xxx>
To: FreeWRL X3D/VRML Viewer <freewrl@crc.ca>
Subject: A quick, dirty, bad but working workaround for 64bit FF 3.5.5
....
Hello,
I suspected that the problem with FF on 64bit was somewhat
cache-related and I was sure that midori's problems (both 32 and 64
bit, although different) is cache related. So I tried a quick fix by
disabling browser cache usage when the plugin is used. Basically I
opened file src/lib/main/ProdCon.c, commented the line with
if (RUNNINGASPLUGIN) {
and added this
if ( FALSE ) {
as can be seen in the attached patch. Now it's working, for both 32 and
64 bit, FF 3.5.5 and midori, but kazehakase often crashes. I don't know
how it'll work with FF 3.0, because I haven't this browser installed.
I wrote "bad" in the subject because I think that the plugin should
use the cached files, instead of re-downloading them and clogging
the /tmp directory. Also it may be unable to download from
password-protected sites.
Hope this helps.
In attach to this comment there are (in a shar file) the PKGBUILD and patch I used to recompile the package. Please note that I've removed the sed lines (the first one actually damages the source, removing it at least the plugin worked on 32 bit, the second one is useless) and compiled with curl. curl is not strictly needed, but I'm under thee impression that the plugin works somewhat better with it, although I haven't done extensive testing. Also added --with-fontsdir to configure (and related ttf-bitstream-vera in optdepends) and --enable-libeai.
Please test these modifications and eventually update the package.