* bug#6579: 23.2; (require 'dbus) without dbus being available makes Emacs unresponsive, maxing out CPU and eating memory
@ 2010-07-07 12:20 David Engster
2010-07-08 16:28 ` Michael Albinus
2010-07-09 9:12 ` Michael Albinus
0 siblings, 2 replies; 5+ messages in thread
From: David Engster @ 2010-07-07 12:20 UTC (permalink / raw
To: 6579
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#6579: 23.2; (require 'dbus) without dbus being available makes Emacs unresponsive, maxing out CPU and eating memory
2010-07-07 12:20 bug#6579: 23.2; (require 'dbus) without dbus being available makes Emacs unresponsive, maxing out CPU and eating memory David Engster
@ 2010-07-08 16:28 ` Michael Albinus
2010-07-09 9:12 ` Michael Albinus
1 sibling, 0 replies; 5+ messages in thread
From: Michael Albinus @ 2010-07-08 16:28 UTC (permalink / raw
To: David Engster; +Cc: 6579
David Engster <deng@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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#6579: 23.2; (require 'dbus) without dbus being available makes Emacs unresponsive, maxing out CPU and eating memory
2010-07-07 12:20 bug#6579: 23.2; (require 'dbus) without dbus being available makes Emacs unresponsive, maxing out CPU and eating memory David Engster
2010-07-08 16:28 ` Michael Albinus
@ 2010-07-09 9:12 ` Michael Albinus
2010-07-09 11:25 ` David Engster
1 sibling, 1 reply; 5+ messages in thread
From: Michael Albinus @ 2010-07-09 9:12 UTC (permalink / raw
To: David Engster; +Cc: 6579
David Engster <deng@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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#6579: 23.2; (require 'dbus) without dbus being available makes Emacs unresponsive, maxing out CPU and eating memory
2010-07-09 9:12 ` Michael Albinus
@ 2010-07-09 11:25 ` David Engster
2010-07-09 12:27 ` Michael Albinus
0 siblings, 1 reply; 5+ messages in thread
From: David Engster @ 2010-07-09 11:25 UTC (permalink / raw
To: Michael Albinus; +Cc: 6579
Michael Albinus writes:
> David Engster <deng@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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#6579: 23.2; (require 'dbus) without dbus being available makes Emacs unresponsive, maxing out CPU and eating memory
2010-07-09 11:25 ` David Engster
@ 2010-07-09 12:27 ` Michael Albinus
0 siblings, 0 replies; 5+ messages in thread
From: Michael Albinus @ 2010-07-09 12:27 UTC (permalink / raw
To: David Engster; +Cc: 6579-done
David Engster <deng@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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-07-09 12:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-07 12:20 bug#6579: 23.2; (require 'dbus) without dbus being available makes Emacs unresponsive, maxing out CPU and eating memory David Engster
2010-07-08 16:28 ` Michael Albinus
2010-07-09 9:12 ` Michael Albinus
2010-07-09 11:25 ` David Engster
2010-07-09 12:27 ` Michael Albinus
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.