Jump to content

Possible crash reason


Recommended Posts

Hi, Been having 8-10 crashes a day and with the help of an expert who may have given a reason has suggested the following.

Am trialling this now to see if it helps, so maybe other with same issues may try.

The problem can happens when some or all of the Attributes palette is set to use class style. When this condition is met, every time your mouse runs over the palette, memory leaks in a big chunk, eventually leading to a crash. There are two things you can do in the interim to prevent this:

1. Move the attributes palette so it is not in a position where the mouse runs over it. Where you have it now is NOT a good position in this regard.

2. Click on the little disclosure arrow at the bottom of the palette and choose Remove By Class Settings. This will prevent it from happening at all and while it may not be your desired option, it could be the lesser of two evils. In this case, you would then have to manually set new objects to use class styles, by choosing Make All Attributes By Class with the object selected.

HTH

Link to comment
  • Vectorworks, Inc Employee

On Windows, we're currently tracking a strange one with Class Attributes. With this turned on for a large number of objects (which is normal use), resizing the attributes palette, moving those objects, changing the class attributes, anything that would trigger a refresh of attribute assignments seems to be building up what are known as "GDI Handles" which, if they reach around 10,000, crash Vectorworks.

During normal operation, Vectorworks should just hover around 2800 or so of these handles maximum, but there is an error or leak where these handles are not released and keep building up until a crash occurs. Unfortunately, the workaround of "Disable class attributes on all objects" is pretty much useless, since any fleshed out documents would likely use this extensively.

Restarting the application completely resets this and can often allow you to avoid the crashes entirely if done regularly, but again this is overly annoying as a temporary fix.

For any interested users, this utility from Microsoft:

https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Can be used to monitor these handles and see when they start to reach a critical state (Anything over 7,000 in my tests here) and then restart accordingly. Simply run the app, scroll down on the left hand side until you see Vectorworks 2016 (if its running) then double click on it to bring up the details and then select the Performance tab. Near the bottom right you'll see GDI Handles which will rise constantly in Vectorworks 2016.

Sorry for the pile of technical info, but I mainly want to make sure users that are experiencing the general symptom of "Random Crashing" can diagnose whether this is the issue they're seeing, or if its something else that needs attention and patching.

Link to comment

Jim,

Given this is a bit of a really nasty bug with the attributes palette on Windows I guess there will be an intermediate patch to fix this. Would that be a correct assumption or will it be fixed with a regular SP in the future?

When I get my copy of 2016 I'll run a test with some of the larger drawings with 1(0)000's of objects if it hasn't been fixed by then if that would help.

Link to comment
  • Vectorworks, Inc Employee

When I get my copy of 2016 I'll run a test with some of the larger drawings with 1(0)000's of objects if it hasn't been fixed by then if that would help.

For the test, the more complex the file, the more likely the crash is to occur quickly. So yes that would be ideal.

Given this is a bit of a really nasty bug with the attributes palette on Windows I guess there will be an intermediate patch to fix this. Would that be a correct assumption or will it be fixed with a regular SP in the future?

Jim,

We are currently holding off on the switch from 2015 to 2016 precisely because of this issue. I have been testing it for our office and it crashes far too often to be viable for now. Is there a fix coming?

Yes, there will be a fix and its being pushed as fast as possible. This is considered top priority for obvious reasons. However, they are still looking for other user actions that might be erroneously increasing this handle count just in case, but class attribute assignment seems to be the main culprit.

Link to comment
  • 2 weeks later...
  • 2 weeks later...

Hows this coming Jim??

Still persisting but crashing at least 4-5 times a day.

Maybe I might try taking the file off the server and putting on desktop??

PS still don't know how to quote someone, maybe you could fill me in please.

Thanks

Edited by Alan Woodwell
Link to comment

Hi All,

I have been experiencing the same crash problem. GDI handles reach 10,000 and boom! Crash.

Would be great to have this one fixed.

Thanks.

Laurie

(first post ever, hope I've done this right!)

_______________________________________

VW2016 SP1 Landmark

Windows 7, Intel Core i7-2600 CPU @ 3.4GHz

8Gb Ram, 64 Bit Operating System

Link to comment

Jim,

I've done some testing on the very large files, but was a bit surprised it took quite some time for the files to have the GDI count get close to 10,000 before it would crash.

On a lighter file, when adding lots of text and copying text items/panning/zooming the 10,000 count was reached faster and VW would crash. One time it also crashed around 6,500.

Hardly any other things were done during those sessions besides the adding text on a design layer. Changing classes of items was very limited.

Other than this GDI count issue VW2016 has been quite stable for me and not that much slower if at all than VW2015 with these drawings.

Based on the differences between the heavy and the less heavy drawing it seems to me it is not as much as the number of items being regenerated for class properties in the drawing but more the number of actions/regenerations that makes the GDI count go up quickly.

i.e. updating 300,000 objects for class properties twice is not going to do much, but updating 300 objects for class properties during panning/copying 70 times is more likely to cause issues and increase the GDI count more rapidly.

Edited by Art V
Link to comment

Hi Jim

I have been posting about random crashes and have monitored the GDI handles and this was the reason 10,000 and boom!

Your tech guys have been aware of this for nearly a month now, why has a patch not been released, it means we have to monitor the handles, close the programme when it gets above 7500 reopen, reload and carry on.

Not an acceptable way to run a programme.

Please ask the programmers to give this absolute priority, 2016 may have a lot of new features that I have not even been able to explore yet because the problems caused by crashing have substantially added to our workload.

Link to comment
  • Vectorworks, Inc Employee
Hi Jim

I have been posting about random crashes and have monitored the GDI handles and this was the reason 10,000 and boom!

Your tech guys have been aware of this for nearly a month now, why has a patch not been released, it means we have to monitor the handles, close the programme when it gets above 7500 reopen, reload and carry on.

Not an acceptable way to run a programme.

Please ask the programmers to give this absolute priority, 2016 may have a lot of new features that I have not even been able to explore yet because the problems caused by crashing have substantially added to our workload.

Glad we were able to diagnose it! Once a patch that corrects the issue is complete and ready for deployment, it will be released. There is no reason we would delay something so important, unfortunately just because engineering or tech is aware of a problem does not mean that the fix will be moments away.

Link to comment

Hi Jim,

Vectorworks is a great program. It's clear that patches take time and can't be released the day after the problem occurs. What's annoying is that service select users feel misused as beta-testers, trying to run a programme that is announced as "ready to work", loosing lots of time with crashes and testing. If VW 2016 were released as "test it out, but we will call it a stable version a few months later" everyone had known what to expect and no one would be disappointed.

So as always, its mainly a matter of communication.

Meanwhile I have set the GDI handles to 100,000 or so, which results in a halfway stable version, but the delay when changing layers or classes is still there.

So I'll be patient and wait for SP2.

Link to comment
  • Vectorworks, Inc Employee

Unfortunately sometimes things like this can slip through testing, but this wouldn't have anything to do with Service Select subscribers, anyone who installed even as late as the release of SP1 would see this bug.

However, I AM a proponent of a public beta phase before release in addition to the closed phases we use now, where things like this would be more easily caught. We implement some automated testing systems here (since testing ALL of Vectorworks is an insanely daunting task even for the dozens of QA personnel we employ) but I think more crowd-centric testing would improve things even further.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...