Eagle 8.1.1 bug - program crash if you change DRC while routing

[Anonymous]

Hi, 

I'm using Eagle 8.1.1 on MacOS 10.12.4. and noticed a little error:

1. You start routing a trace in "walkaround obstacles" Mode

2. while routing open the DRC and change the clearance 

3. Set the next point of your trace

4.  the programm will crash with the error message "ABORT: 'Take(Object)'failed!"

This happens reproducible. Its not the moste usual thing to do but the Programm crashes completely.

[jorge_garcia]

Hello Andreas.brandl,

I hope you're doing well. Could you post a screenshot of Help > About EAGLE from your EAGLE control panel? We can't reproduce this issue in 8.1.1 but this issue did exist in a prior version of EAGLE so we really want to confirm that you are using 8.1.1.

If this confirms that you are working with 8.1.1 then please send the specific design file to me. I will direct message you to request the file.

Let me know if there's anything else I can do for you.

Best Regards,

[tomacorp]

I have the same issue. I have confirmed that I am on 8.1.1 and the issue happens frequently when doing a DRC after routing.

I have been clicking 'Save' often, but it doesn't seem to do anything. When I restart after a crash, the brd data is more than an hour old.

The crash recovery files are a good idea, and I got good at crash recovery, but my latest crash recovery files have old data in them, and I have lost a lot of work.

Does the Save button do anything? It seems like the latest fad in CAD is to have live data and no working save function.

This approach assumes the software is never crashes, or that crash recovery isn't much trouble and it always works. This appears to be a false assumption. I have done about 5 crash recoveries now, and 4 of them worked great. If crash recovery is the strategy and it is supposed to be easy, why isn't it automatic?

Please let me know what really happens when I click Save. Why don't I get the data from my Save after a crash? Do I have to keep renaming the file? Would a new file name actually save something to disk? I need to be able to get back to where I was after a save, even if there is a crash. As of now, it loses data. Given the frequency of updates lately, there must be very little user testing, so I think this is especially important.

Please let me know when this particular crash is fixed, or if there is some way to revert my subscription to a version that doesn't have this particular crash.

Then I will start using EAGLE again.

macOS Sierra

version 10.12.4

MacBook Pro (Retina, 15-inch, Mid 2015)

2.5 GHz Intel Core i7

16 GB 1600 MHz DDR3

AMD Radeon R9 M370X 2048 MB

Intel Iris Pro 1536 MB

Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; RELEASE_X86_64 x86_64

[jorge_garcia]

Hi @tomacorp and @Anonymous,

Thanks for participating on our forums! I have been able to reproduce the crash and have passed it along to our developers thanks to andreas.

Now the Save command does simply that it saves the schematic and board together if they are consistent, otherwise it will just save the current editor. Now EAGLE's backup mechanism kicks in after the last save. How long it takes to kick in is determined by the settings in Options > Backups/File-Locking. By default that period is 5 minutes, and it will create as many backups as that max number allowed in those settings by default it's 9.

Now let's work through a couple of examples.

Let's say you save every 3 minutes. Because this period is less than 5 mins the backup system never gets the opportunity to kick in. So if you don't see backups but you save very often this is likely the cause.

Now let's say you save your schematic for the first time. Using the default settings here is what will happen.

In 5 minutes EAGLE will create a file with the extension .s##, as long as you don't save this file will be updated every 5 minutes. As soon as you save this will become .s#1 and the process repeats until you reach .s#9. At this point the behavior changes a little bit, from this point forward the latest backup will be written to .s#1. So if you have been working on a project for a while and you need to go through your backups more than likely .s#1 will be the most recent backup. You can always confirm this by looking at the date modified of the file.

I hope this clarifies how EAGLE's backup system works.

Let me know if there's anything else I can do for you.

Best Regards,

[tomacorp]

Thanks for the information about the how the Save function inhibits the backup feature!

It's a good start but I still don't understand it. I think a diagram would help. Here are my questions:

> In 5 minutes EAGLE will create a file with the extension .s##, as long as you don't save this file will be updated every 5 minutes.

Okay.

> As soon as you save this will become .s#1 and the process repeats until you reach .s#9.

What does 'this' refer to here?

What part of the process repeats?

> At this point the behavior changes a little bit, from this point forward the latest backup will be written to .s#1.

So .s## is not longer used and latest is written to .s#1?

Does the old .s#1 become .s#2, old .s#2 become .s#3, etc?

Does the any backup happen on save, or just on the timer, which is reset by saving?

> So if you have been working on a project for a while and you need to go through your backups more than likely .s#1 will be the most recent backup.

> You can always confirm this by looking at the date modified of the file.

This is where I ran into trouble. It looks like it is the latest, but it has old data in it. Is this because I was saving? Would .s#2 then be the latest? The problem is that it crashes so often that copying these files around becomes automatic, but then something goes wrong and it hard to figure out what happened.

There is a lock file after a crash. Is there any scenario where I would not want to delete this file?

It is ironic that saving often leads to loss of work.

Would it be possible to enhance EAGLE to make this feature less ironic?
For example, perhaps it would be good to have a deeper backup queue, and make a new backup every time the user presses the Save button after making a change.

I think if you document the autosave process with a diagram, and then show the diagram to the developers, they will want to improve how it works!

[jorge_garcia]

Hi @tomacorp,

I'm working on the diagram and making sure that I understood the process correctly so I'm having the devs verify it to make sure I didn't misunderstand anything.

Let me address some of your questions:

"> As soon as you save this will become .s#1 and the process repeats until you reach .s#9."

.sch and .s## get updated and .s## becomes .s#1. Now you go back to the beginning if 5mins elapse then create .s## again and go through the rest of the process.

"> At this point the behavior changes a little bit, from this point forward the latest backup will be written to .s#1."

.s## is still used but now, whenever the user clicks save it overwrites .s#1 only none of the other backups are touched. As indicated above the backup happens on save, .s## is an intermediate files that hold changes until a save operation is initiated.

If you are the only person working with the EAGLE files then I would encourage you to disable file locking since it doesn't present any benefit for you. You can always delete the .lck files without harm if you are the only person touching the EAGLE files. To disable locking go to Control Panel > Options > Backups/File Locking.

At no point in time should use lose more than 5 minutes of work, like I said this represents the backup mechanism as I understand it right now. I'm waiting for clarification from the devs and if I get permission I'll post the diagram.

Best Regards,

[tomacorp]

Thanks! As you said, the key is to carefully look at the file dates, and not rely on "same as last time" when choosing which backup to restore.

For some reason, I am now having the crashing problem much less frequently.

I think what I have changed is that I switch to 'move' mode before running the DRC.

Thanks also for the information about the lock files. It is great that there is a setting for this!