all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: Fix to long-standing crashes in GC
@ 2004-05-13 18:19 Lars Hansen
  2004-05-13 19:09 ` Luc Teirlinck
                   ` (4 more replies)
  0 siblings, 5 replies; 55+ messages in thread
From: Lars Hansen @ 2004-05-13 18:19 UTC (permalink / raw)


For a long time I have experienced occasional crashes of CVS Emacs, 
usually during Tramp operations. I have four backtraces in case someone 
is interested, but I have not been able produce a test case. To me it 
looks as if GC is involved, but I am unexperienced with gdb. When Kim 
told he had fixed a bug involving GC and process output, it seemed at 
first very likely to be the cause of my troubles. However:

1. In one of the crashes Tramp was not involved.
2. CVS Emacs of today with Kim's fix, just crashed during a Tramp operation.

So now I don't know what to think.
Here is a backtrace from todays crash:

(gdb) run
Starting program: /home/lh/cvsroot/emacs/src/emacs

Program received signal SIGABRT, Aborted.
0x402ec781 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x402ec781 in kill () from /lib/libc.so.6
#1  0x080dfe0a in abort () at emacs.c:433
#2  0x08128037 in mark_object (arg=1217041176) at alloc.c:5034
#3  0x0812809a in mark_object (arg=-1463681024) at alloc.c:5051
#4  0x08126b43 in mark_memory (start=0xbfffe070, end=0xbffff7e8)
    at alloc.c:3700
#5  0x08126f73 in mark_stack () at alloc.c:4055
#6  0x08127549 in Fgarbage_collect () at alloc.c:4429
#7  0x081627f5 in Fbyte_code (bytestr=1752418136, vector=-2006055672,
    maxdepth=53) at bytecode.c:522
#8  0x0813aec1 in funcall_lambda (fun=-2006055216, nargs=3,
    arg_vector=0xbfffe368) at eval.c:2913
#9  0x0813aa81 in Ffuncall (nargs=4, args=0xbfffe364) at eval.c:2783
#10 0x0813a3a5 in Fapply (nargs=3, args=0xbfffe418) at eval.c:2231
#11 0x0813a906 in Ffuncall (nargs=4, args=0xbfffe414) at eval.c:2707
#12 0x081629ec in Fbyte_code (bytestr=1752417784, vector=-2005715320,
    maxdepth=5) at bytecode.c:689
#13 0x0813aec1 in funcall_lambda (fun=-2006054856, nargs=3,
    arg_vector=0xbfffe548) at eval.c:2913
#14 0x0813aa81 in Ffuncall (nargs=4, args=0xbfffe544) at eval.c:2783
#15 0x0813a727 in call3 (fn=675593896, arg1=675187520, arg2=1751585648,
    arg3=675056464) at eval.c:2565
#16 0x08107d13 in Fexpand_file_name (name=1751585648,
    default_directory=675056464) at fileio.c:1705
#17 0x0813a9ad in Ffuncall (nargs=3, args=0xbfffe5f4) at eval.c:2729
#18 0x0813a3a5 in Fapply (nargs=2, args=0xbfffe6a8) at eval.c:2231
#19 0x0813a906 in Ffuncall (nargs=3, args=0xbfffe6a4) at eval.c:2707
#20 0x081629ec in Fbyte_code (bytestr=1752592784, vector=-2005500296,
    maxdepth=5) at bytecode.c:689
#21 0x0813aec1 in funcall_lambda (fun=-2005500152, nargs=3,
    arg_vector=0xbfffe7d8) at eval.c:2913
#22 0x0813aa81 in Ffuncall (nargs=4, args=0xbfffe7d4) at eval.c:2783
#23 0x0813a727 in call3 (fn=678851976, arg1=675187520, arg2=1751585648,
    arg3=675056464) at eval.c:2565
#24 0x08107d13 in Fexpand_file_name (name=1751585648,
    default_directory=675056464) at fileio.c:1705
#25 0x0810f5b0 in Fdirectory_files_and_attributes (directory=1751585648,
    full=675056464, match=675056464, nosort=675056512, id_format=675056464)
    at dired.c:383
#26 0x0813aa11 in Ffuncall (nargs=6, args=0xbfffe8c4) at eval.c:2759
#27 0x0813a3a5 in Fapply (nargs=2, args=0xbfffe988) at eval.c:2231
#28 0x0813a906 in Ffuncall (nargs=3, args=0xbfffe984) at eval.c:2707
#29 0x081629ec in Fbyte_code (bytestr=1752592784, vector=-2005500296,
    maxdepth=5) at bytecode.c:689
#30 0x0813aec1 in funcall_lambda (fun=-2005500152, nargs=6,
    arg_vector=0xbfffeab8) at eval.c:2913
#31 0x0813aa81 in Ffuncall (nargs=7, args=0xbfffeab4) at eval.c:2783
#32 0x0813a787 in call6 (fn=678851976, arg1=675173912, arg2=1751585648,
    arg3=675056464, arg4=675056464, arg5=675056512, arg6=675056464)
    at eval.c:2640
#33 0x0810f5fd in Fdirectory_files_and_attributes (directory=1757484384,
    full=675056464, match=675056464, nosort=675056512, id_format=675056464)
    at dired.c:389
#34 0x0813aa11 in Ffuncall (nargs=5, args=0xbfffeb94) at eval.c:2759
#35 0x081629ec in Fbyte_code (bytestr=1753402600, vector=-2004489696,
    maxdepth=9) at bytecode.c:689
#36 0x0813aec1 in funcall_lambda (fun=-2005624000, nargs=1,
    arg_vector=0xbfffecac) at eval.c:2913
#37 0x0813aa81 in Ffuncall (nargs=2, args=0xbfffeca8) at eval.c:2783
#38 0x081629ec in Fbyte_code (bytestr=1753388008, vector=-2004492704,
    maxdepth=3) at bytecode.c:689
#39 0x0813aec1 in funcall_lambda (fun=-2004860712, nargs=2,
    arg_vector=0xbfffeda8) at eval.c:2913
#40 0x0813aa81 in Ffuncall (nargs=3, args=0xbfffeda4) at eval.c:2783
#41 0x081629ec in Fbyte_code (bytestr=1753387640, vector=-2004626104,
    maxdepth=3) at bytecode.c:689
#42 0x0813aec1 in funcall_lambda (fun=-2004751064, nargs=0,
    arg_vector=0xbfffeea8) at eval.c:2913
#43 0x0813aa81 in Ffuncall (nargs=1, args=0xbfffeea4) at eval.c:2783
#44 0x081629ec in Fbyte_code (bytestr=1753387960, vector=-2004692136,
    maxdepth=7) at bytecode.c:689
#45 0x0813aec1 in funcall_lambda (fun=-2005043992, nargs=0,
    arg_vector=0xbfffefb8) at eval.c:2913
#46 0x0813aa81 in Ffuncall (nargs=1, args=0xbfffefb4) at eval.c:2783
#47 0x081629ec in Fbyte_code (bytestr=1753387448, vector=-2004623568,
    maxdepth=2) at bytecode.c:689
#48 0x0813aec1 in funcall_lambda (fun=-2004907320, nargs=0,
    arg_vector=0xbffff0b8) at eval.c:2913
#49 0x0813aa81 in Ffuncall (nargs=1, args=0xbffff0b4) at eval.c:2783
#50 0x081629ec in Fbyte_code (bytestr=1753223744, vector=-2004866968,
    maxdepth=3) at bytecode.c:689
#51 0x0813aec1 in funcall_lambda (fun=-2004917192, nargs=1,
    arg_vector=0xbffff1b8) at eval.c:2913
#52 0x0813aa81 in Ffuncall (nargs=2, args=0xbffff1b4) at eval.c:2783
#53 0x081629ec in Fbyte_code (bytestr=1753213760, vector=-2004869680,
    maxdepth=2) at bytecode.c:689
#54 0x0813aec1 in funcall_lambda (fun=-2004773840, nargs=0,
    arg_vector=0xbffff2d8) at eval.c:2913
#55 0x0813aa81 in Ffuncall (nargs=1, args=0xbffff2d4) at eval.c:2783
#56 0x0813a6b1 in apply1 (fn=679775736, arg=675056464) at eval.c:2476
#57 0x08136649 in Fcall_interactively (function=679775736,
    record_flag=675056464, keys=-2009241248) at callint.c:406
#58 0x080ecdc9 in Fcommand_execute (cmd=679775736, record_flag=675056464,
    keys=675056464, special=675056464) at keyboard.c:9670
#59 0x080e34ac in command_loop_1 () at keyboard.c:1727
#60 0x08138fad in internal_condition_case (bfun=0x80e27c0 <command_loop_1>,
    handlers=675117376, hfun=0x80e23c4 <cmd_error>) at eval.c:1333
#61 0x080e2688 in command_loop_2 () at keyboard.c:1264
#62 0x08138b25 in internal_catch (tag=675111408,
    func=0x80e2664 <command_loop_2>, arg=675056464) at eval.c:1094
#63 0x080e2633 in command_loop () at keyboard.c:1243
#64 0x080e2188 in recursive_edit_1 () at keyboard.c:959
#65 0x080e22b0 in Frecursive_edit () at keyboard.c:1015
#66 0x080e1122 in main (argc=1, argv=0xbffffa64) at emacs.c:1692
(gdb)

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Re: Fix to long-standing crashes in GC
@ 2004-05-13 23:34 Robert Anderson
  0 siblings, 0 replies; 55+ messages in thread
From: Robert Anderson @ 2004-05-13 23:34 UTC (permalink / raw)
  Cc: larsh, emacs-devel


--- Original Message ---
From: Luc Teirlinck <teirllm@dms.auburn.edu>
To: monnier@iro.umontreal.ca
CC: larsh@math.ku.dk, emacs-devel@gnu.org
Subject: Re: Fix to long-standing crashes in GC

>Stefan Monnier wrote:
>
>   When the GC seems to be involved what it typically means that
there's
>   a memory corruption somewhere.

Which begs the question again of:  did anyone get emacs running
under valgrind yet?  It's a godsend for such bugs.

Bob

^ permalink raw reply	[flat|nested] 55+ messages in thread
* Fix to long-standing crashes in GC
@ 2004-05-12 13:19 Kim F. Storm
  2004-05-13 13:06 ` Kenichi Handa
  2004-05-13 15:45 ` Richard Stallman
  0 siblings, 2 replies; 55+ messages in thread
From: Kim F. Storm @ 2004-05-12 13:19 UTC (permalink / raw)



I have installed a change to read_process_output which fixes some
seemingly unexplainable crashes during GC in compact_small_strings and
allocate_string.

The bug was related to reading & decoding multibyte process output.

If some people who reported such crashes in the past still have test
cases for such crashes, could you please try to repeat those test.

Notice that the bug is also present in 21.1, 21.2, and 21.3.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 55+ messages in thread

end of thread, other threads:[~2004-06-08 20:03 UTC | newest]

Thread overview: 55+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-13 18:19 Fix to long-standing crashes in GC Lars Hansen
2004-05-13 19:09 ` Luc Teirlinck
2004-05-13 19:29   ` Luc Teirlinck
2004-05-13 19:30   ` Lars Hansen
2004-05-13 19:19 ` Stefan Monnier
2004-05-13 22:16   ` Luc Teirlinck
2004-05-13 23:04     ` Stefan Monnier
2004-05-14 11:42     ` Kai Grossjohann
2004-05-14 14:53       ` Luc Teirlinck
2004-05-14 20:48         ` Kai Grossjohann
2004-05-16  9:27         ` Kai Grossjohann
2004-05-14 18:39       ` Luc Teirlinck
2004-05-14 20:54         ` Kim F. Storm
2004-05-14 21:02 ` Richard Stallman
2004-05-22 18:09   ` Lars Hansen
2004-05-23 16:33     ` Eli Zaretskii
2004-05-23 16:32       ` Luc Teirlinck
2004-05-23 17:11         ` Lars Hansen
2004-05-24  5:30         ` Eli Zaretskii
2004-05-25  3:03           ` Luc Teirlinck
2004-05-25  7:07             ` Eli Zaretskii
2004-05-15  4:39 ` Robert Marshall
2004-05-17 14:39   ` Kim F. Storm
2004-05-17 17:42     ` Robert Marshall
2004-05-17 14:43 ` Kim F. Storm
2004-05-18  0:13   ` Luc Teirlinck
2004-05-19  1:26     ` Richard Stallman
2004-05-19 12:11       ` Kim F. Storm
2004-05-19 19:32         ` Stefan Monnier
2004-05-19 22:33           ` Kim F. Storm
2004-05-20 13:17           ` Richard Stallman
2004-05-19 12:52       ` Kim F. Storm
2004-05-19 16:48         ` Stefan Monnier
2004-05-19 22:04           ` Kim F. Storm
2004-05-19 22:25             ` Stefan Monnier
2004-05-19 22:37               ` Kim F. Storm
2004-05-19 22:50                 ` Stefan Monnier
2004-05-20  0:44                   ` Kim F. Storm
2004-05-21 23:43                     ` Kim F. Storm
2004-05-23  1:14                       ` Stefan Monnier
2004-05-23 18:28                       ` Richard Stallman
2004-05-24 11:57                       ` Kim F. Storm
2004-05-28 21:51                       ` Stefan Monnier
2004-05-28 23:40                         ` Kim F. Storm
2004-05-28 23:49                           ` Stefan Monnier
2004-05-29 23:15                             ` Kim F. Storm
2004-05-30 20:44                               ` Stefan Monnier
2004-05-31 20:21                                 ` Kim F. Storm
2004-06-08 20:03                                   ` Lars Hansen
2004-05-20  7:08         ` Richard Stallman
2004-05-21 22:58           ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2004-05-13 23:34 Robert Anderson
2004-05-12 13:19 Kim F. Storm
2004-05-13 13:06 ` Kenichi Handa
2004-05-13 15:45 ` Richard Stallman

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.