Wave of messages in syslog

Create issue
Issue #178 resolved
Evgeny Seliverstov created an issue

Experienced sudden increase of CPU usage of syslog, MacHg and Console.app. Symptoms: nothing special, no files were removed, happened after commit, FileMerge was opened for comparing two revisions.

{{{ Jan 23 21:14:45: --- last message repeated 46 times --- Jan 23 21:14:45 xxx [0x0-0x1656655].com.jasonfharris.MachHg[17262]: 2011-01-23 21:14 MacHg[17262] (CarbonCore.framework) Jan 23 21:14:45 xxx [0x0-0x1656655].com.jasonfharris.MachHg[17262]: process_dir_events: kevent returned -1 (Bad file descriptor) Jan 23 21:14:45 xxx [0x0-0x1656655].com.jasonfharris.MachHg[17262]: 2011-01-23 21:14 MacHg[17262] (CarbonCore.framework) process_dir_events: kevent returned -1 (Bad file descriptor)


Comments (4)

  1. Jason Harris repo owner

    Thanks for the report! If you quit, restart and run MacHg again can you reproduce this?

    If not I will regrettably close as not reproducible. Unfortunately these things if they are not reproducible are really really really hard to pin down. It could be any number of things and having a bug around with no idea of how to reproduce it is problematic. Thus I'll close the bug.

    However, if you can reproduce this after a restart, then I am definitely interested! Please send through lots of details. Can you publish or send me a private copy of the repository? Can you make a short video (eg ishowu)? Can you describe the other things going on with your system? I'll ask more stuff if you can reproduce this...

    Thanks, Jas

  2. Evgeny Seliverstov reporter

    Thank you for attention!

    Unfortunalety, it doesn't seem to be reproducible. I followed initial workflow that leads to a bug but it doesn't appear. I'll report if I would reproduce it.

  3. Jason Harris repo owner

    - Fix issue 148. We need to abandon and cut off the repository data when we switch the view to the backing view. - What was happening is that the old RepositoryData was still in existence and listening to notifications even though the document didn't point to it. Thus, when a kUnderlyingRepositoryChanged was generally posted this limbo RepositoryData was still trying to update itself. But while the limbo Repository data was trying to update itself it had problems during the update since the repository no longer existed on disk, so it asked for another update which again triggered the limbo repository to ask for an update, etc. Meanwhile the good repository that the document actually pointed to was also observing these repeated notifications to keep updating and so it flickered as lots and lots of updates took place... All of this wound the CPU right up. - Thus I think this accounts for the flicking and high CPU usage. - It also Fixes #158, Fixes #164, Fixes #173, Fixes #178, and Addresses #179.


  4. Log in to comment