Bug splat sketchup8 round corner and Vray 1.6
-
@tig said:
Vray beta is known to cause some issues - so it is best left unloaded until you need it, then load it temporarily for just that session...
AFTER SENDING US A BUG REPORT... don't just brush a bug under the rug, tell us about it, that's the entire point of having a public beta!
We don't use other plugins while developing our product, so there's no way we can know about conflicts unless users tell us about them. I am aware of an issue with RT interfering with the undo stack, but we shouldn't be doing anything that should cause a crash... that sounds bad. I do agree that it's a waste of resources to have a rendering plugin installed while you're modeling, but if you do have us enabled, we shouldn't be causing a crash like that. If you can give us any details about the plugin that is conflicting, we can try to contact the developer of that plugin and resolve whatever issue is causing the crash.
-
i have installed the last version of libfredo and there is also bugsplat.
I put the attachment BugSplat.
-
-
I've had this bug for a while along with some other plug-ins such as Instant Roof. I think they are resolved in 2013 but that would mean upgrading which I know some people are against. It's really not fair to have to upgrade SU in order to fix instability issues, but it is what it is.
-
Any updates on this crash? It's annoying.
-
i have make a message to chaos group forum and no news.
Yes it's annoying, because it'i very useful plugin, it became necessary. -
InstantRoof crashes also. For now, the fix is ThomThom's Vray Toys and disable VR.
-
Any news on this crash / bug? I just sent Fredo a message about it.
-
? are you asking me?
-
The other innocent tools are NOT 'crashing' per se.
It does appear that Vray is the likely instigator of these crashes.
An innocent tool does something quite legitimate like add/delete a group and probably a Vray observer kicks is inappropriately and that crashes SketchUp - not the other tool.
It is not a 'clash' of scripts, since the innocent tools are doing only legit API things that it ought to be able to do with confidence...
So Vray is causing the issue and it is crashing: although Vray might not be 'active', its 'observers' certainly will be...
These kinds of crashes are not limited to Vray.
They are usually caused by ill-conceived EntitiesObservers etc that are not robustly coded, or also occasionally by ill-advisedly overwriting native base-class methods [particularly with 'group']... -
I completely agree. We do some operations during an observer event, and from what I understand, that's not safe. When are we supposed to react to what we are notified about via the observer system?... I have no idea... but I've been told that the way we do things is dangerous. I'm sure we probably make some bad assumptions during these events also. I'd love to have someone with more experience, take a look over our observers implementations, and let us know if there are any glaring issues that may be causing some of these crashes/errors to occur. I've tried doing a trace during a crash, but I don't really see anything suspicious. I have also messaged Fredo about the conflict with his plugin, in particular, because he has written a staggering number of plugins, and I believe it's fairly safe to assume that his scripts are not to blame. If anyone is interested in helping us track this down, I am open to suggestions, please send me a PM.
-
Add Joint Push Pull to the list.
-
Does the stack trace give any info on when/where it crashes?
-
You're not speaking my language ThomThom. Way out of my realm of understanding.
-
Sorry, the question was aimed at Devin.
-
call VRayForSketchUp set_vfs_scene_attribute in C:\ProgramData/ASGVIS/VfS/Ruby/R2P.rb:ln 269
c-call Sketchup active_model in C:\ProgramData/ASGVIS/VfS/Ruby/R2P.rb:ln 271
c-call #Sketchup::Model:0x167e78ac attribute_dictionary in C:\ProgramData/ASGVIS/VfS/Ruby/R2P.rb:ln 271
c-call #Sketchup::AttributeDictionary:0x167e73fc []= in C:\ProgramData/ASGVIS/VfS/Ruby/R2P.rb:ln 272
c-call #VRayForSketchUp::VfSModelObserver:0xbbe4668 onTransactionStart in C:\ProgramData/ASGVIS/VfS/Ruby/R2P.rb:ln 272
call #VRayForSketchUp::VfSModelObserver:0xbbe4668 onTransactionCommit in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 1084
call VRayForSketchUp::CallbackWatcher busy? in C:\ProgramData/ASGVIS/VfS/Ruby/skpHelperClasses.rb:ln 41
c-call Sketchup active_model in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 1087
c-call #Sketchup::Model:0x167e78ac materials in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 1087
c-call #Sketchup::Materials:0x167e5444 current in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 1087
c-call == in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 1087
call #VRayForSketchUp::VfSEntitiesObserver:0xbbe45dc onElementModified in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 929
c-call #Sketchup::AttributeDictionary:0x167e73fc class in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 930
c-call Sketchup::FaceSketchup::ComponentInstanceSketchup::Group include? in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 930
c-call Sketchup::Face == in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 930
c-call Sketchup::ComponentInstance == in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 930
c-call Sketchup::Group == in C:\ProgramData/ASGVIS/VfS/Ruby/VfSObservers.rb:ln 930 -
crashes in the observers ::begins to weep and walks off to a corner of the room to collect himself:: My suspicion is that the crash is related to setting the scene attribute dictionary
Advertisement