GNU bug report logs - #6579
23.2; (require 'dbus) without dbus being available makes Emacs unresponsive, maxing out CPU and eating memory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6579 in the body.
You can then email your comments to 6579 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Engster <deng <at> randomsample.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2; (require 'dbus) without dbus being available makes Emacs
	unresponsive, maxing out CPU and eating memory
Date: Wed, 07 Jul 2010 14:20:46 +0200

This was observed on GNU/Linux (Archlinux), but I also witnessed this
under OS X.

* Stop dbus or do not start it in the first place.

* emacs -Q

* evaluate (require 'dbus) in the scratch buffer

Emacs now consumes 100% CPU and is quickly eating memory until there is
no more. Pressing C-g (or any other key) doesn't have any effect.

Attaching gdb to Emacs in this situation usually shows different
backtraces; here is one example:

(gdb) bt full
#0  0x081c0ef7 in set_internal (symbol=23, newval=138692810, buf=0x0,
# bindflag=1) at data.c:1180
        voide = 0
        valcontents = 138692810
        innercontents = -1074816364
        tem1 = -1074816364
        current_alist_element = 0
#1  0x081d801a in unbind_to (count=2, value=138692810) at eval.c:3409
        this_binding = {
          symbol = 138811818, 
          old_value = 138692810, 
          func = 0, 
          unused = 0
        }
        quitf = 138692810
        gcpro1 = {
          next = 0x85bf188, 
          var = 0x14c7ebde, 
          nvars = 140243341
        }
        gcpro2 = {
          next = 0x81d7e0b, 
          var = 0x8468c12, 
          nvars = 138692858
        }
#2  0x082384f7 in update_compositions (from=37, to=38, check_mask=3) at
composite.c:605
        count = 2
        prop = 0
        start = 38
        end = 38
        min_pos = 37
        max_pos = 38
#3  0x08181024 in insert (string=0xbfef9337 "o\001", nbytes=1) at
insdel.c:727
        len = 1
        opoint = 37
#4  0x0818118f in insert_char (c=111) at insdel.c:762
        str = "o\001\000\000"
        len = 1
#5  0x081f0b26 in printchar (ch=111, fun=138692858) at print.c:337
        multibyte_p = 1
        str = "o\000\000\000"
        len = 1
#6  0x081f5ae7 in print_object (obj=348447145, printcharfun=138692858,
escapeflag=1) at print.c:1720
        len = 2
        c = 111
        i_byte = 23
        gcpro1 = {
          next = 0x84448ca, 
          var = 0x14c7ed16, 
          nvars = 138839264
        }
        str = 0x14c778cc "Failed to connect to socket
        /var/run/dbus/system_bus_socket: Connection refused"
        need_nonhex = 0
        multibyte = 0
        size_byte = 79
        buf =
        "`\225\357\277K\177F\bh\225\357\277\354\r\034\bK\177F\b{`,\t\372HD\b\000\000\000\000\000\000\000\000ȭD\b"
#7  0x081f49ba in print (obj=348447129, printcharfun=138692858,
escapeflag=1) at print.c:1304
No locals.
#8  0x081f2d52 in Fprin1 (object=348447129, printcharfun=138692858) at
# print.c:750
        old = 0x844adc8
        old_point = -1
        start_point = -1
        old_point_byte = -1
        start_point_byte = -1
        specpdl_count = 2
        free_print_buffer = 0
        multibyte = 1
        original = 138692858
#9  0x081f44b8 in print_error_message (data=348647862, stream=138692858,
context=0xbfef9726 "", caller=138692810) at print.c:1105
        obj = 348447129
        errname = 138895850
        errmsg = 136789105
        file_error = 138692810
        tail = 348647846
        gcpro1 = {
          next = 0x0, 
          var = 0xb6a08847, 
          nvars = 1
        }
        i = 0
#10 0x08156045 in cmd_error_internal (data=348647862, context=0xbfef9726 "")
at keyboard.c:1305
        sf = 0x9168410
---Type <return> to continue, or q <return> to quit---
#11 0x08155e99 in cmd_error (data=348647862) at keyboard.c:1234
        old_level = 138692810
        old_length = 138692810
        macroerror = "\000\000)\000\000\000\275\031+\b", '\000' <repeats 12
        times>"\312,
        HD\b\344\234ￔ\232\357\277\002\000\000\000Pa\025\b\000\000\000\000\000\000\000"
#12 0x081d4f19 in internal_condition_case (bfun=0x81563d1 <command_loop_1>,
handlers=138730794, hfun=0x8155dab <cmd_error>) at eval.c:1480
        val = 138939926
        c = {
          tag = 138692810, 
          val = 348647862, 
          next = 0xbfef98a8, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {0, -1074815772, -1074816364, -1074816920,
1352025123, -1255756980}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {3220150368, 3220150304, 0, 3077898242, 3078043896,
134547426, 3065788424, 3078041532, 3063912900, 36, 3220150056, 3077961474,
100, 3065237492, 3064330609, 3065244704, 3220149964, 36, 3065237492,
138616160, 
                  138616288, 3063930392, 3065788424, 135734916, 4294967295,
3078041532, 134547426, 1, 3220150384, 3077978728, 3078044336, 3060471368}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
        h = {
          handler = 138730794, 
          var = 138692810, 
          chosen_clause = 138692858, 
          tag = 0xbfef9794, 
          next = 0x0
        }
#13 0x08156127 in command_loop_2 () at keyboard.c:1360
        val = 0
#14 0x081d4a4e in internal_catch (tag=138727866, func=0x8156102
<command_loop_2>, arg=138692810) at eval.c:1226
        c = {
          tag = 138727866, 
          val = 138692810, 
          next = 0x0, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {-1074815632, -1074815772, -1074816364,
-1074816648, 1351189539, -1255351476}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {0 <repeats 16 times>, 3064348398, 0, 0, 0,
138858107, 3220150648, 136057552, 138860226, 138858107, 138692810,
138718664, 140838948, 136705628, 14, 22, 192}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
#15 0x081560e0 in command_loop () at keyboard.c:1339
No locals.
#16 0x081559ca in recursive_edit_1 () at keyboard.c:954
        count = 1
        val = -1074816504
#17 0x08155b35 in Frecursive_edit () at keyboard.c:1016
        count = 0
        buffer = 138692810
#18 0x0815431b in main (argc=2, argv=0xbfef9e14) at emacs.c:1833
        dummy = 0
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = 1
        skip_args = 0
        rlim = {
          rlim_cur = 8388608, 
          rlim_max = 18446744073709551615
        }
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0


----------------------

Configuration:

In GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2010-05-08 on pidsley.hoetzel.info
Windowing system distributor `The X.Org Foundation', version 11.0.10801902
configured using `configure  '--prefix=/usr' '--sysconfdir=/etc' '--libexecdir=/usr/lib' '--localstatedir=/var' '--mandir=/usr/share/man' '--without-sound' '-with-x-toolkit=gtk' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fno-optimize-sibling-calls' 'LDFLAGS=-Wl,--hash-style=gnu -Wl,--as-needed''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Message #8 received at 6579 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: David Engster <deng <at> randomsample.de>
Cc: 6579 <at> debbugs.gnu.org
Subject: Re: bug#6579: 23.2;
	(require 'dbus) without dbus being available makes Emacs
	unresponsive, maxing out CPU and eating memory
Date: Thu, 08 Jul 2010 18:28:28 +0200

David Engster <deng <at> randomsample.de> writes:

> This was observed on GNU/Linux (Archlinux), but I also witnessed this
> under OS X.
>
> * Stop dbus or do not start it in the first place.
>
> * emacs -Q
>
> * evaluate (require 'dbus) in the scratch buffer
>
> Emacs now consumes 100% CPU and is quickly eating memory until there is
> no more. Pressing C-g (or any other key) doesn't have any effect.

Reproduced. I'll work on this next days.

Best regards, Michael.

Message #11 received at 6579 <at> debbugs.gnu.org (full text, mbox):

From: David Engster <deng <at> randomsample.de>
To: Michael Albinus <michael.albinus <at> tieto.com>
Cc: 6579 <at> debbugs.gnu.org
Subject: Re: bug#6579: 23.2;
	(require 'dbus) without dbus being available makes Emacs
	unresponsive, maxing out CPU and eating memory
Date: Fri, 09 Jul 2010 13:25:16 +0200

Michael Albinus writes:
> David Engster <deng <at> randomsample.de> writes:
>
>> * Stop dbus or do not start it in the first place.
>>
>> * emacs -Q
>>
>> * evaluate (require 'dbus) in the scratch buffer
>>
>> Emacs now consumes 100% CPU and is quickly eating memory until there is
>> no more. Pressing C-g (or any other key) doesn't have any effect.
>
> I've fixed it in the trunk.

Works for me. Thank you!

Maybe it would make sense to issue a warning when dbus is not available?

-David

Message #16 received at 6579-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: David Engster <deng <at> randomsample.de>
Cc: 6579-done <at> debbugs.gnu.org
Subject: Re: bug#6579: 23.2;
	(require 'dbus) without dbus being available makes Emacs
	unresponsive, maxing out CPU and eating memory
Date: Fri, 09 Jul 2010 14:27:20 +0200

David Engster <deng <at> randomsample.de> writes:

>> I've fixed it in the trunk.
>
> Works for me. Thank you!

Thanks for the test, I'll close the bug.

> Maybe it would make sense to issue a warning when dbus is not available?

Not when the session bus is unavailable; this is a common use
case. Maybe a chaeck for the unavailability of the system bus. OTHOH, I
don't know whether there are collateral damages then.

You can check the availability yourself:

(dbus-ignore-errors (dbus-get-unique-name :system))
(dbus-ignore-errors (dbus-get-unique-name :session))

Both forms return nil, when the respective bus is not available.

> -David

Best regards, Michael.

Message #19 received at 6579 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> tieto.com>
To: David Engster <deng <at> randomsample.de>
Cc: 6579 <at> debbugs.gnu.org
Subject: Re: bug#6579: 23.2;
	(require 'dbus) without dbus being available makes Emacs
	unresponsive, maxing out CPU and eating memory
Date: Fri, 09 Jul 2010 11:12:05 +0200

David Engster <deng <at> randomsample.de> writes:

> * Stop dbus or do not start it in the first place.
>
> * emacs -Q
>
> * evaluate (require 'dbus) in the scratch buffer
>
> Emacs now consumes 100% CPU and is quickly eating memory until there is
> no more. Pressing C-g (or any other key) doesn't have any effect.

I've fixed it in the trunk.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.