Cool VL Viewer forum

... yet another Octree crash.

Hello Henri,

sorry for the flippant subject selection, just couldn't resist it. Should I even bother reporting these anymore? Most of the time these seem spurious, so I couldn't even begin to try reproducing them in any viewer. No less, I have included the relevant information.

Oh, and on a much more important note: I hope you have a wonderful holiday season, just the way you want it to be.

Love,
Lia

*sighs* The octree code is so unreliable and dirty !!!...

The crash happens in the destructor of an octree node, but there's already safety checks there that I implemented after you reported a similar crash. There is no room left (even the most improbable condition) for any NULL pointer issue in that code (and none of the warnings I added got issued either that would be indicating such a NULL pointer condition), so the only logical explanation is that the viewer called the destructor of an already destroyed octree node !

I'm afraid I can't investigate this bug; if only I could reproduce it myself !... But I so far never stumbled upon it. Unless you can manage to find a common point for each such crash you get (i.e. were you doing something special, such as editing a specific prim with specific characteristics ?), I'm afraid we'll have to wait till LL finds a fix (they must be getting many crash reports with such occurrences and must therefore gather more meaningful data as to what its origin could be).

Uhm... I don't know the code, so I don't know how many places there are that call the destructor... also my knowledge of C++ is limited... but have you thought about setting the pointer to NULL after calling the destructor? Then your code that checks for NULL should be able to catch this.

This is not as simple as this. Pointers *are* set to NULL and checked for, but the problem is that once an object is destroyed, the memory it used (and the pointer variables it contained) is also reused by other objects, which may lead to "un-nullify" a previously "dereferenced" pointer... also, the problem with C++ templates, virtual classes and inheritance (not to mention implicit destructors and allocators code that is automatically added to the code at compile time, even though they don't appear clearly in the sources), is that there are many ways a destroyed object could still get wrongly referenced in a parent class...

I may add some octree tracking code (i.e. maintaining a list of currently allocated octrees and checking against it before attempting to delete an octree), but this would also lead to slower code...

Ah, I hadn't thought about that the memory-location of the pointer itself could be freed-up and reallocated. My bad.

Hello again Henri,

You wrote:Yes, I thought as much -- hence my question about reporting them. As I said, I have no reliable reproduction case, and the Octree crashes are few and far between (This one, if I remember correctly, was right after TP when rendering had just started, but they have happened in completely different situations as well. So I'll skip reporting them here unless I find a 100% repro.

Oh, speaking of spurious stuff, but completely unrelated: I have been witnessing occasional (I think 3 or 4 times so far) viewer freezes -- or so it seemed. When looking at the console output in my .xsession-errors, after the last viewer console log message, I see:(Address varies, obviously)

The viewer binary keeps "running", though. Any ideas on how to swat that one? If I attach gdb to the running viewer then, does it make sense to get a backtrace or something? Since I have to manually terminate it in that case, I might as well attempt something useful.

So far it has happened at least twice after attempting a texture upload (post viewer-confirmation/preview floater) and once after quit (last log message was a saveToFile: LLInventoryModel::saveToFile() entry).

Love,
Lia

It looks like a memory corruption issue... I never encountered such an issue myself (just like your octree problems, that could as well be due to memory corruption). Which would lead me to wonder if the problem is not rather with your system (such as a buggy GTK module ?... See elsewhere in this forum about crashes in file picker with a given GTK module installed).

A proper backtrace is always useful and welcome...

It definitely looks like that buggy GTK module issue...

One small comment:

In theory, overclocking your CPU can lead to strange, inexplainable crashes. So please mention it if your CPU runs outside of its usual frequency range.

(see for example http://blogs.msdn.com/b/oldnewthing/arc ... 07562.aspx about some story about what can happen).

But its probably memory corruption in this case.

Kathrine