Menu
▾
▴
openvrml-develop
|
From: Braden M. <br...@en...> - 2010-02-16 02:53:59
|
OpenVRML 0.18.5 is now available. The distribution can be obtained from <http://downloads.sourceforge.net/project/openvrml/openvrml/0.18.5/openvrml-0.18.5.tar.gz> OpenVRML is a C++ runtime library for VRML97 and X3D worlds. It is capable of reading and displaying VRML/X3D; it can be used for creating loaders, file converters, and VRML/X3D browsers. OpenVRML includes an out-of-process viewer component for use in X11 environments along with hosts for this component in the form of a Mozilla browser plug-in and a stand-alone player. You can find OpenVRML on the Web at <http://openvrml.org> New in OpenVRML 0.18.5: - Fixed build configuration issues for Mac OS X and Cygwin. |
|
From: Greg R. <ne...@po...> - 2010-03-15 04:39:37
|
Lots o' issues, a few successes...
Docs:
- README needs to call out libtool/libltdl as a required dependency.
- D-Bus does _not_ automatically start openvrml-xembed on my box. No clue
how that's supposed to work. The workaround mentioned on the list works,
but the README is slightly misleading.
Build:
- AFAICT, it is flat out impossible to do a full openvrml build on reasonably
modern Debian/Ubuntu. Both xulrunner 1.9.1 (required due to some unique
header file, according to configure) and 1.8.1 (the source of libmozjs)
are required, and they cannot be installed simultaneously due to some
unspecified conflict. Ergo, no JS.
- The dependency list is...stunning. I had to install close to a gigabyte
of additional stuff, and I already had a fairly decent development box.
Extra/upgraded Ubuntu packages:
sudo apt-get install libboost1.37-dev libboost1.37-doc
- [51MB of archives, 183MB of disk space]
- [gccxml libboost-date-time1.37-dev libboost-date-time1.37.0
libboost-filesystem1.37-dev libboost-filesystem1.37.0
libboost-graph1.37-dev libboost-graph1.37.0 libboost-iostreams1.37-dev
libboost-iostreams1.37.0 libboost-program-options1.37-dev
libboost-program-options1.37.0 libboost-python1.37-dev
libboost-python1.37.0 libboost-regex1.37-dev libboost-regex1.37.0
libboost-serialization1.37-dev libboost-serialization1.37.0
libboost-signals1.37-dev libboost-signals1.37.0 libboost-system1.37-dev
libboost-system1.37.0 libboost-test1.37-dev libboost-test1.37.0
libboost-thread1.37-dev libboost-thread1.37.0 libboost-wave1.37-dev
libboost-wave1.37.0 libboost1.37-dev libboost1.37-doc]
sudo apt-get install libpng-dev libjpeg-dev xulrunner-1.9-dev default-jdk libgl1-mesa-dev libglw1-mesa-dev libosmesa6-dev libgtkglext1 libgtkglext1-dev libcurl4-gnutls-dev libdbus-1-dev libdbus-glib-1-dev libsdl1.2debian-pulseaudio doxygen doxygen-doc
- [25.5MB of archives, 110MB of disk space]
- [comerr-dev default-jdk doxygen doxygen-doc libcurl4-gnutls-dev
libdbus-1-dev libdbus-glib-1-dev libgcrypt11-dev libglw1-mesa
libglw1-mesa-dev libgnutls-dev libgpg-error-dev libgtkglext1
libgtkglext1-dev libidn11-dev libkadm55 libkrb5-dev libldap2-dev
libnspr4-dev libnss3-dev libosmesa6 libosmesa6-dev
libsdl1.2debian-pulseaudio libtasn1-3-dev libxmu-dev libxmu-headers
openjdk-6-jdk xulrunner-1.9-dev]
- [REMOVE libsdl1.2debian-alsa]
sudo apt-get install gcj libgcj-dev libgcj-doc java-gcj-compat java-gcj-compat-dev ant
- [96.7MB of archives, 604MB of disk space]
- [ant-gcj ant-optional ant-optional-gcj antlr ecj ecj-gcj fastjar gcj-4.3
gcj-4.3-base gappletviewer-4.3 gij gij-4.3 gjdoc java-gcj-compat-headless
libantlr-java libantlr-java-gcj libbcel-java libecj-java libecj-java-gcj
libgcj-bc libgcj-common libgcj9-0 libgcj9-0-awt libgcj9-dev libgcj9-jar
libgcj9-src libjaxp1.3-java libjaxp1.3-java-gcj liblog4j1.2-java
liblog4j1.2-java-gcj libmx4j-java libregexp-java libxerces2-java
libxerces2-java-gcj]
sudo apt-get install libtool libtool-doc
- [libltdl7-dev libtool libtool-doc]
sudo apt-get install libxml2-dev libxml2-doc
- [libxml2-dev libxml2-doc]
sudo apt-get install libmozjs-dev
- [libmozjs-dev]
sudo apt-get install libgnomeui-dev libgnomeui-doc
- [4102kB of archives, 21.7MB of disk space]
- [libart-2.0-dev libavahi-client-dev libavahi-common-dev libavahi-glib-dev
libbonobo2-dev libbonoboui2-dev libgail-dev libgconf2-dev
libgnome-keyring-dev libgnome2-dev libgnomecanvas2-dev libgnomeui-dev
libgnomeui-doc libgnomevfs2-dev libidl-dev liborbit2-dev libpopt-dev
libselinux1-dev libsepol1-dev orbit2]
sudo apt-get install xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support
- [13.5MB of archives, 25.3MB of disk space]
- [xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support]
- [REMOVE libmozjs-dev xulrunner-1.9-dev]
The (single-threaded) first, non-JS build took 102 minutes on one of two
1.6 GHz Atom 330's; build directory was 820 MB afterward. Still chugging
away on the second build to work around:
- I'm kind of amazed that, a month after release, nobody has yet noticed
that JPEG is broken:
if test X$enable_jpeg_textures = Xno; then
JPEG_LIBS=""
JPEG_LIBS="-ljpeg"
cat >>confdefs.h <<\_ACEOF
#define OPENVRML_ENABLE_JPEG_TEXTURES 1
_ACEOF
fi
Yeah, not so much.
Install:
- Where's sdl-viewer? Oh, buried down in an example directory. Given
the issues with openvrml-player (below), it would probably be good to
install sdl-viewer by default (maybe as openvrml-sdl-viewer, for
consistency and general non-generic-ness).
Run:
- openvrml-player doesn't work at all. The best it manages is a single
frame before crashing, and that only on extremely simple worlds. On at
least a couple of occasions it chokes with signs of memory corruption:
openvrml-player pngboxes.wrl
** (openvrml-xembed:26721): DEBUG: inserted reference to :1.197
get fences failed: -1
param: 6, val: 0
*** glibc detected *** /usr/local/libexec/openvrml-xembed: corrupted double-linked list: 0xb29b35e0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb6c92604]
/lib/tls/i686/cmov/libc.so.6[0xb6c955d2]
/lib/tls/i686/cmov/libc.so.6(__libc_malloc+0x95)[0xb6c969c5]
/usr/lib/libglib-2.0.so.0(g_malloc+0x34)[0xb7567284]
/usr/lib/libglib-2.0.so.0(g_strdup+0x39)[0xb757ffa9]
/usr/lib/libgobject-2.0.so.0(g_value_set_string+0x7b)[0xb76240db]
/usr/lib/libdbus-glib-1.so.2[0xb7f5518e]
/usr/lib/libdbus-glib-1.so.2[0xb7f53a55]
/usr/lib/libdbus-glib-1.so.2[0xb7f53b9c]
/usr/lib/libdbus-glib-1.so.2[0xb7f51baf]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x1ab)[0xb75fcc7b]
/usr/lib/libgobject-2.0.so.0[0xb7612e57]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7b9)[0xb76144b9]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x26)[0xb7614936]
/usr/lib/libdbus-glib-1.so.2[0xb7f52e3f]
/lib/libdbus-1.so.3(dbus_connection_dispatch+0x395)[0xb7f180d5]
/usr/lib/libdbus-glib-1.so.2[0xb7f496bd]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1e8)[0xb755eb88]
/usr/lib/libglib-2.0.so.0[0xb75620eb]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1ca)[0xb75625ba]
/usr/local/libexec/openvrml-xembed[0x805675e]
/usr/local/libexec/openvrml-xembed(_ZNK5boost9function0IvEclEv+0x21)[0x8057a61]
/usr/lib/libboost_thread-mt.so.1.37.0(thread_proxy+0x68)[0xb6edf848]
/lib/tls/i686/cmov/libpthread.so.0[0xb6d8c4ff]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb6d0749e]
======= Memory map: ========
08048000-0806d000 r-xp 00000000 08:07 456472 /usr/local/libexec/openvrml-xembed
0806d000-0806e000 r--p 00025000 08:07 456472 /usr/local/libexec/openvrml-xembed
0806e000-0806f000 rw-p 00026000 08:07 456472 /usr/local/libexec/openvrml-xembed
0918b000-09271000 rw-p 0918b000 00:00 0 [heap]
adca8000-adca9000 ---p adca8000 00:00 0
adca9000-ae4a9000 rwxp adca9000 00:00 0
ae4a9000-ae4aa000 ---p ae4a9000 00:00 0
ae4aa000-aecaa000 rwxp ae4aa000 00:00 0
aecaa000-aecab000 ---p aecaa000 00:00 0
aecab000-af4ab000 rwxp aecab000 00:00 0
af4ab000-af4ac000 ---p af4ab000 00:00 0
af4ac000-afcac000 rwxp af4ac000 00:00 0
afcac000-afcad000 ---p afcac000 00:00 0
afcad000-b04ad000 rwxp afcad000 00:00 0
b04ad000-b04ae000 ---p b04ad000 00:00 0
b04ae000-b0cae000 rwxp b04ae000 00:00 0
b04ae000-b0cae000 rwxp b04ae000 00:00 0
b0cae000-b0caf000 ---p b0cae000 00:00 0
b0caf000-b14af000 rwxp b0caf000 00:00 0
b14af000-b1500000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1500000-b152c000 rw-p b1500000 00:00 0
b152c000-b1600000 ---p b152c000 00:00 0
b164e000-b169f000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b169f000-b16f0000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b16f0000-b1741000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1741000-b1792000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1792000-b17e3000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b17e3000-b1834000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1834000-b1885000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1885000-b18d6000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b18d6000-b1927000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1927000-b1978000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1978000-b19c9000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b19c9000-b1a1a000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1a1a000-b1a6b000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1a6b000-b1abc000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1abc000-b1b0d000 r--p 00000000 08:07 888953 /us
[7] Abort /usr/local/libexec/openvrml-xembed
and simultaneously this stuff showed up for any X event in the player window:
** (openvrml-player:26724): CRITICAL **: void<unnamed>::reset_fds(<unnamed>::CURLSource&): assertion `Invalid multi handle' failed
[x many]
A later run displayed a single frame before dying:
openvrml-player dodecahedron.wrl
** (openvrml-xembed:27181): DEBUG: inserted reference to :1.225
get fences failed: -1
param: 6, val: 0
splut:/data/vrml 1351> ** (openvrml-xembed:27181): DEBUG: erased references to :1.225
[7] Done /usr/local/libexec/openvrml-xembed
On a single-(JPEG-)texture, 12-polygon world, it coughed up a weird MIME-
type error/warning and displayed nothing at all:
openvrml-player dodecahedron.wrl
** (openvrml-xembed:27008): DEBUG: inserted reference to :1.219
get fences failed: -1
param: 6, val: 0
unexpected media type "application/octet-stream"
splut:/data/vrml 1346> ** (openvrml-xembed:27008): DEBUG: erased references to :1.219
[7] Done /usr/local/libexec/openvrml-xembed
(The constant killing of xembed is kind of frustrating, too.)
On a single-PixelTexture world, it did the single-frame display before
dying with a mutex failure:
openvrml-player hypnosphere-chek97.wrl
** (openvrml-xembed:27020): DEBUG: inserted reference to :1.222
get fences failed: -1
param: 6, val: 0
file:///data/vrml/hypnosphere-chek97.wrl:37:46: warning: rotation axis should be a normalized vector
file:///data/vrml/hypnosphere-chek97.wrl:37:66: warning: rotation axis should be a normalized vector
file:///data/vrml/hypnosphere-chek97.wrl:38:12: warning: rotation axis should be a normalized vector
file:///data/vrml/hypnosphere-chek97.wrl:1979:44: warning: rotation axis should be a normalized vector
file:///data/vrml/hypnosphere-chek97.wrl:1988:37: warning: rotation axis should be a normalized vector
splut:/data/vrml 1349> openvrml-xembed: /usr/include/boost/thread/pthread/mutex.hpp:50: void boost::mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
[7] Abort /usr/local/libexec/openvrml-xembed
On a five-PNG/JPEG-texture world (mostly just plain polygons), it again
died without displaying anything:
openvrml-player cubicles.wrl
** (openvrml-xembed:27214): DEBUG: inserted reference to :1.236
get fences failed: -1
param: 6, val: 0
unexpected media type "application/octet-stream"
splut:/data/vrml/cubicles 1360> ** (openvrml-xembed:27214): DEBUG: erased references to :1.236
[7] Done /usr/local/libexec/openvrml-xembed
// blank slate...nothing displayed at all
- sdl-viewer, as someone else (Braden?) noted a few months back, does work
(mostly), and it conveniently doesn't kill xembed even when the viewer
aborts. It has some serious problems with this world, however (which is
highly ironic, given libvrml97's performance on it 10 or 12 years ago):
openvrml-sdl-viewer pngboxes.wrl
get fences failed: -1
param: 6, val: 0
Segmentation fault
DOH!
openvrml-sdl-viewer pngboxes.wrl
get fences failed: -1
param: 6, val: 0
*** glibc detected *** openvrml-sdl-viewer: corrupted double-linked list: 0x0a4d5e68 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7616604]
/lib/tls/i686/cmov/libc.so.6[0xb7618367]
/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb76185b6]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7812231]
/usr/local/lib/libopenvrml.so.9[0xb7b9594b]
/usr/local/lib/libopenvrml.so.9(_ZNK5boost9function0IvEclEv+0x2c)[0xb7b9af8c]
/usr/local/lib/libopenvrml.so.9(_ZN5boost6detail11thread_dataINS_9function0IvEEE3runEv+0x22)[0xb7b9b202]
/usr/lib/libboost_thread-mt.so.1.37.0(thread_proxy+0x68)[0xb7863848]
/lib/tls/i686/cmov/libpthread.so.0[0xb77104ff]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb768b49e]
======= Memory map: ========
08048000-08050000 r-xp 00000000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
08050000-08051000 r--p 00007000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
08051000-08052000 rw-p 00008000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
09c77000-0a532000 rw-p 09c77000 00:00 0 [heap]
acc00000-acc21000 rw-p acc00000 00:00 0
acc21000-acd00000 ---p acc21000 00:00 0
acd41000-acd42000 ---p acd41000 00:00 0
acd42000-ad542000 rwxp acd42000 00:00 0
ad542000-ad54a000 rw-s 00000000 00:09 6990848 /drm mm object (deleted)
ad54a000-ad54b000 ---p ad54a000 00:00 0
ad54b000-add4b000 rwxp ad54b000 00:00 0
add4b000-add4c000 ---p add4b000 00:00 0
add4c000-ae54c000 rwxp add4c000 00:00 0
ae54c000-ae554000 rw-s 00000000 00:09 6990846 /drm mm object (deleted)
ae554000-ae55c000 rw-s 00000000 00:09 6990844 /drm mm object (deleted)
ae55c000-ae564000 rw-s 00000000 00:09 6990842 /drm mm object (deleted)
ae564000-ae565000 ---p ae564000 00:00 0
ae565000-aed65000 rwxp ae565000 00:00 0
aed65000-aed66000 ---p aed65000 00:00 0
aed66000-af566000 rwxp aed66000 00:00 0
af566000-af56e000 rw-s 00000000 00:09 6990840 /drm mm object (deleted)
af56e000-af576000 rw-s 00000000 00:09 6990838 /drm mm object (deleted)
af576000-af57e000 rw-s 00000000 00:09 6990836 /drm mm object (deleted)
af57e000-af57f000 ---p af57e000 00:00 0
af57f000-afd7f000 rwxp af57f000 00:00 0
afd7f000-afd80000 ---p afd7f000 00:00 0
afd80000-b0580000 rwxp afd80000 00:00 0
b0580000-b0588000 rw-s 00000000 00:09 6990834 /drm mm object (deleted)
b0588000-b0589000 ---p b0588000 00:00 0
b0589000-b0d89000 rwxp b0589000 00:00 0
b0d89000-b0d8a000 ---p b0d89000 00:00 0
b0d8a000-b158a000 rwxp b0d8a000 00:00 0
b158a000-b1592000 rw-s 00000000 00:09 6990832 /drm mm object (deleted)
b1592000-b159a000 rw-s 00000000 00:09 6990830 /drm mm object (deleted)
b159a000-b15a2000 rw-s 00000000 00:09 6990828 /drm mm object (deleted)
b15a2000-b15aa000 rw-s 00000000 00:09 6990826 /drm mm object (deleted)
b15aa000-b15ab000 ---p b15aa000 00:00 0
b15ab000-b1dab000 rwxp b15ab000 00:00 0
b1dab000-b1db3000 rw-s 00000000 00:09 6990823 /drm mm object (deleted)
b1db3000-b1dbb000 rw-s 00000000 00:09 6990822 /drm mm object (deleted)
b1dbb000-b1dc3000 rw-s 00000000 00:09 6990820 /drm mm object (deleted)
b1dc3000-b1e14000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1e14000-b1e65000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1e65000-b1eb6000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1eb6000-b1f07000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1f07000-b1f58000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1f58000-b1fa9000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1fa9000-b1ffa000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1ffa000-b204b000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b204b000-b209c000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b209c000-b20ed000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b20ed000-b213e000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b213e000-b218f000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b218f000-b21e0000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b21e0000Abort
DOH!
openvrml-sdl-viewer pngboxes.wrl
get fences failed: -1
param: 6, val: 0
*** glibc detected *** openvrml-sdl-viewer: free(): invalid pointer: 0x0989a1b0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb75ad604]
/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb75af5b6]
/usr/lib/dri/i915_dri.so(_mesa_align_free+0x1d)[0xb5dee40d]
/usr/lib/dri/i915_dri.so(_math_matrix_dtr+0x3d)[0xb5e30edd]
/usr/lib/dri/i915_dri.so[0xb5df1f43]
/usr/lib/dri/i915_dri.so(_mesa_free_matrix_data+0x52)[0xb5df1fc2]
/usr/lib/dri/i915_dri.so(_mesa_free_context_data+0x120)[0xb5db2ed0]
/usr/lib/dri/i915_dri.so(intelDestroyContext+0xf6)[0xb5d784d6]
/usr/lib/dri/i915_dri.so[0xb5d531c7]
/usr/lib/libGL.so.1[0xb7d8cfcc]
/usr/lib/libGL.so.1[0xb7d68bc5]
/usr/lib/libSDL-1.2.so.0[0xb7e7e886]
/usr/lib/libSDL-1.2.so.0[0xb7e82ce7]
/usr/lib/libSDL-1.2.so.0[0xb7e82f22]
/usr/lib/libSDL-1.2.so.0(SDL_VideoQuit+0x50)[0xb7e718a0]
/usr/lib/libSDL-1.2.so.0(SDL_QuitSubSystem+0x55)[0xb7e462e5]
/usr/lib/libSDL-1.2.so.0(SDL_Quit+0x1e)[0xb7e4636e]
/usr/lib/libSDL-1.2.so.0[0xb7e46bff]
[0xb7eed400]
/usr/lib/dri/i915_dri.so[0xb5d5e6fd]
/usr/lib/dri/i915_dri.so(_tnl_draw_prims+0xbf8)[0xb5e41558]
/usr/lib/dri/i915_dri.so(vbo_save_playback_vertex_list+0x351)[0xb5e3fd31]
/usr/lib/dri/i915_dri.so[0xb5dca63d]
/usr/lib/dri/i915_dri.so(_mesa_CallList+0x4a)[0xb5dcd4da]
/usr/local/lib/libopenvrml-gl.so.8(_ZN8openvrml2gl6viewer15do_insert_shellERKNS_13geometry_nodeEjRKSt6vectorINS_5vec3fESaIS6_EERKS5_IiSaIiEERKS5_INS_5colorESaISF_EESE_SA_SE_RKS5_INS_5vec2fESaISK_EESE_+0x58b)[0xb7e319db]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml6viewer12insert_shellERKNS_13geometry_nodeEjRKSt6vectorINS_5vec3fESaIS5_EERKS4_IiSaIiEERKS4_INS_5colorESaISE_EESD_S9_SD_RKS4_INS_5vec2fESaISJ_EESD_+0x57)[0xb7b3da97]
/usr/local/lib/openvrml/node/vrml97.so[0xb4b749f2]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml13geometry_node15render_geometryERNS_6viewerENS_17rendering_contextE+0x82)[0xb7ae42f2]
/usr/local/lib/openvrml/node/vrml97.so[0xb4b3af41]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x74)[0xb7ae43c4]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb00ec]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb2570]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x74)[0xb7ae43c4]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb00ec]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb2570]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x74)[0xb7ae43c4]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb00ec]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb2570]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x74)[0xb7ae43c4]
/usr/local/lib/openvrml/node/vrml97.so[0xb4a8a93c]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x74)[0xb7ae43c4]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml5scene6renderERNS_6viewerENS_17rendering_contextE+0x76)[0xb7b2ef66]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml7browser6renderEv+0x32b)[0xb7b37d2b]
/usr/local/lib/libopenvrml-gl.so.8(_ZN8openvrml2gl6viewer6redrawEv+0x11c)[0xb7e3029c]
openvrml-sdl-viewer[0x804cd97]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7554775]
openvrml-sdl-viewer[0x804bd01]
======= Memory map: ========
08048000-08050000 r-xp 00000000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
08050000-08051000 r--p 00007000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
08051000-08052000 rw-p 00008000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
0981d000-09cf9000 rw-p 0981d000 00:00 0 [heap]
a0d92000-a0d93000 ---p a0d92000 00:00 0
a0d93000-a1593000 rwxp a0d93000 00:00 0
a1593000-a1594000 ---p a1593000 00:00 0
a1594000-a1d94000 rwxp a1594000 00:00 0
a1d94000-a1d95000 ---p a1d94000 00:00 0
a1d95000-a2595000 rwxp a1d95000 00:00 0
a2595000-a2596000 ---p a2595000 00:00 0
a2596000-a2d96000 rwxp a2596000 00:00 0
a2d96000-a2d97000 ---p a2d96000 00:00 0
a2d97000-a3597000 rwxp a2d97000 00:00 0
a3597000-a3598000 ---p a3597000 00:00 0
a3598000-a3d98000 rwxp a3598000 00:00 0
a3d98000-a3d99000 ---p a3d98000 00:00 0
a3d99000-a4599000 rwxp a3d99000 00:00 0
a4599000-a459a000 ---p a4599000 00:00 0
a459a000-a4d9a000 rwxp a459a000 00:00 0
a4d9a000-a4d9b000 ---p a4d9a000 00:00 0
a4d9b000-a559b000 rwxp a4d9b000 00:00 0
a559b000-a559c000 ---p a559b000 00:00 0
a559c000-a5d9c000 rwxp a559c000 00:00 0
a5d9c000-a5da0000 rw-s 00000000 00:09 7041732 /drm mm object (deleted)
a5da0000-a5da1000 ---p a5da0000 00:00 0
a5da1000-a65a1000 rwxp a5da1000 00:00 0
a65a1000-a65a2000 ---p a65a1000 00:00 0
a65a2000-a6da2000 rwxp a65a2000 00:00 0
a6da2000-a6da3000 ---p a6da2000 00:00 0
a6da3000-a75a3000 rwxp a6da3000 00:00 0
a75a3000-a75a4000 ---p a75a3000 00:00 0
a75a4000-a7da4000 rwxp a75a4000 00:00 0
a7da4000-a7da5000 ---p a7da4000 00:00 0
a7da5000-a85a5000 rwxp a7da5000 00:00 0
a85a5000-a85ad000 rw-s 00000000 00:09 7041718 /drm mm object (deleted)
a85ad000-a85ae000 rw-s 00000000 00:09 7041717 /drm mm object (deleted)
a85ae000-a85af000 ---p a85ae000 00:00 0
a85af000-a8daf000 rwxp a85af000 00:00 0
a8daf000-a8db0000 ---p a8daf000 00:00 0
a8db0000-a95b0000 rwxp a8db0000 00:00 0
a95b0000-a95b1000 ---p a95b0000 00:00 0
a95b1000-a9db1000 rwxp a95b1000 00:00 0
a9db1000-a9db2000 ---p a9db1000 00:00 0
a9db2000-aa5b2000 rwxp a9db2000 00:00 0
aa5b2000-aa5b3000 ---p aa5b2000 00:00 0
aa5b3000-aadb3000 rwxp aa5b3000 00:00 0
aadb3000-aadb4000 ---p aadb3000 00:00 0
aadb4000-ab5b4000 rwxp aadb4000 00:00 0
ab5b4000-ab5b5000 ---p ab5b4000 00:00 0
ab5b5000-abdb5000 rwxp ab5b5000 00:00 0
abdb5000-abdb6000 ---p abdb5000 00:00 0
abdb6000-ac5b6000 rwxp abdb6000 00:00 0
ac5b6000-ac5b7000 ---p ac5b6000 00:00 0
ac5b7000-acdb7000 rwxp ac5b7000 00:00 0
acdb7000-acdb8000 ---p acdb7000 00:00 0
acdb8000-ad5b8000 rwxp acdb8000 00:00 0
ad5b8000-ad5b9000 ---p ad5b8000 00:00 0
ad5b9000-addb9000 rwxp ad5b9000 00:00 0
addb9000-addba000 ---p addb9000 00:00 0
addba000-ae5ba000 rwxp addba000 00:00 0
ae5ba000-ae5bb000 ---p ae5ba000 00:00 0
ae5bb000-aedbb000 rwxp ae5bb000 00:00 0
aedbb000-aedbc000 ---p aedbb000 00:00 0
aedbc000-af5bc000 rwxp aedbc000 00:00 0
af5bc000-af5bd000 ---p af5bc000 00:00 0
af5bd000-afdbd000 rwxp af5bd000 00:00 0
afdbd000-afdbe000 ---p afdbd000 00:00 0
afdbe000-b05be000 rwxp afdbe000 00:00 0
b05be000-b05bf000 ---p b05be000 00:00 0
b05bf000-b0dbf000 rwxp b05bf000 00:00 0
b0dbf000-b0dc7000 rw-s 00000000 00:09 7041683 /drm mm object (deleted)
b0dc7000-b0dcf000 rw-s 00000000 00:09 7041682 Abort
DOH!
But other than this world (which, aside from some inconsequential shifting
of text in two-line blocks, hasn't changed since 2000), I haven't found
another world that kills the viewer--at least, out of the three or four
I've tried. :-)
(Btw, that one's still at http://www.libpng.org/pub/png/pngvrml/pngboxes.wrl
AFAIK there are no errors, but I no longer have a VRML syntax-checker,
and Trapezium/Vorlon is long gone.)
- Speaking of things that haven't changed since 2000, I see the Background
node still doesn't transform with Viewpoint...I know I reported that bug
many, many years ago.
- The normalized-vector warning is kind of annoying. I don't know how much
more normalized it expects me to get, but if 6+ nines won't cut it, there's
something wrong with the code:
orientation -0.10618 0.98856 0.10712 1.5911
sqrt(0.10618*0.10618 + 0.98856*0.98856 + 0.10712*0.10712)
.99999988019999282397
Not a big deal, obviously, but it's also 100% trivial to check whether
the vector's within, say, 0.001 of 1.0, which should be "good enough."
System particulars:
- dual Intel Atom 330 1.6 GHz, 2 GB RAM, Intel 945G graphics
- Ubuntu 2009.04 32-bit (64-bit box shipped that way, argh...)
- Linux "2.6.28-17-generic", gcc 4.3.3, glibc 2.9, libstdc++ 6.0.10 (whatever
version that really is)
- openvrml 0.18.5
Regards,
Greg
|
|
From: Braden M. <br...@en...> - 2010-03-15 09:03:51
|
On Sun, 2010-03-14 at 21:39 -0700, Greg Roelofs wrote:
> Lots o' issues, a few successes...
>
> Docs:
>
> - README needs to call out libtool/libltdl as a required dependency.
Yes, it should.
> - D-Bus does _not_ automatically start openvrml-xembed on my box. No clue
> how that's supposed to work. The workaround mentioned on the list works,
> but the README is slightly misleading.
You do have to install it for this to work. It works (when it does)
because OpenVRML installs a descriptor to a place that D-Bus knows
about. On Fedora, that's:
/usr/share/dbus-1/services/org.openvrml.BrowserControl.service
If D-Bus is looking somewhere different on Debian, that would be a
problem.
> Build:
>
> - AFAICT, it is flat out impossible to do a full openvrml build on reasonably
> modern Debian/Ubuntu. Both xulrunner 1.9.1 (required due to some unique
> header file, according to configure) and 1.8.1 (the source of libmozjs)
> are required, and they cannot be installed simultaneously due to some
> unspecified conflict. Ergo, no JS.
That sounds like something you should complain to Debian's xulrunner
package maintainers about.
> - The dependency list is...stunning. I had to install close to a gigabyte
> of additional stuff, and I already had a fairly decent development box.
> Extra/upgraded Ubuntu packages:
>
> sudo apt-get install libboost1.37-dev libboost1.37-doc
> - [51MB of archives, 183MB of disk space]
> - [gccxml libboost-date-time1.37-dev libboost-date-time1.37.0
> libboost-filesystem1.37-dev libboost-filesystem1.37.0
> libboost-graph1.37-dev libboost-graph1.37.0 libboost-iostreams1.37-dev
> libboost-iostreams1.37.0 libboost-program-options1.37-dev
> libboost-program-options1.37.0 libboost-python1.37-dev
> libboost-python1.37.0 libboost-regex1.37-dev libboost-regex1.37.0
> libboost-serialization1.37-dev libboost-serialization1.37.0
> libboost-signals1.37-dev libboost-signals1.37.0 libboost-system1.37-dev
> libboost-system1.37.0 libboost-test1.37-dev libboost-test1.37.0
> libboost-thread1.37-dev libboost-thread1.37.0 libboost-wave1.37-dev
> libboost-wave1.37.0 libboost1.37-dev libboost1.37-doc]
This could probably be narrowed a bit. But Boost upstream is
distributed en masse; Debian has divided it up.
> sudo apt-get install libpng-dev libjpeg-dev xulrunner-1.9-dev default-jdk libgl1-mesa-dev libglw1-mesa-dev libosmesa6-dev libgtkglext1 libgtkglext1-dev libcurl4-gnutls-dev libdbus-1-dev libdbus-glib-1-dev libsdl1.2debian-pulseaudio doxygen doxygen-doc
> - [25.5MB of archives, 110MB of disk space]
> - [comerr-dev default-jdk doxygen doxygen-doc libcurl4-gnutls-dev
> libdbus-1-dev libdbus-glib-1-dev libgcrypt11-dev libglw1-mesa
> libglw1-mesa-dev libgnutls-dev libgpg-error-dev libgtkglext1
> libgtkglext1-dev libidn11-dev libkadm55 libkrb5-dev libldap2-dev
> libnspr4-dev libnss3-dev libosmesa6 libosmesa6-dev
> libsdl1.2debian-pulseaudio libtasn1-3-dev libxmu-dev libxmu-headers
> openjdk-6-jdk xulrunner-1.9-dev]
> - [REMOVE libsdl1.2debian-alsa]
> sudo apt-get install gcj libgcj-dev libgcj-doc java-gcj-compat java-gcj-compat-dev ant
> - [96.7MB of archives, 604MB of disk space]
> - [ant-gcj ant-optional ant-optional-gcj antlr ecj ecj-gcj fastjar gcj-4.3
> gcj-4.3-base gappletviewer-4.3 gij gij-4.3 gjdoc java-gcj-compat-headless
> libantlr-java libantlr-java-gcj libbcel-java libecj-java libecj-java-gcj
> libgcj-bc libgcj-common libgcj9-0 libgcj9-0-awt libgcj9-dev libgcj9-jar
> libgcj9-src libjaxp1.3-java libjaxp1.3-java-gcj liblog4j1.2-java
> liblog4j1.2-java-gcj libmx4j-java libregexp-java libxerces2-java
> libxerces2-java-gcj]
Dude, I just need jni.h and javac. Blame this on the JDK and/or gcj
folks.
> sudo apt-get install libtool libtool-doc
> - [libltdl7-dev libtool libtool-doc]
> sudo apt-get install libxml2-dev libxml2-doc
> - [libxml2-dev libxml2-doc]
> sudo apt-get install libmozjs-dev
> - [libmozjs-dev]
> sudo apt-get install libgnomeui-dev libgnomeui-doc
> - [4102kB of archives, 21.7MB of disk space]
> - [libart-2.0-dev libavahi-client-dev libavahi-common-dev libavahi-glib-dev
> libbonobo2-dev libbonoboui2-dev libgail-dev libgconf2-dev
> libgnome-keyring-dev libgnome2-dev libgnomecanvas2-dev libgnomeui-dev
> libgnomeui-doc libgnomevfs2-dev libidl-dev liborbit2-dev libpopt-dev
> libselinux1-dev libsepol1-dev orbit2]
Well, that goes to show how much good being a good citizen and not
depending on deprecated GNOME libraries does me. (I'm talking to you,
gnomevfs2.)
> sudo apt-get install xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support
> - [13.5MB of archives, 25.3MB of disk space]
> - [xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support]
> - [REMOVE libmozjs-dev xulrunner-1.9-dev]
I don't think you can blame me or mozilla.org for this. And ordinarily
I really enjoy blaming mozilla.org for stuff.
> The (single-threaded) first, non-JS build took 102 minutes on one of two
> 1.6 GHz Atom 330's; build directory was 820 MB afterward. Still chugging
> away on the second build to work around:
Atoms are, of course, targeted at power efficiency rather than
performance. I have an Atom 330 myself. It's a neat little machine.
But I don't use it to build software.
FWIW, though, OpenVRML's build parallelizes well. You should see some
performance benefit from "make -jN" since the 330 has two cores with
hyperthreading. Of course, you may find yourself memory-limited. But
if you've installed 4 GB in the machine, I think you should be able to
use -j4 safely.
By comparison, an i7 920 using -j8 can build all of OpenVRML in about
five minutes.
> - I'm kind of amazed that, a month after release, nobody has yet noticed
> that JPEG is broken:
>
> if test X$enable_jpeg_textures = Xno; then
> JPEG_LIBS=""
> JPEG_LIBS="-ljpeg"
>
> cat >>confdefs.h <<\_ACEOF
> #define OPENVRML_ENABLE_JPEG_TEXTURES 1
> _ACEOF
>
> fi
>
> Yeah, not so much.
Argh. Missing comma in configure.ac.
> Install:
>
> - Where's sdl-viewer? Oh, buried down in an example directory. Given
> the issues with openvrml-player (below), it would probably be good to
> install sdl-viewer by default (maybe as openvrml-sdl-viewer, for
> consistency and general non-generic-ness).
I'd rather fix openvrml-player. But aside from issues with automatic
activation of openvrml-xembed, it's not clear to me that you're having
problems that aren't shared by sdl-viewer.
> Run:
>
> - openvrml-player doesn't work at all. The best it manages is a single
> frame before crashing, and that only on extremely simple worlds. On at
> least a couple of occasions it chokes with signs of memory corruption:
>
> openvrml-player pngboxes.wrl
> ** (openvrml-xembed:26721): DEBUG: inserted reference to :1.197
> get fences failed: -1
> param: 6, val: 0
> *** glibc detected *** /usr/local/libexec/openvrml-xembed: corrupted double-linked list: 0xb29b35e0 ***
> ======= Backtrace: =========
[snip]
Ouch.
The DEBUG message from openvrml-xembed is normal. Everything south of
that is not.
I can reproduce this; I'll find out what's going on here.
> and simultaneously this stuff showed up for any X event in the player window:
>
> ** (openvrml-player:26724): CRITICAL **: void<unnamed>::reset_fds(<unnamed>::CURLSource&): assertion `Invalid multi handle' failed
> [x many]
That just means that openvrml-xembed has died unexpectedly and the
openvrml-player process doesn't know what to do. :-/
Are the other problem worlds publicly available?
> - sdl-viewer, as someone else (Braden?) noted a few months back, does work
> (mostly), and it conveniently doesn't kill xembed even when the viewer
> aborts.
sdl-viewer doesn't use openvrml-xembed. The idea behind openvrml-xembed
is to have a single viewer backend that is usable as either a
stand-alone viewer or a browser plug-in.
> - Speaking of things that haven't changed since 2000, I see the Background
> node still doesn't transform with Viewpoint...I know I reported that bug
> many, many years ago.
OpenVRML's renderer really needs a near-complete rewrite at this
point. :-/
> - The normalized-vector warning is kind of annoying. I don't know how much
> more normalized it expects me to get, but if 6+ nines won't cut it, there's
> something wrong with the code:
>
> orientation -0.10618 0.98856 0.10712 1.5911
>
> sqrt(0.10618*0.10618 + 0.98856*0.98856 + 0.10712*0.10712)
> .99999988019999282397
>
> Not a big deal, obviously, but it's also 100% trivial to check whether
> the vector's within, say, 0.001 of 1.0, which should be "good enough."
Yes; OpenVRML's float comparison is probably being too picky.
> System particulars:
>
> - dual Intel Atom 330 1.6 GHz, 2 GB RAM, Intel 945G graphics
Ah, 2 GB. Well, since you're using i686 instead of x86_64, "make -j4"
is probably still doable.
> - Ubuntu 2009.04 32-bit (64-bit box shipped that way, argh...)
Fixable. :-) But if you plan on using this to build software, I'd
recommending 4 GB of RAM if you want to use x86_64 Linux. gcc can
consume a lot of memory; and IME, x86_64 can really nearly double its
memory consumption.
Thanks for taking the time to hammer on OpenVRML.
--
Braden McDaniel <br...@en...>
|
|
From: Andreas K. H. <and...@ph...> - 2010-03-15 09:56:31
|
This looks just like the problems I encountered on 0.18.3 on Gentoo. Sorry for not getting back to you so far. I did some quick tests with 0.18.5, saw problems and decided to investigate more before reporting. Then kept postponing this because of other stuff... More in the next days, Andreas > > - openvrml-player doesn't work at all. The best it manages is a single > > frame before crashing, and that only on extremely simple worlds. On at > > least a couple of occasions it chokes with signs of memory corruption: > > > > openvrml-player pngboxes.wrl > > ** (openvrml-xembed:26721): DEBUG: inserted reference to :1.197 > > get fences failed: -1 > > param: 6, val: 0 > > *** glibc detected *** /usr/local/libexec/openvrml-xembed: corrupted double-linked list: 0xb29b35e0 *** > > ======= Backtrace: ========= > > [snip] > > Ouch. > > The DEBUG message from openvrml-xembed is normal. Everything south of > that is not. > > I can reproduce this; I'll find out what's going on here. > > > and simultaneously this stuff showed up for any X event in the player window: > > > > ** (openvrml-player:26724): CRITICAL **: void<unnamed>::reset_fds(<unnamed>::CURLSource&): assertion `Invalid multi handle' failed > > [x many] > > That just means that openvrml-xembed has died unexpectedly and the > openvrml-player process doesn't know what to do. :-/ > > Are the other problem worlds publicly available? -- Dr. Andreas K. Huettel Institute for Experimental and Applied Physics University of Regensburg D-93040 Regensburg Germany tel. +49 151 241 67748 (mobile) e-mail ma...@ak... http://www.akhuettel.de/research/ |
|
From: Greg R. <ne...@po...> - 2010-03-15 17:20:11
|
>> - D-Bus does _not_ automatically start openvrml-xembed on my box. No clue >> how that's supposed to work. The workaround mentioned on the list works, >> but the README is slightly misleading. > You do have to install it for this to work. Sorry, I meant to note that this was after I installed it (openvrml) via "make install" as root. Or did you mean D-Bus itself? > It works (when it does) > because OpenVRML installs a descriptor to a place that D-Bus knows > about. On Fedora, that's: > /usr/share/dbus-1/services/org.openvrml.BrowserControl.service > If D-Bus is looking somewhere different on Debian, that would be a > problem. I have that directory, but there's no openvrml file in there. Very strange. I do see the relevant test and install command in my log, but it didn't work: [...] ---------------------------------------------------------------------- test -z "/usr/local/include/openvrml" || /bin/mkdir -p "/usr/local/include/openvrml" /usr/X11R6/bin/install -c -m 644 libopenvrml/openvrml-config.h libopenvrml/openvrml-common.h libopenvrml-gl/openvrml-gl-config.h libopenvrml-gl/openvrml-gl-common.h '/usr/local/include/openvrml' test -z "/usr/local/share/dbus-1/services" || /bin/mkdir -p "/usr/local/share/dbus-1/services" /usr/X11R6/bin/install -c -m 644 openvrml-xembed/org.openvrml.BrowserControl.service '/usr/local/share/dbus-1/services' make[4]: Leaving directory `/util/3D/openvrml-0.18.5/src' make[3]: Leaving directory `/util/3D/openvrml-0.18.5/src' make[2]: Leaving directory `/util/3D/openvrml-0.18.5/src' make[1]: Leaving directory `/util/3D/openvrml-0.18.5/src' Making install in data [...] Not installed and later removed, either: % ll -d /usr/share/dbus-1/services drwxr-xr-x 2 root 4096 Aug 1 2009 /usr/share/dbus-1/services/ Weird. >> Build: >> >> - AFAICT, it is flat out impossible to do a full openvrml build on reasonably >> modern Debian/Ubuntu. Both xulrunner 1.9.1 (required due to some unique >> header file, according to configure) and 1.8.1 (the source of libmozjs) >> are required, and they cannot be installed simultaneously due to some >> unspecified conflict. Ergo, no JS. > That sounds like something you should complain to Debian's xulrunner > package maintainers about. Yes, this next section was more as a reference for others than explicit bug-reporting. Ubuntu has version 1.9.2 for either Karmic or Lucid, but I don't have sufficient deb-fu to be able to pick that apart and see if whatever conflict they saw has been resolved. (xulrunner's dependency list is even bigger than openvrml's, apparently, so I'm not inclined to try building it manually. The 44MB source tarball is none too inviting, either.) > This could probably be narrowed a bit. But Boost upstream is > distributed en masse; Debian has divided it up. Not a complaint; I can use a modern Boost (and Java, doxygen, and even ant) for other stuff, so I wanted a reasonably complete set. But someone working on Slackware, for example, would be feeling some serious pain at all of the dependencies and sub-dependencies. It's useful to have some idea of what a "complete" list looks like. >> sudo apt-get install xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support >> - [13.5MB of archives, 25.3MB of disk space] >> - [xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support] >> - [REMOVE libmozjs-dev xulrunner-1.9-dev] > I don't think you can blame me or mozilla.org for this. And ordinarily > I really enjoy blaming mozilla.org for stuff. Don't we all, don't we all... Without knowing the nature of the putative incompatibility, it's hard to judge. The Debian/Ubuntu changelog wasn't much help. > > The (single-threaded) first, non-JS build took 102 minutes on one of two > > 1.6 GHz Atom 330's; build directory was 820 MB afterward. Still chugging > > away on the second build to work around: > Atoms are, of course, targeted at power efficiency rather than > performance. I have an Atom 330 myself. It's a neat little machine. > But I don't use it to build software. Again, that wasn't a complaint, just a reference point for others. I had a (slightly) beefier machine but turned it off in favor of this sub-30W, fanless wonderbox. (I ended up adding a quiet, external USB fan last summer since internal temps were approaching the hard drive's stated limits, but it's still virtually inaudible.) > FWIW, though, OpenVRML's build parallelizes well. You should see some > performance benefit from "make -jN" since the 330 has two cores with > hyperthreading. Of course, you may find yourself memory-limited. But > if you've installed 4 GB in the machine, I think you should be able to > use -j4 safely. Very good to know, thanks. It's got only 2 GB and HT is disabled, but there are two real cores in it, so I'll give -j2 a shot next time around. > By comparison, an i7 920 using -j8 can build all of OpenVRML in about > five minutes. Nice. > Are the other problem worlds publicly available? I've just uploaded a tarball here: http://gregroelofs.com/test/grr-openvrml-0.18.5-test.tgz Note that the hypnosphere one is _not_ mine; I believe someone in Europe, possibly Austria, created it, but he didn't leave a name in the comments, and I didn't keep a download reference. Hopefully he won't mind... > sdl-viewer doesn't use openvrml-xembed. The idea behind openvrml-xembed > is to have a single viewer backend that is usable as either a > stand-alone viewer or a browser plug-in. Huh...I completely missed that. OK, that explains it. > OpenVRML's renderer really needs a near-complete rewrite at this > point. :-/ Ah, I thought maybe that had already happened in the last few years. :-) >> - dual Intel Atom 330 1.6 GHz, 2 GB RAM, Intel 945G graphics > Ah, 2 GB. Well, since you're using i686 instead of x86_64, "make -j4" > is probably still doable. I've got both Firefox and SeaMonkey resident and no swap, so I'll be a bit conservative there.... It's just time, and the little box is happy to chug away all night if need be. >> - Ubuntu 2009.04 32-bit (64-bit box shipped that way, argh...) > Fixable. :-) But if you plan on using this to build software, I'd > recommending 4 GB of RAM if you want to use x86_64 Linux. gcc can > consume a lot of memory; and IME, x86_64 can really nearly double its > memory consumption. Good to know, thanks. If the box is capable of it, I may go straight to 8. > Thanks for taking the time to hammer on OpenVRML. Likewise. ;-) It's great to have a working VRML viewer again; time to start modeling the house. Greg |
|
From: Braden M. <br...@en...> - 2010-03-15 20:12:13
|
On Mon, 2010-03-15 at 10:20 -0700, Greg Roelofs wrote: > >> - D-Bus does _not_ automatically start openvrml-xembed on my box. No clue > >> how that's supposed to work. The workaround mentioned on the list works, > >> but the README is slightly misleading. > > > You do have to install it for this to work. > > Sorry, I meant to note that this was after I installed it (openvrml) via > "make install" as root. Or did you mean D-Bus itself? Presumably D-Bus is already installed on a reasonably modern Linux. > > It works (when it does) > > because OpenVRML installs a descriptor to a place that D-Bus knows > > about. On Fedora, that's: > > > /usr/share/dbus-1/services/org.openvrml.BrowserControl.service > > > If D-Bus is looking somewhere different on Debian, that would be a > > problem. > > I have that directory, but there's no openvrml file in there. Very strange. > I do see the relevant test and install command in my log, but it didn't work: > > [...] > ---------------------------------------------------------------------- > test -z "/usr/local/include/openvrml" || /bin/mkdir -p "/usr/local/include/openvrml" > /usr/X11R6/bin/install -c -m 644 libopenvrml/openvrml-config.h libopenvrml/openvrml-common.h libopenvrml-gl/openvrml-gl-config.h libopenvrml-gl/openvrml-gl-common.h '/usr/local/include/openvrml' > test -z "/usr/local/share/dbus-1/services" || /bin/mkdir -p "/usr/local/share/dbus-1/services" > /usr/X11R6/bin/install -c -m 644 openvrml-xembed/org.openvrml.BrowserControl.service '/usr/local/share/dbus-1/services' > make[4]: Leaving directory `/util/3D/openvrml-0.18.5/src' > make[3]: Leaving directory `/util/3D/openvrml-0.18.5/src' > make[2]: Leaving directory `/util/3D/openvrml-0.18.5/src' > make[1]: Leaving directory `/util/3D/openvrml-0.18.5/src' > Making install in data > [...] > > Not installed and later removed, either: > > % ll -d /usr/share/dbus-1/services > drwxr-xr-x 2 root 4096 Aug 1 2009 /usr/share/dbus-1/services/ > > Weird. You're installing OpenVRML under /usr/local while you have D-Bus installed under /usr. So, openvrml-xembed's service descriptor is going to wind up in /usr/local/share/dbus-1/services. > > Are the other problem worlds publicly available? > > I've just uploaded a tarball here: > > http://gregroelofs.com/test/grr-openvrml-0.18.5-test.tgz Thanks. I'll check these out. > > sdl-viewer doesn't use openvrml-xembed. The idea behind openvrml-xembed > > is to have a single viewer backend that is usable as either a > > stand-alone viewer or a browser plug-in. > > Huh...I completely missed that. OK, that explains it. sdl-viewer also only knows how to load local files. libopenvrml is network-agnostic; and this extends to openvrml-xembed. openvrml-xembed actually relies on its container to provide resource fetching services. openvrml-player uses libcurl for that part, while the Web browser plug-in uses NPAPI services. > > Fixable. :-) But if you plan on using this to build software, I'd > > recommending 4 GB of RAM if you want to use x86_64 Linux. gcc can > > consume a lot of memory; and IME, x86_64 can really nearly double its > > memory consumption. > > Good to know, thanks. If the box is capable of it, I may go straight to 8. The 330 is a quirky little beast. Even though it supports x86_64, it can only see 4 GB of memory. (Well, really more like 3.5.) -- Braden McDaniel <br...@en...> |
|
From: Greg R. <ne...@po...> - 2010-03-16 06:09:18
|
> You're installing OpenVRML under /usr/local while you have D-Bus
> installed under /usr. So, openvrml-xembed's service descriptor is going
> to wind up in /usr/local/share/dbus-1/services.
Doh! I completely missed the "local" difference there. Sorry, pilot error.
I'll either figure out how to configure the /usr/local directory into D-Bus
or else move the openvrml file into /usr.
> sdl-viewer also only knows how to load local files.
I'm not saying I prefer it over openvrml-player (aside from the not-crashing
part); it's simply what I got working, and I can make some progress now. I
would totally love a supported in-browser or browser-like player, though.
> The 330 is a quirky little beast. Even though it supports x86_64, it
> can only see 4 GB of memory. (Well, really more like 3.5.)
Really? Dang, you'd think that would the kind of thing Intel would actually
document somewhere, but there's no mention of it on this page...
http://ark.intel.com/Product.aspx?id=35641&processor=330&spec-codes=SLG9Y
...nor in their datasheet:
http://download.intel.com/design/processor/datashts/320528.pdf
(unless it's _really_ obscure, like some implicit FSB signalling or pinout
restriction). How annoying.
(I see they do now mention it explicitly for their newer Atom processors,
though.)
Thanks,
Greg
|
|
From: Braden M. <br...@en...> - 2010-03-16 15:14:23
|
On Mon, 2010-03-15 at 23:09 -0700, Greg Roelofs wrote: > > You're installing OpenVRML under /usr/local while you have D-Bus > > installed under /usr. So, openvrml-xembed's service descriptor is going > > to wind up in /usr/local/share/dbus-1/services. > > Doh! I completely missed the "local" difference there. Sorry, pilot error. > I'll either figure out how to configure the /usr/local directory into D-Bus > or else move the openvrml file into /usr. It would be nice if there were some environment variable one could set to tell D-Bus about other directories. If that exists, I don't know what it is. :-/ > > The 330 is a quirky little beast. Even though it supports x86_64, it > > can only see 4 GB of memory. (Well, really more like 3.5.) > > Really? Dang, you'd think that would the kind of thing Intel would actually > document somewhere, but there's no mention of it on this page... > > http://ark.intel.com/Product.aspx?id=35641&processor=330&spec-codes=SLG9Y Yeah, you'd think. > ...nor in their datasheet: > > http://download.intel.com/design/processor/datashts/320528.pdf > > (unless it's _really_ obscure, like some implicit FSB signalling or pinout > restriction). How annoying. The closest the datasheet comes to making this clear is Table 4-13 in the description of the A[32:3]# signal. To say it could be clearer would be quite an understatement. -- Braden McDaniel <br...@en...> |
|
From: Greg R. <ne...@po...> - 2010-03-19 17:32:01
|
>> Are the other problem worlds publicly available? > I've just uploaded a tarball here: The weird brown desktop in the cubicles model in the tarball was bothering me, but I thought it must have been due to some subtle alignment issue between that specific bit of geometry and my light source(s). Doesn't look like it, though: http://gregroelofs.com/test/cubicles-moved-DeskCorner.wrl (Note that the textures aren't there, so copy that file wherever you unpacked the tarball for complete parity with cubicles.wrl. The relevant "feature" isn't dependent on the textures, though.) Anyway, that's an identical file except that the specific instance of the DeskCorner proto that was brown in cubicles.wrl has been moved in front of all the other desk-related instances (about 20-30 lines up). Now it works correctly, i.e., it matches all the other desktop surfaces. I'm wondering of this is another manifestation of the apparent memory corruption seen in the crashes. There are similar color oddities on all of the rectangular portions of desktop (Desk_2x2 protos), but only on the (exposed) sides and undersurfaces. I haven't completely verified that that's not a real artifact/oversight in the model, but I've got some old screenshots from other browsers that suggest it's not normal (so to speak). Btw, note that the weird brown color is almost identical to that of the cubicle sides visible from the second viewpoint. This is more apparent if you mouse-rotate the first (top down) viewpoint a bit. Oh, and one other gotcha with sdl-viewer: it appears that any X events (e.g., mouseover) while it's setting up the initial scene will lock up X input in a way reminiscent of the old Motif menu-focus-grab lockups. The mouse still moves, but focus doesn't change, and neither mouseclicks nor keyboard input are accepted. Since modern X no longer supports the old AllowDeactivateGrabs option, I can't verify that it's actually a grab issue, but that's what it feels like. (Logging in from another machine and killing the sdl-viewer process takes care of it.) Greg |
|
From: Braden M. <br...@en...> - 2010-03-29 20:58:20
|
On Fri, 2010-03-19 at 10:31 -0700, Greg Roelofs wrote: > >> Are the other problem worlds publicly available? > > > I've just uploaded a tarball here: > > The weird brown desktop in the cubicles model in the tarball was bothering > me, but I thought it must have been due to some subtle alignment issue > between that specific bit of geometry and my light source(s). Doesn't > look like it, though: > > http://gregroelofs.com/test/cubicles-moved-DeskCorner.wrl > > (Note that the textures aren't there, so copy that file wherever you > unpacked the tarball for complete parity with cubicles.wrl. The relevant > "feature" isn't dependent on the textures, though.) > > Anyway, that's an identical file except that the specific instance of the > DeskCorner proto that was brown in cubicles.wrl has been moved in front of > all the other desk-related instances (about 20-30 lines up). Now it works > correctly, i.e., it matches all the other desktop surfaces. > > I'm wondering of this is another manifestation of the apparent memory > corruption seen in the crashes. Could be. I'm still trying to get a handle on exactly what's going on here. I'm getting closer; I think I'm looking at a race between some stream handling threads. But I haven't isolated it yet. > Oh, and one other gotcha with sdl-viewer: it appears that any X events > (e.g., mouseover) while it's setting up the initial scene will lock up X > input in a way reminiscent of the old Motif menu-focus-grab lockups. The > mouse still moves, but focus doesn't change, and neither mouseclicks nor > keyboard input are accepted. Since modern X no longer supports the old > AllowDeactivateGrabs option, I can't verify that it's actually a grab > issue, but that's what it feels like. (Logging in from another machine > and killing the sdl-viewer process takes care of it.) I'll give this a looksee once I've resolved the crasher bugs; but an sdl-viewer specific bug might not get a very high priority from me. -- Braden McDaniel <br...@en...> |
|
From: Greg R. <ne...@po...> - 2010-03-29 22:35:00
|
>> Oh, and one other gotcha with sdl-viewer: it appears that any X events >> (e.g., mouseover) while it's setting up the initial scene will lock up X >> input in a way reminiscent of the old Motif menu-focus-grab lockups. The >> mouse still moves, but focus doesn't change, and neither mouseclicks nor >> keyboard input are accepted. Since modern X no longer supports the old >> AllowDeactivateGrabs option, I can't verify that it's actually a grab >> issue, but that's what it feels like. (Logging in from another machine >> and killing the sdl-viewer process takes care of it.) > I'll give this a looksee once I've resolved the crasher bugs; but an > sdl-viewer specific bug might not get a very high priority from me. I was mistaken about the X events part--it occurs even without any mouse or keyboard activity at all (in fact, sole X event is initial expose, I think). It seems to be simply a one-in-20 (or so) error condition. I'm not certain, but I _think_ I saw it in freewrl yesterday, which may suggest a driver bug rather than either app. Newly seen rendering-model issue: with a half-transparent covering (a roof in this case), visibility of the underlying stuff depends entirely on the objects' order in the world file. This order... aerial-view ground texture (square) 50% tranparent roof house geometry house objects (more monitors :-) ) ...resulted in a completely invisible house and objects when seen from above; the texture is all that showed through the roof. This order, on the other hand... house geometry 50% tranparent roof house objects (monitors) aerial-view ground texture ...caused only the monitors and portions of the ground texture at the edges of the roof (i.e., without house geometry intervening) to disappear. Thus the only workable place for the roof is as the last geometry element in the file--unless one _wants_ the other stuff to go away, that is, which briefly proved useful when aligning the model with the aerial texture. Greg |
|
From: Braden M. <br...@en...> - 2010-04-01 19:57:27
|
On 3/29/10 4:58 PM, Braden McDaniel wrote: > I'm still trying to get a handle on exactly what's going on > here. I'm getting closer; I think I'm looking at a race between some > stream handling threads. But I haven't isolated it yet. This may or may not be the case. Regardless, there is definitely something screwy going on in the PNG decoder. I think what's happening is that for some images, the decoder is not detecting the number of pixel components correctly and consequently isn't giving libpng a big enough buffer to work with. libpng calls then proceed to stomp all over memory (which on my machine appears consistently to be the browser's node_metatype_registry); hilarity ensues. -- Braden McDaniel <br...@en...> |
|
From: Braden M. <br...@en...> - 2010-05-03 06:26:08
|
On Thu, 2010-04-01 at 15:57 -0400, Braden McDaniel wrote:
> On 3/29/10 4:58 PM, Braden McDaniel wrote:
> > I'm still trying to get a handle on exactly what's going on
> > here. I'm getting closer; I think I'm looking at a race between some
> > stream handling threads. But I haven't isolated it yet.
>
> This may or may not be the case. Regardless, there is definitely
> something screwy going on in the PNG decoder. I think what's happening
> is that for some images, the decoder is not detecting the number of
> pixel components correctly and consequently isn't giving libpng a big
> enough buffer to work with. libpng calls then proceed to stomp all over
> memory (which on my machine appears consistently to be the browser's
> node_metatype_registry); hilarity ensues.
This bug continues to elude me. :-(
I have discovered a few things...
* Even if I comment out all of the texture URLs in pngboxes.wrl, I
get a segfault in sdl-viewer occasionally. So there's
*something* screwy going on irrespective of the image loading
code.
* Fiddling with valgrind has made it clear that Text nodes are
leaky. But, since valgrind isn't showing a lot of the symbols in
its backtrace to the allocation point, tracking the leaks down
is difficult. I found one spot where we were leaking FT_Glyphs
and fixed it; but it seems there's more. However, it seems
unlikely that this is the source of the memory *corruption* that
appears to be happening.
* One somewhat ominous looking message I'm getting from valgrind
is pointing to my Spirit-based node metatype identifier parser
(which is just a minor augmentation of my URI parser). It's not
obvious to me that I'm doing something wrong here; conceivably
there's some threading-related bug in Spirit. However, Spirit
has been substantially rewritten since I wrote this; and my code
has not been updated to take advantage of the new version. As I
doubt the Spirit developers are hugely interested in possible
obscure bugs in the old version of their project, my next step
is to rewrite my URI and node metatype identifier parsers using
Spirit2.
One nice side effect of me combing through the text rendering code is
that I have broken some big scary functions into smaller scary
functions.
--
Braden McDaniel <br...@en...>
|
|
From: Braden M. <br...@en...> - 2010-05-21 09:16:51
|
On Mon, 2010-05-03 at 02:26 -0400, Braden McDaniel wrote: > On Thu, 2010-04-01 at 15:57 -0400, Braden McDaniel wrote: > > On 3/29/10 4:58 PM, Braden McDaniel wrote: > > > I'm still trying to get a handle on exactly what's going on > > > here. I'm getting closer; I think I'm looking at a race between some > > > stream handling threads. But I haven't isolated it yet. > > > > This may or may not be the case. Regardless, there is definitely > > something screwy going on in the PNG decoder. I think what's happening > > is that for some images, the decoder is not detecting the number of > > pixel components correctly and consequently isn't giving libpng a big > > enough buffer to work with. libpng calls then proceed to stomp all over > > memory (which on my machine appears consistently to be the browser's > > node_metatype_registry); hilarity ensues. > > This bug continues to elude me. :-( > > I have discovered a few things... > > * Even if I comment out all of the texture URLs in pngboxes.wrl, I > get a segfault in sdl-viewer occasionally. So there's > *something* screwy going on irrespective of the image loading > code. I still need to investigate this further... > * One somewhat ominous looking message I'm getting from valgrind > is pointing to my Spirit-based node metatype identifier parser > (which is just a minor augmentation of my URI parser). I tried updating the URI parser to use Spirit2; and this did get rid of the ominous valgrind message. It did not, however, fix The Problem. I did finally discover a problem in the PNG reader that was leading to memory corruption. I've committed a fix for this on the trunk and the 0.18 branch. This has certainly addressed a significant problem with pngboxes.wrl; though I'm not sure it was the only problem. I'll be out of town this weekend; so it will probably be sometime next week before I'm able to test things more thoroughly. In the meantime, the changes have been committed in case anyone else is interested in taking them for a spin. -- Braden McDaniel <br...@en...> |
|
From: Greg R. <ne...@po...> - 2010-05-21 15:33:49
|
> I did finally discover a problem in the PNG reader that was leading to > memory corruption. I've committed a fix for this on the trunk and the > 0.18 branch. This has certainly addressed a significant problem with > pngboxes.wrl; though I'm not sure it was the only problem. > I'll be out of town this weekend; so it will probably be sometime next > week before I'm able to test things more thoroughly. In the meantime, > the changes have been committed in case anyone else is interested in > taking them for a spin. Many thanks, Braden! If I can find time this weekend, I'll check out the 0.18 branch and give it a spin. Greg |
|
From: Braden M. <br...@en...> - 2010-05-28 04:06:40
|
On Fri, 2010-05-21 at 08:33 -0700, Greg Roelofs wrote: > > I did finally discover a problem in the PNG reader that was leading to > > memory corruption. I've committed a fix for this on the trunk and the > > 0.18 branch. This has certainly addressed a significant problem with > > pngboxes.wrl; though I'm not sure it was the only problem. > > > I'll be out of town this weekend; so it will probably be sometime next > > week before I'm able to test things more thoroughly. In the meantime, > > the changes have been committed in case anyone else is interested in > > taking them for a spin. > > Many thanks, Braden! If I can find time this weekend, I'll check out the > 0.18 branch and give it a spin. It looks like there are still problems in the JPEG reader that cause a crash. :-/ -- Braden McDaniel <br...@en...> |
|
From: Braden M. <br...@en...> - 2010-05-28 15:22:43
|
On Fri, 2010-05-28 at 00:06 -0400, Braden McDaniel wrote: > On Fri, 2010-05-21 at 08:33 -0700, Greg Roelofs wrote: > > > I did finally discover a problem in the PNG reader that was leading to > > > memory corruption. I've committed a fix for this on the trunk and the > > > 0.18 branch. This has certainly addressed a significant problem with > > > pngboxes.wrl; though I'm not sure it was the only problem. > > > > > I'll be out of town this weekend; so it will probably be sometime next > > > week before I'm able to test things more thoroughly. In the meantime, > > > the changes have been committed in case anyone else is interested in > > > taking them for a spin. > > > > Many thanks, Braden! If I can find time this weekend, I'll check out the > > 0.18 branch and give it a spin. > > It looks like there are still problems in the JPEG reader that cause a > crash. :-/ This is now fixed. Unfortunately, the JPEG corruption issue described in trac ticket #29 is still a problem. But at least it doesn't crash. In light of these crash fixes (and some other stuff), I'll release 0.18.6 this weekend. -- Braden McDaniel <br...@en...> |
|
From: Braden M. <br...@en...> - 2010-05-27 16:38:04
|
On Mon, 2010-05-03 at 02:26 -0400, Braden McDaniel wrote: [snip] > * Fiddling with valgrind has made it clear that Text nodes are > leaky. But, since valgrind isn't showing a lot of the symbols in > its backtrace to the allocation point, tracking the leaks down > is difficult. I found one spot where we were leaking FT_Glyphs > and fixed it; but it seems there's more. However, it seems > unlikely that this is the source of the memory *corruption* that > appears to be happening. I finally tracked this down to stuff leaked (more or less deliberately) by Fontconfig. Calling FcFini will clean it up; but FcFini cannot be called safely from library code (since it cannot be called redundantly). So I've modified sdl_viewer.cpp to call FcFini on shutdown, since that's what I normally use to check for leaks in the library code. -- Braden McDaniel <br...@en...> |
Thanks for helping keep SourceForge clean.
X