Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 20:31:58



Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3, 4  Next
Crash on export object/s recent Linux releases 
Author Message

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Using a recompiled library (I guess, with PCRE statically linked to it) is in no way a fix... At best, it's a work around, and one that works only for one Linux distribution, and only for one buggy version of this distribution, and a workaround that could cause more issues in other distros (with mixed PCRE versions used as a result in the viewer and its dynamic libraries)... The bug itself is in Ubuntu: Ubuntu's dev have to fix their buggy package. Period.

Please report the bug to Ubuntu's upstream/packager for that library (GTK/PCRE/whatever).


2012-08-13 18:06:38
Profile WWW

Joined: 2009-09-08 01:27:46
Posts: 172
Reply with quote
I've run into a major issue with downloading textures or saving snapshots to my hard drive. I would try to open a directory where I keep specific snapshots (for use as backdrops in my web comic), and the viewer would instantly CTD upon entering the directory. I did some experimenting, and I found that the crash is triggered by navigating the file picker into any directory that has images in it.

I've included a tar.gz archive of the crash logs, though the file crashreport.log was not included because it was not written during the crash.

Code:
Viewer Info:

Cool VL Viewer 1.26.4 (23) Aug  4 2012 14:26:33 (Cool VL Viewer)
Release Notes

CPU: AMD Phenom(tm) II X4 970 Processor (3500 MHz)
Memory: 7989 MB
OS Version: Linux 3.4.8-1-ck #1 SMP PREEMPT Thu Aug 9 17:09:09 EDT 2012 x86_64
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 460/PCIe/SSE2
OpenGL Version: 4.2.0 NVIDIA 304.32

libcurl Version: libcurl/7.21.1 OpenSSL/1.0.0d zlib/1.2.5 c-ares/1.7.1
J2C Decoder Version: KDU
Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.11.753 / OpenAL Community / OpenAL Soft: PulseAudio Software
Qt Webkit Version: 4.7.1 (version number hard-coded)

Built with GCC version 40302

Compile flags used for this build:
-O2 -fomit-frame-pointer -frename-registers -fweb -ftree-vectorize -fexpensive-optimizations -DLL_RELEASE=1 -DLL_RELEASE_FOR_DOWNLOAD=1 -DLL_SEND_CRASH_REPORTS=1 -DNDEBUG -Wall -Wno-sign-compare -Wno-trigraphs -Werror -Wno-reorder -Wno-non-virtual-dtor -Wno-deprecated -g -fexceptions -fno-strict-aliasing -fvisibility=hidden -fsigned-char -march=pentium4 -msse2 -mfpmath=sse -fno-math-errno -fno-trapping-math -pthread -fno-stack-protector -m32 -D_FORTIFY_SOURCE=2 -DLL_USE_TCMALLOC=1 -DLL_LINUX=1 -D_REENTRANT -DAPPID=secondlife -DLL_IGNORE_SIGCHLD -DLL_DBUS_ENABLED=1 -DLL_ELFBIN=1 -DOV_EXCLUDE_STATIC_CALLBACKS -DCARES_STATICLIB -DLL_SDL=1 -DLIB_NDOF=1 -DLL_GTK=1 -DLL_X11=1


Attachments:
File comment: Crash logs for viewer
crashlogs_08_14_2012.tar.gz [5.29 KiB]
Downloaded 132 times
2012-08-14 14:21:28
Profile WWW

Joined: 2009-09-08 01:27:46
Posts: 172
Reply with quote
A couple of notes:
* This function worked fine in the prior stable branch (1.26.2), so I don't think that the fact that I'm on a 64bit system is to blame
* The initial folder the file picker opens up with will not cause a crash if it has images in it, the crash is only when navigating to other folders.


Also, I did another test with uploads, and initially believed that they were not affected. However, upon navigating to another folder I knew triggered the crash. My theory is that this issue is caused by navigating to folders with images above a certain size. The folder with images that did not trigger the crash didn't have any images larger than 1024x1024. Meanwhile, the folders that did cause the crash had high-definition desktop backgrounds made for 1920x1080, and another had some fullscreen snapshots for that same size.


2012-08-14 14:40:23
Profile WWW

Joined: 2009-09-08 01:27:46
Posts: 172
Reply with quote
Last week I had to change linux distributions due to a change in Fontconfig 2.10 which rendered all viewers unusable (CTD before it hits the login screen). So, I chose to use Ubuntu so that I could continue running the viewers (and because I grew tired of Arch Linux's overly experimental nature).

All viewers seem to work fine, except for Cool VL Viewer. Under both the experimental and stable versions, any attempt to save a texture/snapshot to my hard drive results in the viewer locking up, requiring me to force-kill it from the command line.

As a note: my system is 64bit, but I doubt that is the cause of the problem because the 32bit InWorldz Viewer runs under 64bit Linux just fine.

Viewer Information.
Code:
Cool VL Viewer 1.26.4 (29) Sep  8 2012 10:20:49 (Cool VL Viewer)
Release Notes

CPU: AMD Phenom(tm) II X4 970 Processor (800 MHz)
Memory: 7985 MB
OS Version: Linux 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 x86_64
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 460/PCIe/SSE2
OpenGL Version: 4.2.0 NVIDIA 295.40

libcurl Version: libcurl/7.21.1 OpenSSL/1.0.0d zlib/1.2.5 c-ares/1.7.1
J2C Decoder Version: KDU
Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.11.753 / OpenAL Community / OpenAL Soft: PulseAudio Software
Qt Webkit Version: 4.7.1 (version number hard-coded)

Built with GCC version 40302

Compile flags used for this build:
-O2 -fomit-frame-pointer -frename-registers -fweb -ftree-vectorize -fexpensive-optimizations -DLL_RELEASE=1 -DLL_RELEASE_FOR_DOWNLOAD=1 -DLL_SEND_CRASH_REPORTS=1 -DNDEBUG -Wall -Wno-sign-compare -Wno-trigraphs -Werror -Wno-reorder -Wno-non-virtual-dtor -Wno-deprecated -g -fexceptions -fno-strict-aliasing -fvisibility=hidden -fsigned-char -march=pentium4 -msse2 -mfpmath=sse -fno-math-errno -fno-trapping-math -pthread -fno-stack-protector -m32 -D_FORTIFY_SOURCE=2 -DLL_USE_TCMALLOC=1 -DLL_LINUX=1 -D_REENTRANT -DAPPID=secondlife -DLL_IGNORE_SIGCHLD -DLL_DBUS_ENABLED=1 -DLL_ELFBIN=1 -DOV_EXCLUDE_STATIC_CALLBACKS -DCARES_STATICLIB -DLL_SDL=1 -DLIB_NDOF=1 -DLL_GTK=1 -DLL_X11=1


2012-09-13 13:26:35
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Zauber Exonar wrote:
Last week I had to change linux distributions due to a change in Fontconfig 2.10 which rendered all viewers unusable (CTD before it hits the login screen). So, I chose to use Ubuntu so that I could continue running the viewers (and because I grew tired of Arch Linux's overly experimental nature).

All viewers seem to work fine, except for Cool VL Viewer. Under both the experimental and stable versions, any attempt to save a texture/snapshot to my hard drive results in the viewer locking up, requiring me to force-kill it from the command line.

As a note: my system is 64bit, but I doubt that is the cause of the problem because the 32bit InWorldz Viewer runs under 64bit Linux just fine.

Viewer Information.
Code:
Cool VL Viewer 1.26.4 (29) Sep  8 2012 10:20:49 (Cool VL Viewer)
Release Notes

CPU: AMD Phenom(tm) II X4 970 Processor (800 MHz)
Memory: 7985 MB
OS Version: Linux 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 x86_64
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 460/PCIe/SSE2
OpenGL Version: 4.2.0 NVIDIA 295.40

libcurl Version: libcurl/7.21.1 OpenSSL/1.0.0d zlib/1.2.5 c-ares/1.7.1
J2C Decoder Version: KDU
Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.11.753 / OpenAL Community / OpenAL Soft: PulseAudio Software
Qt Webkit Version: 4.7.1 (version number hard-coded)

Built with GCC version 40302

Compile flags used for this build:
-O2 -fomit-frame-pointer -frename-registers -fweb -ftree-vectorize -fexpensive-optimizations -DLL_RELEASE=1 -DLL_RELEASE_FOR_DOWNLOAD=1 -DLL_SEND_CRASH_REPORTS=1 -DNDEBUG -Wall -Wno-sign-compare -Wno-trigraphs -Werror -Wno-reorder -Wno-non-virtual-dtor -Wno-deprecated -g -fexceptions -fno-strict-aliasing -fvisibility=hidden -fsigned-char -march=pentium4 -msse2 -mfpmath=sse -fno-math-errno -fno-trapping-math -pthread -fno-stack-protector -m32 -D_FORTIFY_SOURCE=2 -DLL_USE_TCMALLOC=1 -DLL_LINUX=1 -D_REENTRANT -DAPPID=secondlife -DLL_IGNORE_SIGCHLD -DLL_DBUS_ENABLED=1 -DLL_ELFBIN=1 -DOV_EXCLUDE_STATIC_CALLBACKS -DCARES_STATICLIB -DLL_SDL=1 -DLIB_NDOF=1 -DLL_GTK=1 -DLL_X11=1

Merging your (incomplete: where are the logs ?) report with the existing, relevant topic. This is an Ubuntu bug: please transmit to Ubuntu support and upstream for their buggy GTK binaries.


2012-09-13 17:49:50
Profile WWW

Joined: 2009-09-08 01:27:46
Posts: 172
Reply with quote
Okay Henri, out of all the viewers I've used in this past year, I have only ever had problems with Cool VL Viewer. Imprudence, Kokua, Hippo, the InWorldz Viewer, and the official Second Life viewer all run without any notable stability issues. Based on the fact that I had these problems with saving textures and snapshots to disk for over a month prior to switching to Ubuntu, and do not have them with any other viewers, I seriously doubt that it's a problem with Ubuntu's GTK. And again, it isn't a 32bit issue with my 64bit system: IW Viewer's 32bit version works without any problems. I strongly suggest you take a closer look at your code and do some comparisons with other viewers known to work.

But, if you insist there's nothing wrong with your code, it's not my problem anymore. For the past two years I have only used Cool VL Viewer for taking full-screen snapshots with deferred rendering. Because of the current crashing and freezing issues I've been experiencing this past month, I cannot use it anymore because I needed it for the snapshot-to-disk functionality. Because of that and other problems I've had with Cool VL Viewer, I'm just going to use Kokua for photography.


2012-09-13 22:15:59
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Zauber Exonar wrote:
Okay Henri, out of all the viewers I've used in this past year, I have only ever had problems with Cool VL Viewer. Imprudence, Kokua, Hippo, the InWorldz Viewer
None of which are using colladadom (since they don't support mesh at all), which is the library affected by the bug in Ubuntu GTK...

Quote:
and the official Second Life viewer
Really ?... The latest mesh versions ?... I doubt that: there's even a JIRA for it (see the messages above).

Quote:
But, if you insist there's nothing wrong with your code,
There is indeed nothing wrong here (using Mandriva): I just can't reproduce these crashes !

Quote:
it's not my problem anymore. For the past two years I have only used Cool VL Viewer for taking full-screen snapshots with deferred rendering. Because of the current crashing and freezing issues I've been experiencing this past month, I cannot use it anymore because I needed it for the snapshot-to-disk functionality. Because of that and other problems I've had with Cool VL Viewer, I'm just going to use Kokua for photography.
That's your call. Since anyway you don't provide proper bug reports (with SecondLife.log and crash log), it's not my problem any more either !


2012-09-13 22:52:52
Profile WWW

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
Hi Henri, hello everyone,

there seem to be several odd issues surrounding the GTK file dialog, at least under Ubuntu Precise 64, ever since the switch to the new libraries, I presume. So far I haven't bothered bringing them up despite them being a pain in the behind, because I want to pin them down further before sending Henri off on a wild goose chase.

I have observed two distinct scenarios now:

(1) The viewer (anything past 1.26.4.22, which is my 'old libs' reference) will crash immediately when attempting to open the GTK file picker. This seems to happen if the first invocation of the 32-bit GTK file picker since reboot (or just restart of X? -- need to check) is performed by the viewer. Unfortunately I don't have any crash info handy at the moment, but I distinctly remember it being an FT_glyph-something, so I presume freetype is involved. Incidentally, in this scenario, the file picker never even shows.

It works fine with 1.26.4.22, on the other hand. And once the GTK file picker has managed to open from there, opening it from later versions of the viewer works just as well. Same goes if I open the GTK file picker the first time with, say, Acrobat reader (which is 32 Bit as well) -- after that, no issues with later viewers. So I presume there is something about the (context of?) the file picker and/or how it is/isn't initialized that will cause this behaviour. It may technically not be a viewer bug, though -- no idea. I'll add crash info no less the next time I forget to "initialize" the file picker first.

(2) This one's odd. Doesn't always happen, is definitely tcmalloc related and not an OOM condition. It happens with a variable delay after the file picker has executed. I have two crash dumps I am attaching, maybe it will shed a tiny flashlight on this oddity.


Love,
Lia


Attachments:
File comment: Crash info for the 2 tcmalloc-related crashes
FilePickerCrashes.tar.bz2 [33.23 KiB]
Downloaded 129 times
2012-09-14 10:03:49
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Amalia Illios wrote:
Hi Henri, hello everyone,

there seem to be several odd issues surrounding the GTK file dialog, at least under Ubuntu Precise 64, ever since the switch to the new libraries, I presume. So far I haven't bothered bringing them up despite them being a pain in the behind, because I want to pin them down further before sending Henri off on a wild goose chase.

I have observed two distinct scenarios now:

(1) The viewer (anything past 1.26.4.22, which is my 'old libs' reference) will crash immediately when attempting to open the GTK file picker. This seems to happen if the first invocation of the 32-bit GTK file picker since reboot (or just restart of X? -- need to check) is performed by the viewer. Unfortunately I don't have any crash info handy at the moment, but I distinctly remember it being an FT_glyph-something, so I presume freetype is involved. Incidentally, in this scenario, the file picker never even shows.

It works fine with 1.26.4.22, on the other hand. And once the GTK file picker has managed to open from there, opening it from later versions of the viewer works just as well. Same goes if I open the GTK file picker the first time with, say, Acrobat reader (which is 32 Bit as well) -- after that, no issues with later viewers. So I presume there is something about the (context of?) the file picker and/or how it is/isn't initialized that will cause this behaviour. It may technically not be a viewer bug, though -- no idea. I'll add crash info no less the next time I forget to "initialize" the file picker first.
The only difference between v1.26.4.22 and newer releases is that the latter are linked against the newest LL's pre-built libraries instead of against a mix of old Snowglobe ones, personal builds, and v2.4 pre-built libraries from LL... There has been no other change in the viewer-side GTK file picker calling code. I assume some incompatibility arose between LL's pre-built libraries and Ubuntu v12, but it would be an Ubuntu specific issue (not seeing any such issue here, with Mandriva 2010.2 32bits)...

One thing you could try, just in case, is to add the following lines in the cool_vl_viewer wrapper scipt, above the "## Nothing worth editing below this line." comment:
Code:
export LANG=C
export LANGUAGE=C
export LC_ALL=C
It will force glibc to use the default (english) locale instead of your system locale. I've seen many such weird locale issues in the past, and it could possibly work around the UTF-8 issue with colladadom and GTK.

Quote:
(2) This one's odd. Doesn't always happen, is definitely tcmalloc related and not an OOM condition. It happens with a variable delay after the file picker has executed. I have two crash dumps I am attaching, maybe it will shed a tiny flashlight on this oddity.
Interesting... But again, non-reproducible here. I just had a look at newer tcmalloc versions, however, and noticed a bug fix in v1.9 that could possibly explain such crashes in v1.8.3 (from tcmalloc Changelog: "BUGFIX: Fix a race with the CentralFreeList lock before main"). I'll use tcmalloc v1.10 (exact same code as the newest v2.0 but without possible function renaming issues) for the next releases and see what happens. You could try and see by yourself by replacing libtcmalloc.so.0 in the viewer installation lib/ sub-directory with the binary available here.
Also, are you using the "Advanced" -> "UI" -> "Use a non-blocking file picker" option or not ?... Does it make a difference when you toggle it ?


2012-09-14 12:25:35
Profile WWW

Joined: 2010-04-07 08:23:18
Posts: 210
Reply with quote
Hi again Henri,

you wrote:
Henri Beauchamp wrote:
I assume some incompatibility arose between LL's pre-built libraries and Ubuntu v12, but it would be an Ubuntu specific issue (not seeing any such issue here, with Mandriva 2010.2 32bits)...
That's why I'm skeptical, yes, and why I am using the last 'old' lib version as a base. When you switched I was making a point of keeping it, since I did expect any issues popping up possibly not rearing their ugly heads until much later. Some of what looks to be "Ubuntu specific" might in fact be stuff caused by erroneous packaging regarding the MultiArch file system layout. I have manually corrected a few of those on my system to avoid 32-Bit GTK from trying to load 64-bit plugins and whatnot.
Henri Beauchamp wrote:
One thing you could try, just in case, is [...] to use the default (english) locale instead of your system locale.
Good point, that may be something to revisit. Just thinking back to the 100% CPU issue on SLplugin craziness makes me agree. :lol:
Henri Beauchamp wrote:
Interesting... But again, non-reproducible here. I just had a look at newer tcmalloc versions, however, and noticed a bug fix in v1.9 that could possibly explain such crashes in v1.8.3 (from tcmalloc Changelog: "BUGFIX: Fix a race with the CentralFreeList lock before main"). I'll use tcmalloc v1.10 (exact same code as the newest v2.0 but without possible function renaming issues) for the next releases and see what happens. You could try and see by yourself by replacing libtcmalloc.so.0 in the viewer installation lib/ sub-directory with the binary available here.
The descripition certainly sounds like something that could fit the category. I'm hardly a guru, but the stack dump looked like tcmalloc getting confused on one of its (linked?) lists, sooo ... yes. Thank you for the binary, I'll give it a go right away.
Henri Beauchamp wrote:
Also, are you using the "Advanced" -> "UI" -> "Use a non-blocking file picker" option or not ?... Does it make a difference when you toggle it ?
I haven't in forever. Shortly after it came out I had serious issues with it (i.e. frequent crashes surrounding the picker process) when I tried it, so I switched back to the old blocking one and left it there since. If you say it might make a difference, I sure could give it another go.

Oh, and ... thank you for your hard work on all this, Henri!

Love,
Lia


2012-09-15 09:32:37
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 32 posts ]  Go to page Previous  1, 2, 3, 4  Next

Who is online

Users browsing this forum: No registered users and 36 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.