Lock up

[mrmikel]

Back at it again, Kovid. Unrecoverable lock up on program. It seems to be related to multiple insertions from clipboard via control-v into paragraph tag ie class="tocsub" or class="widebox".

Is it possible to start it in a debug mode so it will track when it goes boom?
It is completely unresponsive with no error message, then goes white overlay when you click anywhere in it. It can be closed by xing out, you get a dialog asking if you want to close or wait.

I had used paragraph express, but at the time it locked up I was doing a series of inserts of the type mentioned above trying to style the html toc.

I have to add that it takes perhaps half an hour of editing without saving (naturally) to have this show up. (Don't you just love this kind of issue????????)

The book shows no errors, though it does have words outside of paragraphs in the body.

[kovidgoyal]

There's no logging that would help with a hang. Lets wait and see if more people experience this issue, then we can start to investigate if there is somethin common to the occurrences.

[eschwartz]

debug mode can be accesed by running

calibre-debug.exe -t

instead of

ebook-edit.exe

Or if you restart calibre in debug mode via the Preferences, Edit Book (on a book in your library) should inherit that and use the same log.

[mrmikel]

It seems if the document is saved right along then the problem does not occur. It is only when it is run for an extended period of time that the problem occurs. The editor has been so reliable, I have fallen into evil habits of just plowing along without saving.

The editor seems to slow down after long periods without saving. Could this point to a memory problem or garbage collection issue?

[kovidgoyal]

saving should make no difference to anything. saving just creates a duplicate and saves that, the original is left as is.

[mrmikel]

More lockups this morning. FWIW the computer is Win7 6gig, 4 core. Always to do with insertion. Checked the performance CPU was 25% one core and not responding. Rest of computer was plenty of memory, disk space and the CPU usage was all on the one core.

Looks like my guess might be right, memory monitor shows increasing memory usage going up at the rate .01 gig every couple of seconds. Is now up to 4.19 and increasing. It was more or less stable until it went into the lockup.

[kovidgoyal]

Since I cannot replicate it and neither has anyone else reported anything like it, it's likely an interaction with something on your system.

[mrmikel]

I think it is phrase express. I found by checking task manager that it was still active despite being set to be off. I have moved it out of startup and I will see what transpires. Thanks for your efforts and I really appreciate the editor. For me it has displaced Sigil because of a number of its advantages. It doesn't require you to civilize the document before saving it and I work on a lot of junk. It is faster at many things. The clips function is now the only thing missing for me now.

I terminated the phrase express process and so far no lock ups.

[kovidgoyal]

A clips tools is on my TODO list, however, I am currently busy with migrating all of calibre to Qt 5, so until that is done there likely wont be any major new features for the editor.

[kovidgoyal]

Someone elkse did report a lock up, which I have fixed, though I dont think it is related to your symptoms: https://bugs.launchpad.net/bugs/1314009

[mrmikel]

It is always a paragraph tag so maybe this is it. I am avoiding doing inserts into paragraph tags and see if that is it.

Thanks for letting me know.

I am suspecting that is it. With no insertions, no hangs.

[mrmikel]

Went through entire rest of book without paragraph tag inserts, no lockup. That is the culprit.

[DrChiper]

Just my 2cts:

I was splitting a large file into multiple files per chapter. When I had a lot of chapter TAB's (and did no intermediate save) at some point the editor seems to "hang". However, after waiting for a loooooong time, the editor responded again. To "hang" again after a new edit attempt. A quick save action, and closing all unnecessary TAB's restored the normal edit behavior.

[kovidgoyal]

@DrChiper: If this is something you can replicate consistently, then by all means opena bug report and attach the file along with a list of steps to replicate the issue. Although, I suspect the problem is caused by running low on RAM.

[DrChiper]

Unfortunately, I cannot provide you the original file. However, I've seen this in the recent past a couple of times with several relatively large EPUBS (~2MiB), heavily editing sessions and forgetting to regularly save.

Today I had this issue after splitting a file in about 10-15 separate chapter files (from a total of 120 chapters). Thereafter I got a windows message "application not responding" which lasted for about 10 minutes or so.

I'm using a regular up-to-date Windows 7 machine quad-core, 4GiB RAM, ample disk space (separate data drive) and no other application active than a browser (FF).

I will file a bug report with details for good measure to help.

Filed Bug #1314339