Hi,

Yesterday I deleted the newest layer from one of my QR archives, and then tried to compact it afterward. QR crashed, however, as soon as the command started. Verification gave no error after re-openning the archive, and subsequent captures went smoothly. But I can no longer compact the archive; QR crashes each time.

I compact my archives from time to time, and have never run into this before. I can still do it on other archives, just not this one. I tried it one more time just now, with a new log file, which is attached here for your reference.

Ming-Li,

I looked at the log file you sent, and I can't see a crash. Please send a diagnostic report (in the QRecall app, choose Help > Send Report). This will automatically include any crash logs recorded by the system for QRecall and its related processes.

The capture action itself ran just fine, according to the log file you posted. The compact action started at 13:28:28 and finished successfully at 13:29:12.

It's possible that the QRecall application crashed during this time. But the QRecall app is just a browser; the actions that change your archive is always run in a separate process, which is why your archive verified successfully and you encountered no problems with subsequent captures. In fact, the QRecall application never modifies archives directly, so a crash or forced quit of this app can never corrupt your archive.

So the good news is your data is safe.

I'll look into the crash further, once I receive the diagnostic report.

Done.

Could you please tell me (or is it documented somewhere) exactly what is sent with the "Help - Send Report" function. The QRecall*.plist files in ~/Library/Application Support/CrashReporter, and the QRecall*.diag files in /Library/Logs/DiagnosticReports, I gather. Anything else?

Thanks.

The Send Report function sends the following:

An anonymized system profile (model of computer, OS version, amount of memory installed, and so on), but no identifiable information (no serial numbers, MAC addresses, and so on).

The last 20MB of QRecall log entries.

Your ~/Library/Preferences/com.qrecall.* files, which have your current QRecall preferences and settings.

Your ~/Library/Preferences/QRecall/Actions/* files, which define what QRecall actions you've created.

All CrashReporter and DiagnosticReports files that begin with QRecall*, which should capture the core dumps of any crashed QRecall-related processes

This information is compressed and uploaded, along with your comments, to the QRecall diagnostic report server.

You're welcome to examine the script that prepares this information. It's located in the QRecall.app/Contents/Resources/buildreport.sh script file.

Thanks for sending the diagnostic report.

The QRecall app is definitely crashing, and pretty consistently, although it's difficult to tell why. It's happening after the compact action has finished and the QRecall app is trying to reopen the updated archive in the document window.

So the crash has nothing to do with the action the took place (the compact). It's just something to do with redrawing the window.

My big question is this: After it crashes, are there any problems opening the archive again?

No, I've opened the archive many times afterward, and scheduled daily captures have been going just fine since. Verifications (scheduled and manual alike) have never reported any error. And yet every time I try to compact that archive, QRecall crashes. Compacting other archives is never an issue, and I compacted this particular archive successfully before.

Because the first crash happened when I tried to compact the archive after deleting the newest layer, I decided to try it again, this time on a clone of the archive. Here's what I found:

Action -- result
1. delete the newest layer -- QRecall crashed
2. reopen the archive -- no problem, and I can see the layer is indeed gone
3. verify -- no problem
4. manual recapture of the whole volume -- no problem
5. deleted the newest layer again (the one created by manual recapture) -- no problem
6. verify again -- no problem
7. compact -- NO PROBLEM!


To see if this is a fluke, I deleted the clone, made a new clone from the original archive and tried the following on the original:

Action -- result
1. verify -- ok
2. compact -- QRecall crashed
3. reopen QRecall -- no problem, but there's no entry of the last action (compact) in the log (the one accessible from the "Window" menu)
4. reopen the archive -- no problem
5. delete the newest layer (scheduled capture earlier this morning) -- NO PROBLEM
6. compact again -- NO PROBLEM

The compacting recovered almost 600MB of space after 3+ min., while the layer deleted just now took only 19 MB of space and there's no other layer merged or removed before today. If the compacting that caused the first crash (the one on 2/2) succeeded as you said, it probably didn't "finish" the job, for

1. the successful compacting just now should not be able to recover this much space if the earlier one did its job, and
2. QRecall crashed less than 2 seconds into the action then, but the successful one just now lasted 3+ minutes.

Anyway, the problem seems to have gone away. I'll keep an eye on this archive and report back if I run into any other issue.

The mystery deepens...

Please send another diagnostic report (or just your QRecall.log file). That should include the logs for the experiments you just performed.

If you ever have a question about whether an action was successful or not, the definitive answer is in the log. Open the log window and the find the action. If it says "successful," the action completed without any significant problems.

Diag. report has been sent as requested.

Thanks for the tip about the log. I "discovered" it only yesterday. (I probably saw it when checking out the menus in the beginning, but have never used it. I'm used to hunting for logs in the various usual places, so the user friendly design of QRecall log didn't registered. Sorry.)

Speaking of log, I found several peculiar entries that may (or may not) have something to do with the mystery. It's an error message that says "Unable to connect with helper". There are several occurrences in the log, including a recent one at 10:35:21 local time (it's 11:05 right now).

There was one action scheduled around that time, at 10:35 sharp (a "Capture" to a different archive), and there's no log entry of the action (before or after the error), but I'm pretty sure no change was done to the associated source folder, so there's nothing to capture.

Going further back, another "Unable to connect with helper" error was logged at 00:29:22 today, but no action was scheduled then, I believe.

Ming-Li Wang wrote:Diag. report has been sent as requested.

Received. I'll take a look at it soon.

Speaking of log, I found several peculiar entries that may (or may not) have something to do with the mystery. It's an error message that says "Unable to connect with helper". There are several occurrences in the log, including a recent one at 10:35:21 local time (it's 11:05 right now).

If the actions are running and finishing correctly, you can ignore those messages.

QRecall uses Mach ports to communicate with running processes. Prior to OS X 10.8, Mach ports were rock solid. You could open a port and leave it open for days without any problem. Now they seem to spontaneously close themselves, and I've never learned why. Earlier versions of QRecall would treat a port communications error very seriously because it almost always meant one of the processes had crashed?which is pretty serious. But now this just happens for reasons unknown, so it's much less indicative of a problem.

The next version of QRecall is more tolerate of the kernel's behavior. (It will still log the closed port, but it now doesn't complain unless it is also unable to reestablish a new connection.)

There was one action scheduled around that time, at 10:35 sharp (a "Capture" to a different archive), and there's no log entry of the action (before or after the error), but I'm pretty sure no change was done to the associated source folder, so there's nothing to capture.

There could be some log window subtlety here. Every log message (and every hierarchical group of log messages) has a severity value associated with it. Failures are a big deal, warnings not so much, and so on, down to minutia and debug messages. The slider at the top of the log window filters out less significant messages so you aren't bombarded by trivial details if all you want to know is if there was an error.

When a capture action starts, it logs a regular "Capture started" message. If the capture action finds no changes (meaning nothing was added to the archive), it changes the severity of the message to "minutia." If the slider isn't all the way to the right, you won't see "minutia" messages. This is so, if you've created a capture that runs every 15 minutes, your log window won't be filled with "Captured nothing" 96 times a day. You'll only see the capture actions that actually captured something, or had problems.

Good to know. I remember seeing the "severity slider" in the help documentation, but have forgotten about it until you mentioned it. A clever and very useful design, indeed. Thanks.