From: Ralf Fassel <ralfixx@gmx.de>
Subject: core dump while in gnus
Date: Tue, 9 Apr 2002 20:16:08 +0200 (MDT) [thread overview]
Message-ID: <200204091816.g39IG7S113949@jupiter.akutech-local.de> (raw)
In GNU Emacs 21.2.1 (mips-sgi-irix6.5, X toolkit)
of 2002-04-05 on merkur
configured using `configure --prefix=/software/emacs/21.2 -exec-prefix=/software/emacs/21.2/IRIX-6 --with-pop --with-x-toolkit=athena'
Important settings:
value of $LC_ALL: C
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: nil
locale-coding-system: nil
default-enable-multibyte-characters: nil
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
while running Gnus, emacs dumps core quite often. GDB stack trace:
#0 0x101a3128 in mmap_realloc (var=0x10765808, nbytes=2125) at buffer.c:4516
#1 0x101a3750 in enlarge_buffer_text (b=0x10765800, delta=2104)
at buffer.c:4667
#2 0x101a8c10 in make_gap (nbytes_added=2104) at insdel.c:545
#3 0x101aa0e0 in insert_from_string_1 (string=815766308, pos=0, pos_byte=0,
nchars=124, nbytes=124, inherit=0, before_markers=1) at insdel.c:1050
#4 0x101a9ebc in insert_from_string_before_markers (string=815766308, pos=0,
pos_byte=0, length=124, length_byte=124, inherit=0) at insdel.c:1012
#5 0x10299180 in read_process_output (proc=1085325184, channel=4)
at process.c:3161
#6 0x10298208 in wait_reading_process_input (time_limit=-1, microsecs=0,
read_kbd=0, do_display=0) at process.c:2774
#7 0x102972fc in Faccept_process_output (process=1085325184, timeout=1,
timeout_msecs=273280004) at process.c:2301
#8 0x10230548 in Ffuncall (nargs=3, args=0x7fff18f0) at eval.c:2666
#9 0x1028e31c in Fbyte_code (bytestr=814417700, vector=1082850560, maxdepth=5)
at bytecode.c:716
#10 0x10231228 in funcall_lambda (fun=1078574976, nargs=1,
arg_vector=0x7fff1ae4) at eval.c:2851
#11 0x10230730 in Ffuncall (nargs=2, args=0x7fff1ae0) at eval.c:2707
#12 0x1028e31c in Fbyte_code (bytestr=814417044, vector=1082857472, maxdepth=8)
at bytecode.c:716
#13 0x10231228 in funcall_lambda (fun=1082823552, nargs=1,
arg_vector=0x7fff1cd4) at eval.c:2851
#14 0x10230730 in Ffuncall (nargs=2, args=0x7fff1cd0) at eval.c:2707
#15 0x1028e31c in Fbyte_code (bytestr=814408324, vector=1082851200, maxdepth=5)
at bytecode.c:716
#16 0x10231228 in funcall_lambda (fun=1082825056, nargs=2,
arg_vector=0x7fff1ec4) at eval.c:2851
#17 0x10230730 in Ffuncall (nargs=3, args=0x7fff1ec0) at eval.c:2707
#18 0x1028e31c in Fbyte_code (bytestr=814181380, vector=1081054208, maxdepth=4)
at bytecode.c:716
#19 0x10231228 in funcall_lambda (fun=1082366880, nargs=1,
arg_vector=0x7fff20a4) at eval.c:2851
#20 0x10230730 in Ffuncall (nargs=2, args=0x7fff20a0) at eval.c:2707
#21 0x1028e31c in Fbyte_code (bytestr=814174276, vector=1082505216, maxdepth=9)
at bytecode.c:716
#22 0x10231228 in funcall_lambda (fun=1082367264, nargs=1,
arg_vector=0x7fff22a4) at eval.c:2851
#23 0x10230730 in Ffuncall (nargs=2, args=0x7fff22a0) at eval.c:2707
#24 0x1028e31c in Fbyte_code (bytestr=814268516, vector=1082686848, maxdepth=3)
at bytecode.c:716
#25 0x10231228 in funcall_lambda (fun=1082683072, nargs=3,
arg_vector=0x7fff2484) at eval.c:2851
#26 0x10230730 in Ffuncall (nargs=4, args=0x7fff2480) at eval.c:2707
#27 0x1028e31c in Fbyte_code (bytestr=813374004, vector=1082130112, maxdepth=4)
at bytecode.c:716
#28 0x10231228 in funcall_lambda (fun=1082129760, nargs=1,
arg_vector=0x7fff2694) at eval.c:2851
#29 0x10230730 in Ffuncall (nargs=2, args=0x7fff2690) at eval.c:2707
#30 0x102288e8 in Fcall_interactively (function=273481356,
record_flag=273280004, keys=1078665216) at callint.c:797
#31 0x1017e628 in Fcommand_execute (cmd=273481356, record_flag=273280004,
keys=273280004, special=273280004) at keyboard.c:9221
#32 0x1016964c in command_loop_1 () at keyboard.c:1644
#33 0x1022c258 in internal_condition_case (bfun=0x10167b48 <command_loop_1>,
handlers=273402052, hfun=0x10167250 <cmd_error>) at eval.c:1267
#34 0x101677e8 in command_loop_2 () at keyboard.c:1245
#35 0x1022ba50 in internal_catch (tag=273354404,
func=0x101677a8 <command_loop_2>, arg=273280004) at eval.c:1030
#36 0x10167750 in command_loop () at keyboard.c:1224
#37 0x10166c9c in recursive_edit_1 () at keyboard.c:950
#38 0x10166f2c in Frecursive_edit () at keyboard.c:1006
#39 0x1016472c in main (argc=7, argv=0x7fff2e54, envp=0x7fff2e74)
at emacs.c:1547
(gdb) l
4511 result = mmap_alloc (var, nbytes);
4512 }
4513 else
4514 {
4515 struct mmap_region *r = MMAP_REGION (*var);
4516 size_t room = r->nbytes_mapped - MMAP_REGION_STRUCT_SIZE;
4517
4518 if (room < nbytes)
4519 {
4520 /* Must enlarge. */
(gdb) where 1
#0 0x101a3128 in mmap_realloc (var=0x10765808, nbytes=2125) at buffer.c:4516
(gdb) p r
$1 = (struct mmap_region *) 0x4060000
(gdb) p *r
Cannot access memory at address 0x4060000
(gdb) up
#1 0x101a3750 in enlarge_buffer_text (b=0x10765800, delta=2104)
at buffer.c:4667
4667 p = mmap_realloc ((POINTER_TYPE **) &b->text->beg, nbytes);
(gdb) p nbytes
$2 = 2125
(gdb) p b
$3 = (struct buffer *) 0x10765800
(gdb) p b->text
$4 = (struct buffer_text *) 0x10765808
(gdb) p b->text->beg
$5 = (unsigned char *) 0x4060018 <Address 0x4060018 out of bounds>
(gdb) up
#2 0x101a8c10 in make_gap (nbytes_added=2104) at insdel.c:545
545 enlarge_buffer_text (current_buffer, nbytes_added);
(gdb) p current_buffer
$6 = (struct buffer *) 0x10765800
(gdb) p *current_buffer
$7 = {
size = 537002092,
next = 0x10765200,
own_text = {
beg = 0x4060018 <Address 0x4060018 out of bounds>,
...
The buffer in question seems to always be the NNTP process buffer
" *server news.cis.dfn.de nntp *nntpd**"
where the process might have been disconnected due to a server
timeout. gdb is still running. so if anybody has some ideas...
R'
next reply other threads:[~2002-04-09 18:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-09 18:16 Ralf Fassel [this message]
2002-04-15 22:00 ` core dump while in gnus Richard Stallman
2002-04-16 6:19 ` Eli Zaretskii
2002-04-16 8:40 ` Ralf Fassel
2002-04-17 16:04 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200204091816.g39IG7S113949@jupiter.akutech-local.de \
--to=ralfixx@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.