30 Mar
2010
30 Mar
'10
5:43 p.m.
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
30 Mar
30 Mar
6:06 p.m.
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
6:18 p.m.
On Tue, Mar 30, 2010 at 7:06 PM, Fritz Anderson <fritza(a)uchicago.edu> wrote:
On Mar 30, 2010, at 12:43 PM, Nicholas Cole wrote:
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
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. 
7 May
7 May
9:57 a.m.
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.
17 May
17 May
12:36 p.m.
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
3945
days inactive
3993
days old
4 comments
4 participants
participants (4)
-
Adam Strzelecki -
Allan Odgaard -
Fritz Anderson -
Nicholas Cole