Jump to content

serious stability problems, crashes and corrupt savings


Recommended Posts

hello,

serious stability problems: vw 12 is crashing down about ten times a day.

It happens whether when we are moving walls, when we are changing wallstyles or establishing workgroup referencing.

I guess it?s crashing down just before autosaving because we always lose maximum amount of work. that bugs.

We don?t dare to use vectorworks workgroup referencing anymore because it is causing crashdown 4 out of 5 times.

File sizes are below 20 MB. We are working on dual G5 Powermacs and new G4 Powerbooks, so that shouldn?t be the problem

Another issue:

We used to work directly on the files on our office network. But once in a while Vectorworks is saving the file as a corrupt zero KB file.

trying to open the file it is saying "This is an unrecognised file. It may be a VectorWorks file created by a newer version of the application, it may be a very old miniCAD file, it may have been created by another application, or it may have been corrupted by a hardware or system error."

the same as "Laurence_R" experienced:

http://techboard.nemetschek.net/ubb/ultimatebb.php?ubb=get_topic;f=12;t=005873

we lost a lot of work and we contacted the local vectorworks trader. He advised us to work on copyfiles on our computers and then save them on the network because the risk of losing the file is to high. That is possible but it is a bug for the workflow. is it so that vectorworks 12 is not suitable for working on files directly on the local network because the risk of file corruption is too high????

do you have any solutions?

Link to comment

What OS are you running?

How long is a filename, including the network name and all of it's folders (in character count, including spaces)

[ 03-09-2006, 11:34 AM: Message edited by: Katie ]

Link to comment
  • Vectorworks, Inc Employee

Hi Marek,

We're tracking this problem on several fronts and trying to find some common threads. Did these problems start happening when you upgraded your server to MacOS 10.4.4 or 10.4.5?

We think it might be the case that, when you get the "unrecognized file" message, the file is not really corrupt at that point, and it only becomes corrupt when you shutdown VectorWorks. When you get the message, if you copy the file in the Finder before you shutdown, or if you Force Quit VectorWorks, the file might be ok. Please let me know if you get a chance to try this out.

As you may have noticed from Laurence_R's thread, this problem has suddenly started happening to some of our users using VectorWorks 11.5 also. Any information about what might have changed on either your system or your server right before these problems started happening would be greatly appreciated.

Best regards,

Mark Farnan

Core Technologies Manager

Nemetschek NA

[ 03-09-2006, 02:23 PM: Message edited by: Mark Farnan ]

Link to comment

hi mark,

sorry, the macOS 10.4.4 is the version of my laptop. I am not sure if the server is a mac or a pc. I will find out tomorrow.

But what about the crash down rate? I have a collegue beside me whos vectorworks is crashing down everytime he is moving or streching certain walls in his drawings. it?s eating our time(=money).

workgroup referencing is possible with symbols, but when we reference mod-floor layers it is crashing most of the times.

best regards marek

Link to comment

Mark,

I would like to try that trick with copying in finder and force quitting vw after the "unrecognized file" message, but we are not working directly on the network anymore.

this is a new office, we established vectorworks for four months ago. so we don?t have made any changes to our systems nor the network before the problems appeared. So I cannot help you with usable informations from that.

best regards Marek

Link to comment

I send my collegues file and console text to mark.

the console text is saying:

Mac OS X Version 10.4.5 (Build 8H14)

2006-03-10 09:28:04 +0100

2006-03-10 09:28:05.719 SystemUIServer[78] lang is:en

Mar 10 09:28:07 kristoffer-theisens-power-mac-g5 mDNSResponder: Adding browse domain local.

kextload: /System/Library/Extensions/smbfs.kext loaded successfully

VectorWorks(213,0xa000ed68) malloc: *** Deallocation of a pointer not malloced: 0xffffffff; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug

VectorWorks(213,0xa000ed68) malloc: *** Deallocation of a pointer not malloced: 0xffffffff; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug

VectorWorks(213,0xa000ed68) malloc: *** Deallocation of a pointer not malloced: 0xffffffff; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug

VectorWorks(730,0xa000ed68) malloc: *** Deallocation of a pointer not malloced: 0xffffffff; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug

Mar 10 17:11:12 kristoffer-theisens-power-mac-g5 crashdump[747]: VectorWorks crashed

Mar 10 17:11:14 kristoffer-theisens-power-mac-g5 crashdump[747]: crash report written to: /Users/kristoffer/Library/Logs/CrashReporter/VectorWorks.crash.log

best regards marek

Link to comment

We're having the same problem with autosaves. It seems that it only happens frequently with a few users, though we can't seem to establish a pattern.

We're on OS X 10.4.5 currently (server as well as clients). The problem seems to have drastically worsened since the 10.4.5 roll-out two weeks ago, though that's second-hand information from a user and we can't verify an exact time or frequency of crashes. We're running VW 12.0.0 but are this evening rolling out 12.0.1 to see if the problem goes away.

Another user described the situation as crashing when attempting to minimize a drawing just after an autosave. Something he said (though I can't remember exactly what) suggested that performing nearly *any* action can crash it after an autosave (when the problem occurs).

Our work-around for now is to disable autosave in the affected users' preferences. So far it seems to be working.

[ 03-10-2006, 04:38 PM: Message edited by: JLN ]

Link to comment

For those having problems, what is your current open space on your share_point? We have had this(or a remarkably similar) issue on and off since version 9. I believe we found and solved this issue. We are currently a mix of 10.4.4 and 10.4.5 with 10.4.5 Server. and a mix of VW 11.5.1 and VW 12.01, and as I point out below we haven't seen the problem for nearly 15 months.

I sent following information via email a while back to NNA.

I found that without fail if the sharepoint's drive being saved to got beyond 85-90% full we would experience widespread file corruption. The corruption would occur, even though our staff was very careful to never close or save a file until the print was completely transfered to the printer. Also to never close a file and use the standard Save warning to save the file, rather to save the document first and then close the file.

We found that 99.5% the corrupted file was the main working document, and that the backup copy saved a few operations before was fine. There were a couple of times where both the main file and the backup were corrupted, but I never could answer to my satisfaction if staff had opened the backup without making a copy, so I have no concrete cause and effect for those rare situations.

This occurred three times, in a little over two years. During that time, we had two 60Gb drives, one was our startup drive, and user accounts, and the other our data drive. In all three occurrences I hadn't monitored data drive space closely enough. The first realization I got that something was wrong, was a day where 10-15 files were corrupted. Once I cleared enough space of the data drive the new corruption of files would cease, though it was usually a three week process of finding all the files corrupted while the drive was too full. After the third occurrence, I increased our storage dramatically, and we haven't seen the same widespread corruption since, about 15 months now.

The particulars:

xserve Dual G4 1.0 Ghz/ 1.5 Gb RAM (depending on the time(120 - 420 Gb HD space, Mac OS X Server 10.2.x - 10.3.9)

100bT ethernet network

16 workstations all Macs, a mix of G3, G4 & G5s, running the current version of Mac OSX, usually adopted office-wide around the 10.x.2 or 10.x.3 release

Only in office access was allowed, no remote access of files.

I don't know if this is releated to your issues or not, but it is worth looking into.

Link to comment

To disagree slightly with Christaan?and say what I think was meant?if the drive is smaller than 70 Gb (yes I realize technically Gb numbers are powers of two, not 10, this is just simpler for conversation) you shouldn't be having problems related to this issue, but 70Gb & larger, you are in the danger zone. How far into the danger zone depends on how large the drive is. It isn't how much space, but rather the percentage free. So for me on our original drives which were 60 Gbs, I started to see widespread corruption as the open space passed under the 6Gb mark.

Also this has nothing to do with file size, a large percentage of our files are less than 2Mb.

So take a look at how much overall capacity you have on the drive and compare it to your free space. If you have other questions, I am happy to follow up.

Link to comment

We've also had this problem of VW12 crashing when moving walls, changing wall type, etc., and I asked about it in a different thread. This thread reminded me that I had autosave on at the time, but we don't work off a server, so maybe the issue is unrelated to that? I thought at first it was a memory issue, since I was using a ton of PIOs and my file size was topping 23MB for a house. I caught to the fact that VW always seemed to crash if I was moving a wall right as the program was trying to autosave. The crashes stopped when I checked "Confirm Before Save". HTH

Link to comment

Just in case this is a Mac issue and not VectorWorks:

Have you tried turning everything off and restarting?

Is/are the computer(s) left on at night?

If not, do you run MacJanitor or similar?

Do you regularly repair permissions?

Do you run DiskWarrior or similar regularly?

It is surprising what a bit of weekly maintenance can do, even with Macs.

Link to comment

quote:

Originally posted by ionw:

I found that without fail if the sharepoint's drive being saved to got beyond 85-90% full we would experience widespread file corruption.

quote:

Originally posted by ionw:

It isn't how much space, but rather the percentage free. So for me on our original drives which were 60 Gbs, I started to see widespread corruption as the open space passed under the 6Gb mark.

Hence if marek has 7GB of free space he should be alright if his drive is 83GB or larger, as this would mean it is below 85% full. Am I missing something?

Link to comment

David, in short yes to all. No matter the maintenance, once the drive filled, we would experience wide-spread file corruption. The last 15 months without issue is testament to that.

Christiaan, if my theory is correct, the bigger the drive the more free space one needs:

40 Gb drive needs 4Gb or more free

60 Gb needs 6 Gb or more

80 Gb needs 8 Gb or more

100 Gb needs 10 Gb or more

So if he has 7Gb free he needs a 70 Gb drive or smaller. The bigger the drive, the more open space required.

I also wouldn't get to hung up on the proper Gb percentage amounts. There really is no practical reason if I am correct. Our 60 Gb drive started failing when I passed the 6 Gb full mark. Consistently. That is why I used a range for the percentages.

Maybe on our current 180 Gb drive there will be a larger window when talking percentages, but if I make sure we have at least 18 or more Gb free I will have a margin of safety due to the way drives are marketed and conversion of capacities measured in powers of two being discussed in terms of decimal fractions.

I know that this works for me, I present it here in hopes it helps someone else.

ion

Link to comment

Marek,

It really depends how it is allocated. The important part is not overall space for the whole server, if you mount the network drive for docuuments and do a Get Info (Apple-I) on that disk, that should give you a capacity, amount used, and an amount available. just make sure that the amount used is less that 90% of the capacity.

(Capacity)(0.9) > (amount used)

Is your drive partitioned? or are there multiple drives? If not it sounds like you have plenty of open space, and don't need to worry about what plagued us.

Link to comment

If Marek is saving to a 15 gig partition with 7 gig free he's less than 50% full and should be fine.

I'm curious if it doesn't have something to do with AutoSave as it did with Heather. 20 MB files saving over a network will take *some* time. How does our program behave if you try to make a change with a save in progress? It shouldn't be possibe. Or what happens if you're in the middle of a change and it tries to AutoSave? That shouldn't happen either.

I'd try turning this feature of as a test. If it helps then check the preference to "confirm before save' to ensure that it's saving only when you want it to, and then thank Heather.

Link to comment

ion and christiaan,

i get confused of all the percentages.

the part of our server with documents to be backed up every day is about 15 GB. And in there is 7 GB available.

the server in all is about 180 GB with 118 available.

As far as I understand the free space theory, the explanation could be that the 7 GB free in our documents part may be to little to work with on our server(180GB)..? But then, there is lots of GB available other places on the server. I don?t think it?s the full explanation here.

But thanks, I will keep the free space demands in mind.

regards marek

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...