Crash on export object/s recent Linux releases
Author |
Message |
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5546
|
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 |
|
|
Zauber Exonar
Joined: 2009-09-08 01:27:46 Posts: 172
|
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.
|
2012-08-14 14:21:28 |
|
|
Zauber Exonar
Joined: 2009-09-08 01:27:46 Posts: 172
|
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 |
|
|
Zauber Exonar
Joined: 2009-09-08 01:27:46 Posts: 172
|
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.
|
2012-09-13 13:26:35 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5546
|
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 |
|
|
Zauber Exonar
Joined: 2009-09-08 01:27:46 Posts: 172
|
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 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5546
|
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... Really ?... The latest mesh versions ?... I doubt that: there's even a JIRA for it (see the messages above). There is indeed nothing wrong here (using Mandriva): I just can't reproduce these crashes ! 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 |
|
|
Amalia Illios
Joined: 2010-04-07 08:23:18 Posts: 210
|
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
|
2012-09-14 10:03:49 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5546
|
| | | | 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: 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. 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 |
|
|
Amalia Illios
Joined: 2010-04-07 08:23:18 Posts: 210
|
Hi again Henri, you wrote: 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. Good point, that may be something to revisit. Just thinking back to the 100% CPU issue on SLplugin craziness makes me agree. 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. 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 |
|
|
Who is online |
Users browsing this forum: No registered users and 101 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
|
|