Current code crashes a lot on llDialog and similar popups

Issue #75 new
Lance Corrimal created an issue

I've built a linux binary from the latest repo sources, and the resulting viewer crashes a lot on lldialog and similar popups, inventory offers, etc etc.

Comments (8)

  1. Marine Kelley repo owner

    Interesting, I get a lot of crashes with this code as well, specifically a "pure virtual function call" (source unknown, of course, and it happens completely randomly) and other crashes when processing avatar properties (groups and profiles, but I don't remember the class right now). I could never strengthen that code, which is not my work but LL's. I'm at a complete loss as to how to fix those crashes. Any input would be greatly appreciated !

  2. Lance Corrimal reporter

    I vaguely remember that some people discussin similar issues on the developer mailing list.

  3. Lance Corrimal reporter

    I've built a linux binary from the latest repo sources, still crashes to desktop w/o warnings.

  4. Marine Kelley repo owner

    On my viewer the crash always occurs in LLAvatarPropertiesProcessor::notifyObservers(), when the program calls oi->second->processProperties(data,type);

    When debugging (in Release configuration since compiling in Debug does not work for me, due to third-party libraries such as hacd being compiled in Release and I don't have the time to rebuild everything myself), it shows that the list of observers is populated with LLAvatarObserver objects or something like that (I'm not totally sure about the exact name of the class). Well, duh. But the interesting part is that there is always at least one of them that is merely a pointer, an address that the compiler believes is an LLAvatarObserver, but is really nothing special. I believe it crashes when trying to call the processProperties() method on that kind of void pointer. I also believe that those void pointers exist because somewhere, something deletes them and forgets to set them to NULL. I do not know where, nor why, but I do know this is recent. It didn't happen before the merge with CHUI.

    The only reason I could think of that it would be a bug of mine, is that either I have failed to merge perfectly (which is possible but I have double-checked everything), or I have broken something while working on re-instating the "shownames" restriction. What makes me think of that is that when "shownames" is active, I do not allow the viewer to populate its "nearby" list in the new Communication window. However the viewer crashes whether "shownames" is active or not.

    This crash occurs specifically when something changes about avatars around you. It won't crash while you're alone, and usually it crashes when someone derezzes (logs off or TPs out) while they were on your radar.

    This is where I'm at right now, but I am so demotivated by this new CHUI thing (it breaks my habits once again) and it crashes so much, that I preferred to go back to the older version for now. Feel free to look into it if you have time, I will get back to it when I have time as well.

  5. Lance Corrimal reporter

    I'm not looking forward to CHUI either, but I heard rumors that SSB will go live about four weeks after they release a viewer with SSB... so then any viewer without server side baking will be dead.

    and just a few days ago the ssb stuff got merged into viewer-release :-(

  6. Marine Kelley repo owner

    Yes... I have merged that part and did not notice any difference yet. Even AvatarZOffset still works.

  7. Marine Kelley repo owner

    The latest push I made today (4/30) should improve things and make the viewer crash much less. I'm still testing but this is looking good.

    The crash occurred because of a piece of code in the avatar radar handler that would update the avatar age in days. Every second (figure that). Eventually after an avatar leaves the radar (for example if you shorten the radar range) and then comes back again, the viewer would stumble upon incorrectly destroyed observers, and crash.

    Do not ask me why, but there seems to be a loose causation here.

    I have noticed that some crashes were due to group updates from avatars nearby, and I have not touched that part of the code at all, so it is likely to still be vulnerable to crashing. Just much less than before.

    Feel free to test !

  8. Log in to comment