close Warning: Failed to sync with repository "(default)": [Errno 12] Cannot allocate memory; repository information may be out of date. Look in the Trac log for more information including mitigation strategies.
Modify

#333 closed defect (fixed)

Jabber module uses 100% CPU

Reported by: spam-bitlbee@… Owned by:
Priority: major Milestone: 1.2
Component: BitlBee Version: 1.1.1dev
Keywords: cpu jabber Cc:
IRC client+version: Client-independent Operating System: Public server
OS version/distro:

Description

Bitlbee version 1.1.1dev (1.1 did it too) starts 100% CPU from time to time.

I am not 100% sure but it seems it is when all my contacts are offline.

account off and then account on gets CPU utilisation back to normal.

Attachments (0)

Change History (9)

comment:1 Changed at 2007-12-06T00:03:11Z by wilmer

Ugh, I really hoped this wouldn't come back another time. So you can still give commands? I don't think the fact that your contacts are offline has anything to do with this, BitlBee doesn't really care about things like that.

Can you try to figure out what BitlBee's doing at those moments? Maybe using strace or gdb?

comment:2 Changed at 2007-12-06T00:03:23Z by wilmer

Milestone: 1.2

comment:3 Changed at 2007-12-06T09:35:59Z by anonymous

yes I can still give commands, i'm going to recompile it with debug symbols to try to give you a backtrace or something usable

comment:4 Changed at 2007-12-09T23:34:14Z by wilmer

Found something yet?

comment:5 Changed at 2007-12-09T23:39:34Z by wilmer

BTW, can you give me some more info? Like, which event handling lib do you use (probably GLib)? Are you using SSL/TLS? If so, which SSL library?

This has to be fixed...

comment:6 Changed at 2007-12-10T12:02:34Z by anonymous

i'm using glib/gnutls, ssl enabled yes.

the bug didn't show up yet. It is much less frequent since 1.1.1dev compared to 1.1dev.

Last time it did show up I did attach gdb to it and checked the backtrace: it was in glib but I had no debug symbols so I hardly could debug it.

I'll post more when it shows up next time.

comment:7 Changed at 2007-12-11T11:13:02Z by anonymous

strace gives thousands of :

gettimeofday({1197371160, 331858}, NULL) = 0
gettimeofday({1197371160, 331915}, NULL) = 0
poll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=5, events=POLLIN, revents=POLLIN}, {fd=5, events=POLLOUT, revents=POLLOUT}], 5, 1686) = 2
gettimeofday({1197371160, 331995}, NULL) = 0
gettimeofday({1197371160, 332025}, NULL) = 0
poll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=5, events=POLLIN, revents=POLLIN}, {fd=5, events=POLLOUT, revents=POLLOUT}], 5, 1686) = 2

CPU utilisation is @ 100% with 40% system time. gdb backtrace doesn't give something meaningful. I'll let it running, so you can tell me if you want to do other things.

comment:8 Changed at 2007-12-11T11:32:21Z by wilmer

We most likely tracked this down thanks to gdb. Will try to roll out a fix soon.

comment:9 Changed at 2007-12-12T21:43:00Z by wilmer

Resolution: fixed
Status: newclosed

I'm quite sure I fixed this now. Could you please try out r285 and reopen if it's still broken?

Modify Ticket

Action
as closed The ticket will remain with no owner.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.