Bug 5181

Summary: emacs dumps core on a .po file in po-mode
Product: [Retired] Red Hat Linux Reporter: Kjartan Maraas <kmaraas>
Component: emacsAssignee: Cristian Gafton <gafton>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-07-17 15:02:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
my .emacs file containing the necessary stuff for po-mode
none
po-file used to recreate the bug
none
po-mode.el file, goes into /usr/share/emacs/site-lisp/ none

Description Kjartan Maraas 1999-09-17 08:57:12 UTC
This is what happens when I try to remove a fuzzy mark in a
translation using emacs with po mode. This happens both in X
and on the console. Lorax 6.0.55.

(gdb) bt
#0  0x402134e1 in __kill () from /lib/libc.so.6
#1  0x8094be0 in abort ()
#2  0x80aea41 in abort ()
#3  0x80b1776 in abort ()
#4  0x80b1400 in abort ()
#5  0x80b1382 in abort ()
#6  0x80cebf6 in abort ()
#7  0x80ea34a in error ()
#8  0x80e8195 in re_compile_pattern ()
#9  0x80ea2b5 in error ()
#10 0x80e82fc in re_compile_pattern ()
#11 0x80e4c0b in re_compile_pattern ()
#12 0x80ea2b5 in error ()
#13 0x80e8195 in re_compile_pattern ()
#14 0x80ea2b5 in error ()
#15 0x80e82fc in re_compile_pattern ()
#16 0x80e8c35 in re_compile_pattern ()
#17 0x80ea2b5 in error ()
#18 0x80e82fc in re_compile_pattern ()
#19 0x80e1d8b in re_compile_pattern ()
#20 0x80ea2b5 in error ()
#21 0x80e82fc in re_compile_pattern ()
#22 0x80eb3d4 in error ()
---Type <return> to continue, or q <return> to quit---
#23 0x80eb1f4 in error ()
#24 0x80ea4a7 in error ()
#25 0x80e82fc in re_compile_pattern ()
#26 0x80e8209 in re_compile_pattern ()
#27 0x80ea2b5 in error ()
#28 0x80e82fc in re_compile_pattern ()
#29 0x80eb3d4 in error ()
#30 0x80eb05a in error ()
#31 0x80eaafd in error ()
#32 0x80e6cf0 in re_compile_pattern ()
#33 0x809f03f in abort ()
#34 0x8097af4 in abort ()
#35 0x80e939a in re_compile_pattern ()
#36 0x8096ea8 in abort ()
#37 0x80e8f72 in re_compile_pattern ()
#38 0x8096e5c in abort ()
#39 0x8096a68 in abort ()
#40 0x8096b67 in abort ()
#41 0x8095c19 in abort ()
#42 0x4020d1eb in __libc_start_main (main=0x80950d0
<abort+1280>, argc=1,
    argv=0xbffffb74, init=0x804c714 <_init>, fini=0x8125238
<_fini>,
    rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffffb6c)
    at ../sysdeps/generic/libc-start.c:90
(gdb)

Comment 1 Kjartan Maraas 1999-11-23 19:10:59 UTC
I have a patch from Gerd Moeller <gerd> that I haven't tested myself
because of the lack of a emacs src.rpm. 18 megs over one ISDN line does not
sound tempting. I'll test it tomorrow.

Cheers
Kjartan Maraas

------------patch-------------------

*** insdel.c	1999/11/23 13:58:04	1.1
--- insdel.c	1999/11/23 15:20:27
***************
*** 568,575 ****
  	    }
  	  else
  	    {
! 	      m->charpos += diff_chars;
! 	      m->bytepos += diff_bytes;
  	    }
  	}
        else if (m->bytepos >= from_byte)
--- 568,576 ----
  	    }
  	  else
  	    {
! 	      m->charpos = min (from + new_chars, m->charpos + diff_chars);
! 	      m->bytepos = min (from_byte + new_bytes,
! 				m->bytepos + diff_bytes);
  	    }
  	}
        else if (m->bytepos >= from_byte)

Comment 2 Kjartan Maraas 1999-11-23 19:21:59 UTC
Created attachment 13 [details]
my .emacs file containing the necessary stuff for po-mode

Comment 3 Kjartan Maraas 1999-11-23 19:23:59 UTC
Created attachment 14 [details]
po-file used to recreate the bug

Comment 4 Kjartan Maraas 1999-11-23 19:27:59 UTC
Created attachment 15 [details]
po-mode.el file, goes into /usr/share/emacs/site-lisp/

Comment 5 Kjartan Maraas 1999-11-24 22:21:59 UTC
I can confirm that the patch solves the problem for me

-Kjartan Maraas

Comment 6 Kjartan Maraas 2000-07-17 15:02:42 UTC
Shouldn't this bug be closed soon?

Kjartan