Scrivener: Slowly consumes RAM[BUG LOGGED]

I had Scrivener lock up on me earlier today.

I killed Scrivener, started it up.

It gives the “Beta” notice, then it looks like it has closed.

Trying to open it again results in not even the Beta notice dialog, so I checked the Task Manager.

Scrivener is running, slowly consuming RAM. While it does this it seems to be spinning a core. This is a quad-core, and it shows Scrivener using 25% of the CPU. It’s allocating ~200k or so a second. Waiting it out doesn’t seem to help, it’s up to 180M allocated and growing.

I wondered if it was Scrivener itself or just my project. It loads the tutorial just fine. Switching to my project after the tutorial also produces the same results except it leaves the (Not Responding) Scrivener Tutorial window open.

I’ve actually backed up my project recently and have only been updating meta-data (Well, it was 6+ hours of metadata updates, as I’ve written myself some extra time for late-stage planning.) I should be able to do some testing to narrow down exactly what is causing the problem. I’m happy to provide a sample project, but I’d like to get a sample project that (1) just had what was needed to produce the error, and (2) didn’t leak out my story.

Well, since I’d been mostly touching the meta-data, I would have thought that just the project.scriv file was the source of the problem.

So I got my most current backup, extracted it to another location – loaded it up once to verify I was working from a usable backup – then renamed the functioning project.scivx and copied over the new one.

It loaded that one just fine even with my updated meta-data, as I could see my new tags.

I’ll keep looking for the source of the issue.

I’ve confirmed that it is one of the RTF files that is causing it to get in this state.

This means Scrivener (at least the 1.2 version) could write RTF files it could not parse.

I have since updated to the 1.3 beta (to see if it would fix the issue) but it did not.

A further clue, I ran through the RTF files that had been saved yesterday and opened them all with WordPad.

There were no complaints when they were loaded.

I saved them and tried the project again – and it worked.

This means that an RTF file that WordPad doesn’t feel worth complaining about is causing Scrivener to lock up.

I’ll see if I can narrow it down further.

The problem RTF file has been found.

Better than that, it didn’t have anything of note from the novel, so I didn’t need to try to pull stuff out of it first.

Again, WordPad loads the problem file broke_127_notes.rtf and when saved it produces the work_127_notes.rtf file. I’m including both, just incase WordPad in a different version of Windows produces different results.

Since Scrivener created this problem RTF file, it would be great if it could be fixed. This could be a real blocker. (581 Bytes)

Thanks Yam655, this is very helpful indeed.