Dear List,
I have a strange bug to report. Using 10.6.3, Textmate and Skim together (via the LaTeX bundle) seems to trigger a nasty bug in OS X. As far as I can tell, it is triggered when skim reloads a changed PDF file, but I haven't been able to completely reliably find out exactly what triggers it. At first I thought it was to do with the pdfsync functionality, but then I noticed it could be triggered simply if the files changed. Whatever is causing it, once triggered any new process on the machine will use up 100% of the CPU. The only way to get things back to normal is to log out of the user account and back in again.
I realise that this is a very sketchy bug report - I'm posting it here in the hopes that someone else has run into it and has managed to work out exactly what is causing it better than I have. I'm not even sure if the fault lies with skim or with textmate or with the latex bundle.
Best wishes,
Nicholas
On Mar 30, 2010, at 12:43 PM, Nicholas Cole wrote:
I realise that this is a very sketchy bug report - I'm posting it here in the hopes that someone else has run into it and has managed to work out exactly what is causing it better than I have. I'm not even sure if the fault lies with skim or with textmate or with the latex bundle.
If you know the processor is saturated, I assume you're already running Activity Monitor. Sort the window by % CPU to see what process is taking up the bandwidth. That may tell you where the problem is. Select that line. Click the Sample Process button in the toolbar. If the resulting stack trace doesn't tell you anything, it will probably mean something to the author of the offending program.
You can also use the Quit Process button to kill the offender without having to log yourself out.
— F
On Tue, Mar 30, 2010 at 7:06 PM, Fritz Anderson fritza@uchicago.edu wrote:
On Mar 30, 2010, at 12:43 PM, Nicholas Cole wrote:
I realise that this is a very sketchy bug report - I'm posting it here in the hopes that someone else has run into it and has managed to work out exactly what is causing it better than I have. I'm not even sure if the fault lies with skim or with textmate or with the latex bundle.
If you know the processor is saturated, I assume you're already running Activity Monitor. Sort the window by % CPU to see what process is taking up the bandwidth. That may tell you where the problem is. Select that line. Click the Sample Process button in the toolbar. If the resulting stack trace doesn't tell you anything, it will probably mean something to the author of the offending program.
You can also use the Quit Process button to kill the offender without having to log yourself out.
I should have been clearer - this is what is so strange about this bug. Once it is triggered, any new process starts eating up the CPU, no matter what it is, and killing it in the task manager doesn't reduce the CPU load. That's why I find this bug so odd...
N
On 30 Mar 2010, at 20:18, Nicholas Cole wrote:
[…] Once it is triggered, any new process starts eating up the CPU, no matter what it is, and killing it in the task manager doesn't reduce the CPU load. That's why I find this bug so odd...
Then just run ‘sample’ on a new process.
Most likely some OS service has “gone down” and is what is causing the problem. Getting a stack trace (from sample) will likely show what OS service the task is using.
As far as I can tell, it is triggered when skim reloads a changed PDF file, but I haven't been able to completely reliably find out exactly what triggers it. At first I thought it was to do with the pdfsync functionality, but then I noticed it could be triggered simply if the files changed.
Aside of whether this is a Skim bug or not, IMHO it is recommended to switch OFF checking for file changes in Skim Sync properties while you're using Latex bundle, which anyway forces Skim to reload the file upon each compilation.
Regards,
-
Adam Strzelecki -
Allan Odgaard -
Fritz Anderson -
Nicholas Cole