Back to Rhino aggain!!
-
Have you submitted these BugSplats? Did you enter any description we can use to look it up?
-
@rich o brien said:
Are you running non-compliant plugins? Or is it a vanilla install that crashes.
You really should submit the splats if it is repeatable actions that are causing it.
Or post the sequence here so we cn see if it is reproducible.
I'd imagine there's some people here who are beta-testers?
Not vanilla - about 30 plugins installed mainly via SketchUcanion Plugin Store and meant to be 2014 compliant. Send 3 Bugslats today. Now I'm trying to reduce the number of the plugins, enabling the most used and temporary loading what is needed.
-
Did you enter an email or description? Windows or OSX?
-
@tt_su said:
Did you enter an email or description? Windows or OSX?
Yes, but didn't fill out any info. Here is my Event Logs - Win 7 64 bit SP1 Ultimate:
@unknownuser said:
Faulting application name: SketchUp.exe, version: 14.0.4900.0, time stamp: 0x5304d0bb
Faulting module name: BugSplat.dll, version: 3.3.0.4, time stamp: 0x51a0da9e
Exception code: 0xc0000005
Fault offset: 0x000055d5
Faulting process id: 0xfe8
Faulting application start time: 0x01cf4745f26e93e0
Faulting application path: C:\PROGRA~2\SketchUp\SKETCH~1\SketchUp.exe
Faulting module path: C:\PROGRA~2\SketchUp\SKETCH~1\BugSplat.dll
Report Id: 11ca2d47-b381-11e3-ae47-002618e4be10@unknownuser said:
The description for Event ID 1 from source BugSplat cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
su14win
SketchUp
10592The specified resource type cannot be found in the image file
@unknownuser said:
Faulting application name: SketchUpConverter.exe, version: 0.0.0.0, time stamp: 0x5324a2d9
Faulting module name: MSVCR80.dll, version: 8.0.50727.6195, time stamp: 0x4dcddbf3
Exception code: 0x40000015
Fault offset: 0x000046b4
Faulting process id: 0x7cc
Faulting application start time: 0x01cf48d97161830d
Faulting application path: C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\SketchUp\SketchUpConverter.exe
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\MSVCR80.dll
Report Id: b07aaa3e-b4cc-11e3-a354-002618e4be10@unknownuser said:
Faulting application name: SketchUp.exe, version: 14.0.4900.0, time stamp: 0x5304d0bb
Faulting module name: BugSplat.dll, version: 3.3.0.4, time stamp: 0x51a0da9e
Exception code: 0xc0000005
Fault offset: 0x000055d5
Faulting process id: 0x96c
Faulting application start time: 0x01cf4662d2c61afc
Faulting application path: C:\PROGRA~2\SketchUp\SKETCH~1\SketchUp.exe
Faulting module path: C:\PROGRA~2\SketchUp\SKETCH~1\BugSplat.dll
Report Id: b71a8ae9-b26b-11e3-8476-002618e4be10And more...
-
Can you reproduce the crash reliably? If so, can you do so and submit with some info we can look up. I cannot correlate the Event Log data.
-
@tt_su said:
Can you reproduce the crash reliably? If so, can you do so and submit with some info we can look up. I cannot correlate the Event Log data.
Ok - I'll try.
-
@tt_su said:
Can you reproduce the crash reliably? If so, can you do so and submit with some info we can look up. I cannot correlate the Event Log data.
I was able to correlate the crash from the provided data. If we're talking about the same one, it came from an IP address in Bulgaria on 2014-03-25 at 11:38:06. The name of the Windows login account is "cadmaster". The BugSplat ID of the report is 10592. The rest of the message is in reference to this specific BugSplat.
That BugSplat shows that SketchUp crashed while executing a Ruby script. It is possible that there's a bug in the Ruby API that allowed a well behaved script to fail. More likely though, the Ruby script that was executing did something wrong and killed SketchUp as a result.
Normally it is very difficult for us to figure out which plugin is misbehaving when it dies. I was able to see that a plugin called "jf_trim_and_keep.rb" was executed before the crash, but I think it completed successfully. I don't think there's a clear indication of the problem-causing plugin in the undo log.
As I said, it's normally very difficult to figure out which plugin crashed from BugSplat data. However, in this case, two big clues stand out which point to the likely cause. First, the list of currently loaded libraries contains Thea4SU_core.so. Second, the call stack shows that there is an active thread on the CPU working inside the Thea4SU_core library at the time of the crash.
I'm guessing Thea wasn't necessarily being actively used or that fact would have been mentioned. Regardless, it actually might not matter. I believe ThomThom has documented elsewhere that Thea is known to cause problems when it's run in the background but isn't being used. If my recollection of that is correct, it would seem that the workaround to this specific crash is to disable Thea when you're not rendering, then save everything and quit before re-enabling Thea when you want to render.
Also for the record, one of the previous messages in this thread which contained excerpts of event logs showed one of the crashes not to be in SketchUp.exe, but something called SketchUpConverter.exe, located in a folder called "Rhinoceros 5 (64-bit)". I wrote the SketchUp installer and I know I didn't ship a file by that name or anything installed to a folder named after a wild animal, so that one isn't our fault.
I hope this helps.
Andrew
-
@andrews said:
I was able to correlate the crash from the provided data. If we're talking about the same one, it came from an IP address in Bulgaria on 2014-03-25 at 11:38:06. The name of the Windows login account is "cadmaster". The BugSplat ID of the report is 10592. The rest of the message is in reference to this specific BugSplat.
That BugSplat shows that SketchUp crashed while executing a Ruby script. It is possible that there's a bug in the Ruby API that allowed a well behaved script to fail. More likely though, the Ruby script that was executing did something wrong and killed SketchUp as a result.
Looking at the crash data the crash happen when a plugin tries to get the name of a style. I'm not able to figure out which. I can't see the plugin doing anything wrong here, the crash appear to be our fault. But if we can figure out which plugin it is we could assist in a workaround until we can fix the crash on our end.
However, I'm not sure how to reproduce.@andrews said:
Normally it is very difficult for us to figure out which plugin is misbehaving when it dies. I was able to see that a plugin called "jf_trim_and_keep.rb" was executed before the crash, but I think it completed successfully. I don't think there's a clear indication of the problem-causing plugin in the undo log.
Yea, I'm also not sure which plugin triggers this. I'd start looking at any plugins you can think of that deals with the model styles in any way.
@andrews said:
As I said, it's normally very difficult to figure out which plugin crashed from BugSplat data. However, in this case, two big clues stand out which point to the likely cause. First, the list of currently loaded libraries contains Thea4SU_core.so. Second, the call stack shows that there is an active thread on the CPU working inside the Thea4SU_core library at the time of the crash.
I'm guessing Thea wasn't necessarily being actively used or that fact would have been mentioned. Regardless, it actually might not matter. I believe ThomThom has documented elsewhere that Thea is known to cause problems when it's run in the background but isn't being used. If my recollection of that is correct, it would seem that the workaround to this specific crash is to disable Thea when you're not rendering, then save everything and quit before re-enabling Thea when you want to render.
[/quote]
Render engines in general has historically been prone to destabilizing things, mostly due to their heavy reliance of observers. Again, the real cause is in our code, observers a volatile items in the current API and we need to improve them. -
Yes, it was our office computer. Sorry, but we removed SketchUp - so, I can't collaborate further. Sure, SketchUp is pretty stable as a vanilla and almost useless for us without a bunch of plugins! It was my first 3d program and I can't stop going back to it
-
Don't recall if Thea for SU had actually crashed SU for me (but I am using a old SU8), still there been reports (at Thea forums) that v-ray for SU and Thea for SU together may result a crash (SU 2013 & OS X). If just Thea for SU where used, everything where fine. Tomasz probably do know better, if there further details on this.
-
@notareal said:
Don't recall if Thea for SU had actually crashed SU for me (but I am using a old SU8), still there been reports (at Thea forums) that v-ray for SU and Thea for SU together may result a crash (SU 2013 & OS X). If just Thea for SU where used, everything where fine. Tomasz probably do know better, if there further details on this.
Multiple render engines together has historically been known to increase chance of crashes - usually due to competing observers working at the same time affecting the model.
-
Dear All,
I've been using Sketchup for 7 years and have some tips to share about crashed:
1)Actually Modelling program like CAD, MAX, Rhino and Sketchup always have a limitation of precision. You will never be able to draw an ant standing on earth and flying around the sun. It's computing limitation.
So, sometime my sketchup crashed when I tried to import(paste) a model with very small details (1/10 millimeter) into an large scale urban masterplan (20 kilometer).
2)And you should clean your sketchup file to be sure that there is no Vray materials. That things make me crashed sometime too.
3)Have you recently install some extra plugins for sketchup? Some of them will make you crashed when you apply materials to object or move etc...
-
@dave r said:
Funny. I can work in SketchUp daily for months and never have a bug splat. They are extremely rare in my experience.
With you, Dave. very rare to get a bugsplat only when I'm playing around with a beta plugin really....
-
@nghminh81 said:
1)Actually Modelling program like CAD, MAX, Rhino and Sketchup always have a limitation of precision. You will never be able to draw an ant standing on earth and flying around the sun. It's computing limitation.
ha.. i just tried that for fun..
drew a sphere 865,000 miles diameter.. then one 93000000 miles away with a diameter of 8000 miles.
(the earth is tiny compared to the sun-- i mean, i knew that already but drawing it really makes it sink in).
things still worked ok at this point.then drew a line 5mm long (ant) on the surface of the smaller sphere.. it worked, and i could select it and rotate around it but i couldn't see it or zoom to it in perspective viewport.. i could work on it fine in the other views though.
regardless, highly impractical for any needs i've come across yet.. might come in handy though when google earth moves to google galaxy and beyondrhino does have some crazy units to choose from though.. i tried it with miles since it was maybe an in-between of sun & ant size..
-
Angstroms and lightyears, impressive!
-
Thank Jeff for your quick test and correct my point, I've also drawn an ant and our galaxy without any bug.
I had this scaling problem long time ago when I tried to import from Rhino to sketchup 8. It was a complicated part of a washing machine. That bug might happened to only me.
-
@tt_su said:
@notareal said:
Don't recall if Thea for SU had actually crashed SU for me (but I am using a old SU8), still there been reports (at Thea forums) that v-ray for SU and Thea for SU together may result a crash (SU 2013 & OS X). If just Thea for SU where used, everything where fine. Tomasz probably do know better, if there further details on this.
Multiple render engines together has historically been known to increase chance of crashes - usually due to competing observers working at the same time affecting the model.
Sounds feasible. Maybe some more robust method than observers is needed (if not already exist).
Advertisement