Opened 12 years ago

Last modified 11 years ago

#1116 new Defect

Colloquy eats 95%+ of CPU

Reported by: Sparks Owned by: timothy
Component: Chat Core (IRC) Version: 2.1 (Mac)
Severity: Critical Keywords:
Cc: beej, danchr, xenon, grahamperrin

Description

A bit of testing shows that this happens on Tiger with the Safari 3 WebKit? installed, but a (very) cursory check does not seem to have this happen on Leopard.

Periodically (often right after startup, but sometimes after hours running) Colloquy will begin to eat 95% or more of the CPU. Colloquy itself does not become in any way unresponsive or beachball, but the CPU of the machine is driven to the point that the fans kick in, and top or any other form of process monitor shows Colloquy pegging the CPU. Needless to say, this makes other software turn sluggish!

Disconnecting from everything, closing all windows, and basically making Colloquy stop doing everything does NOT correct this; only an entire quit and restart will solve the problem, and even then a restart seems likely to immediately peg again.

Change History (11)

comment:1 Changed 12 years ago by beej

cc me

comment:2 Changed 12 years ago by timothy

  • Cc beej added

comment:3 Changed 12 years ago by beej

the colloquy_sample.txt that i just attached is from Colloquy 2.1 going into this all too familiar tailspin. this time it happened as my C2D blackbook came out of sleep in closed lid mode. Colloquy itself was "Not Responding" according to OS 10.4.10 and had to be force quit.

comment:4 Changed 11 years ago by w0mbat

I'm having the same problem, except that Colloquy does become unresponsive. The app will spin for at least 5 minutes. Compiled from revision 3769.

MacBook? Pro, OS X 10.4.10, Safari 2

comment:5 Changed 11 years ago by danchr

  • Cc danchr added
  • Component changed from Colloquy (GUI) to Chat Core (IRC)

I experienced this very thing earlier today; Colloquy remained responsive and hogged every single CPU cycle it could get. I made a sample using Instruments.app, attached below. I was talking to akempgen whom I suspect is a Colloquy developer, and he said I “…really needed to talk to xenon about stuff like that.” AFAICT this bug is subscribed to him, all the more reason to think this is the same issue.

As far as I can tell, the culprit is [MVIRCChatConnection(MVIRCChatConnectionPrivate) _ircRunloop] from ChatCore. Judging from the source code for it, I suspect the issue may be an “opposite deadlock” so to speak; that for some reason, those locks and runloops do not suspend execution.

Environment:

  • Colloquy v2.1 (3761)
  • Mac OS X 10.5.1
  • 768MB RAM
  • 1.25GHz eMac G4

Input Managers:

  • SIMBL
  • SafariBlock

SIMBL plugins:

  • GrowlSafari
  • Keywurl
  • Twicetab

comment:6 Changed 11 years ago by danchr

Instruments.app sample, too large to upload.

comment:7 Changed 11 years ago by beej

  • Cc xenon added

comment:8 Changed 11 years ago by beej

xenon: was akempgen right about you being the person to talk to about this issue? it's very annoying :(

comment:9 Changed 11 years ago by beej

there is some evidence that the beachballing i'm seeing has to do with transcript indexing. i was set to "One File Per Session Day" logging, which is apparently broken (#1010, #1115). at the suggestion of bogo_lode from #colloquy, i changed that to "One File Per Session" and moved the old logs out of the way.

/me crosses fingers

comment:10 Changed 11 years ago by grahamperrin

  • Cc grahamperrin added

@ beej:

Are your fingers still crossed or has the workaround been successful for you?

Note: See TracTickets for help on using tickets.