Package: emacs21
Version: 22.2+2-5
Since upgrading to lenny, users here report emacs freezing very often here.
(All debuging happening with the i386 package:)
Attaching to such a process in gdb does not look very informative:
(gdb) bt
#0 0xb7c56dee in ?? () from /lib/libc.so.6
#1 0xb7bef35d in ?? () from /lib/libc.so.6
after installing libc6-dbg it is a bit more informative:
#0 0xb7c56dee in __lll_lock_wait_private () from /lib/libc.so.6
#1 0xb7bef35d in _L_lock_2163 () from /lib/libc.so.6
#2 0xb7beb29d in mALLOPt () from /lib/libc.so.6
#3 0x0812d460 in ?? ()
#4 0xfffffffe in ?? ()
#5 0x00000000 in ?? ()
But a bit of disassembling hints that this might be within the
__malloc_hook code emacs uses:
0xb7c56dd0: push %edx
0xb7c56dd1: push %ebx
0xb7c56dd2: push %esi
0xb7c56dd3: mov $0x2,%edx
0xb7c56dd8: mov %ecx,%ebx
0xb7c56dda: xor %esi,%esi
0xb7c56ddc: mov %gs:0x20,%ecx
0xb7c56de3: cmp %edx,%eax
0xb7c56de5: jne 0xb7c56dee
0xb7c56de7: mov $0xf0,%eax
0xb7c56dec: int $0x80
0xb7c56dee: mov %edx,%eax
0xb7c56df0: xchg %eax,(%ebx)
0xb7c56df2: test %eax,%eax
0xb7c56df4: jne 0xb7c56de7
0xb7c56df6: pop %esi
0xb7c56df7: pop %ebx
0xb7c56df8: pop %edx
0xb7c56df9: ret
(gdb) p ((int**)$esp)[3]
$5 = (int *) 0xb7bef35d
0xb7bef35d: jmp 0xb7beb29d
0xb7beb29d: lea 0x116c(%ebx),%eax
0xb7beb2a3: call 0xb7bea880
0xb7beb2a8: lea 0x6(%edi),%eax
0xb7beb2ab: cmp $0x7,%eax
0xb7beb2ae: jbe 0xb7beb2e0
0xb7beb2b0: mov $0x1,%ecx
0xb7beb2b5: cmpl $0x0,%gs:0xc
0xb7beb2bd: je 0xb7beb2c0
0xb7beb2bf: lock subl $0x1,0x116c(%ebx)
0xb7beb2c7: jne 0xb7bef362
0xb7beb2cd: mov %ecx,%eax
0xb7beb2cf: mov (%esp),%ebx
0xb7beb2d2: mov 0x4(%esp),%esi
0xb7beb2d6: mov 0x8(%esp),%edi
0xb7beb2da: mov %ebp,%esp
0xb7beb2dc: pop %ebp
0xb7beb2dd: ret
(gdb) p (*(int***)$ebp)[1]
$16 = (int *) 0xb7bee525
0xb7bee4f0 <malloc+0>: push %ebp
0xb7bee4f1 <malloc+1>: mov %esp,%ebp
0xb7bee4f3 <malloc+3>: sub $0x1c,%esp
0xb7bee4f6 <malloc+6>: mov %ebx,-0xc(%ebp)
0xb7bee4f9 <malloc+9>: call 0xb7b9628f <_unwind_find_...@plt+119>
0xb7bee4fe <malloc+14>: add $0xcbaf6,%ebx
0xb7bee504 <malloc+20>: mov %edi,-0x4(%ebp)
0xb7bee507 <malloc+23>: mov 0x8(%ebp),%edi
0xb7bee50a <malloc+26>: mov %esi,-0x8(%ebp)
0xb7bee50d <malloc+29>: mov -0xf4(%ebx),%eax
0xb7bee513 <malloc+35>: mov (%eax),%edx
0xb7bee515 <malloc+37>: test %edx,%edx
0xb7bee517 <malloc+39>: je 0xb7bee538 <malloc+72>
0xb7bee519 <malloc+41>: mov 0x4(%ebp),%eax
0xb7bee51c <malloc+44>: mov %edi,(%esp)
0xb7bee51f <malloc+47>: mov %eax,0x4(%esp)
0xb7bee523 <malloc+51>: call *%edx
0xb7bee525 <malloc+53>: mov %eax,%esi
0xb7bee527 <malloc+55>: mov %esi,%eax
0xb7bee529 <malloc+57>: mov -0xc(%ebp),%ebx
0xb7bee52c <malloc+60>: mov -0x8(%ebp),%esi
0xb7bee52f <malloc+63>: mov -0x4(%ebp),%edi
0xb7bee532 <malloc+66>: mov %ebp,%esp
0xb7bee534 <malloc+68>: pop %ebp
0xb7bee535 <malloc+69>: ret
This means it happens inside a __malloc_hook call.
(actually like inside an mallopt inside a __malloc_hook,
though that mallopt seems to be the last one inside the hook,
which is strange).
To verify it may be related, I compiled emacs with the following patch,
which should make emacs stop its __malloc_hook tricks:
Index: emacs21-21.4a+1/src/s/gnu-linux.h
===================================================================
--- emacs21-21.4a+1.orig/src/s/gnu-linux.h 2009-04-28 17:17:40.000000000
+0200
+++ emacs21-21.4a+1/src/s/gnu-linux.h 2009-04-28 17:18:35.000000000 +0200
@@ -26,6 +26,9 @@
* Define all the symbols that apply correctly.
*/
+/* are there hangs happening in the malloc hooks? */
+#define SYSTEM_MALLOC 1
+
/* #define UNIPLUS */
/* #define USG5 */
#define USG
With this patch, no more hangs are reported.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
