GNU bug report logs - #4879
Crash in xmenu_show

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4879 in the body.
You can then email your comments to 4879 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Crash in xmenu_show
Date: Fri, 06 Nov 2009 12:49:21 +0200

In a non-toolkit X build GNU Emacs 23.1.50 (x86_64-pc-linux-gnu)
steps to reproduce the crash:

1. emacs -Q
2. Type `C-x C-f'
3. Click on the `Minibuf' top-level menu.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f146c4497a0 (LWP 31459)]
0x000000000047028f in xmenu_show (f=0x11abbb0, x=383, y=10, for_click=1,
        keymaps=1, title=10721059, error=0x7fff74478630) at xmenu.c:2738
2738                  bcopy (SDATA (item_name), item_data,

I've tracked and narrowed the cause of this crash to a change
between 2009-09-10 and 2009-09-11.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Message #10 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>, 4879 <at> debbugs.gnu.org
Subject: Re: bug#4879: Crash in xmenu_show
Date: Fri, 06 Nov 2009 13:50:37 +0200

> From: Juri Linkov <juri <at> jurta.org>
> Date: Fri, 06 Nov 2009 12:49:21 +0200
> Cc: 
> 
> In a non-toolkit X build GNU Emacs 23.1.50 (x86_64-pc-linux-gnu)

What does it mean, exactly?  Why didn't you send the report using "M-x
report-emacs-bug RET", where all this information is automatically
included?

FWIW, I cannot reproduce this neither in the MS-DOS build (which
should generally work like a non-toolkit build on Unix), nor in the
MS-Windows build, both from today's CVS.

Message #15 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>, 4879 <at> debbugs.gnu.org
Cc: Juri Linkov <juri <at> jurta.org>
Subject: Re: bug#4879: Crash in xmenu_show
Date: Fri, 06 Nov 2009 16:11:01 +0100

Eli Zaretskii skrev:
>> From: Juri Linkov <juri <at> jurta.org>
>> Date: Fri, 06 Nov 2009 12:49:21 +0200
>> Cc: 
>>
>> In a non-toolkit X build GNU Emacs 23.1.50 (x86_64-pc-linux-gnu)
> 
> What does it mean, exactly?  Why didn't you send the report using "M-x
> report-emacs-bug RET", where all this information is automatically
> included?
> 
> FWIW, I cannot reproduce this neither in the MS-DOS build (which
> should generally work like a non-toolkit build on Unix), nor in the
> MS-Windows build, both from today's CVS.
> 
> 

I can't reproduce it either, on x86_64-pc-linux-gnu, --with-x-toolkit=no

	Jan D.

Message #20 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 4879 <at> debbugs.gnu.org
Subject: Re: bug#4879: Crash in xmenu_show
Date: Fri, 06 Nov 2009 23:10:27 +0200

> What does it mean, exactly?  Why didn't you send the report using "M-x
> report-emacs-bug RET", where all this information is automatically
> included?

`M-x report-emacs-bug RET' includes irrelevant information - the date
it inserts in the version string is the date of compilation that
provides no help to reproduce the bug.  Is it possible to replace it
with the date of the last CVS checkout/update that says exactly what
state of the code repository contains the bug?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Message #25 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 4879 <at> debbugs.gnu.org
Subject: Re: bug#4879: Crash in xmenu_show
Date: Fri, 06 Nov 2009 23:06:23 +0200

> I can't reproduce it either, on x86_64-pc-linux-gnu, --with-x-toolkit=no

Sorry, I thought it will be easy to reproduce, but since it's not,
I include maximum information below.

1. Test case 1
1.1. mkdir cvs20090910
1.2. cd cvs20090910
1.3. cvs -z3 -d:pserver:anonymous <at> cvs.sv.gnu.org:/sources/emacs co -D 2009-09-10 emacs
1.4. cd emacs
1.5. ./configure --with-x-toolkit=no CFLAGS="-g3 -O0 -Wno-pointer-sign -fno-inline -fno-crossjumping"
1.6. make -j3 bootstrap
1.7. cd src
1.8. ./emacs -Q
1.9. Type `C-x C-f'
1.10. Click on the top-level menu "Minibuf"
1.11. No crash

2. Test case 2
2.1. mkdir cvs20090911
2.2. cd cvs20090911
2.3. cvs -z3 -d:pserver:anonymous <at> cvs.sv.gnu.org:/sources/emacs co -D 2009-09-11 emacs
2.4. cd emacs
2.5. ./configure --with-x-toolkit=no CFLAGS="-g3 -O0 -Wno-pointer-sign -fno-inline -fno-crossjumping"
2.6. make -j3 bootstrap
2.7. cd src
2.8. ./emacs -Q
2.9. Type `C-x C-f'
2.10. Click on the top-level menu "Minibuf"
2.11. Crash with the backtrace below

In GNU Emacs 23.1.50.1 (x86_64-unknown-linux-gnu) of 2009-09-11 (CVS date)
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
configured using `configure  '--with-x-toolkit=no' 'CFLAGS=-g3 -O0 -Wno-pointer-sign -fno-inline -fno-crossjumping''

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: en_DK.utf8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=SCIM
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Configured for `x86_64-unknown-linux-gnu'.
  What operating system and machine description files should Emacs use?
        `s/gnu-linux.h' and `m/amdx86-64.h'
  What compiler should emacs be built with?               gcc -g3 -O0 -Wno-pointer-sign -fno-inline -fno-crossjumping
  Should Emacs use the GNU version of malloc?             yes
      (Using Doug Lea's new malloc from the GNU C Library.)
  Should Emacs use a relocating allocator for buffers?    yes
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          none
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use -lpng?                                   yes
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use -lgpm?                                   yes
  Does Emacs use -ldbus?                                  yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   yes
  Does Emacs use toolkit scroll bars?                     no

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb3746be7a0 (LWP 19530)]
0x00000000004701c7 in xmenu_show (f=0x11c46e0, x=227, y=29, for_click=1, keymaps=1, title=12708355, error=0x7fff7c6ed8c0) at xmenu.c:2735
2735                  bcopy (SDATA (item_name), item_data,
(gdb) bt full
#0  0x00000000004701c7 in xmenu_show (f=0x11c46e0, x=227, y=29, for_click=1, keymaps=1, title=12708355, error=0x7fff7c6ed8c0) at xmenu.c:2735
        gap = 19
        item_name = 12452995
        help_string = 0x1074da0 "Terminate input and exit minibuffer"
        enable = 11890497
        descrip = 13638049
        help = 12458691
        item_data = (unsigned char *) 0x7fff7bda3920 <Address 0x7fff7bda3920 out of bounds>
        root = 315
        menu = (XMenu *) 0x12879b0
        pane = 0
        selidx = 17331797
        lpane = 0
        status = 2087639072
        entry = 141733920778
        pane_prefix = 11890401
        datap = 0xb56ee1 ""
        ulx = 1
        uly = 0
        width = 4
        height = 2087639040
        dispwidth = 0
        dispheight = 4645596
        i = 59
        j = 24
        lines = 7
        maxlines = 0
        maxwidth = 24
        dummy_int = 0
        dummy_uint = 24
        specpdl_count = 33
#1  0x000000000046f2fa in Fx_popup_menu (position=17488549, menu=17488613) at xmenu.c:505
        keymap = 17331781
        tem = 11890401
        xpos = 223
        ypos = 4
        title = 12708355
        error_name = 0x0
        selection = 11890401
        f = (FRAME_PTR) 0x11c46e0
        x = 1784
        y = 32
        window = 18630372
        keymaps = 1
        for_click = 1
        specpdl_count = 33
        gcpro1 = {
  next = 0x100000001,
  var = 0x800000006,
  nvars = 2
}
#2  0x000000000054f57e in read_char_x_menu_prompt (nmaps=2, maps=0x7fff7c6edd90, prev_event=17488549, used_mouse_menu=0x7fff7c6ee1d8) at keyboard.c:8613
        realmaps = (Lisp_Object *) 0x7fff7c6ed930
        value = 140408669737242
        nmaps1 = 1
        mapno = 2
        name = 12708355
#3  0x00000000005444e6 in read_char (commandflag=1, nmaps=2, maps=0x7fff7c6edd90, prev_event=17488549, used_mouse_menu=0x7fff7c6ee1d8, end_time=0x0) at keyboard.c:2912
        c = 11890401
        count = 0
        jmpcount = 33
        local_getcjmp = {{
    __jmpbuf = {11890401, 4079779853910592874, 0, 140735281040048, 0, 0, 4079779853793152362, -4080065152552612502},
    __mask_was_saved = 0,
    __saved_mask = {
      __val = {11890401, 0, 17331909, 140735281028000, 5549673, 11890401, 16403009, 17332117, 17332021, 140735281028256, 5608643, 16403009, 11890401, 4311370305,
        4294967296, 16403009}
    }
  }}
        save_jump = {{
    __jmpbuf = {0, 11890401, 140735281027744, 5607104, 0, 17332117, 16403009, 17332085},
    __mask_was_saved = 0,
    __saved_mask = {
      __val = {16403009, 11890401, 11890401, 140735281028000, 5608401, 16403009, 17332117, 0, 11890401, 11951393, 17331989, 17331957, 11890401, 140735281027856,
        6236616, 11951393}
    }
  }}
        key_already_recorded = 0
        tem = 140735281028432
        save = 5572172
        previous_echo_area_message = 11890401
        also_record = 11890401
        reread = 0
        gcpro1 = {
  next = 0xfa4a41,
  var = 0x1087625,
  nvars = 13463754
}
        gcpro2 = {
  next = 0xfa4a41,
  var = 0x1087645,
  nvars = 11890401
}
        polling_stopped_here = 0
        orig_kboard = (struct kboard *) 0xe70660
#4  0x0000000000551030 in read_key_sequence (keybuf=0x7fff7c6ee380, bufsize=30, prompt=11890401, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1)
    at keyboard.c:9464
        interrupted_kboard = (KBOARD *) 0xe70660
        interrupted_frame = (struct frame *) 0x11c46e0
        key = 17488549
        used_mouse_menu = 0
        echo_local_start = 0
        last_real_key_start = 2
        keys_local_start = 2
        local_first_binding = 0
        from_string = 11890401
        count = 33
        t = 2
        echo_start = 0
        keys_start = 0
        nmaps = 2
        nmaps_allocated = 2
        defs = (Lisp_Object * volatile) 0x7fff7c6edd70
        submaps = (Lisp_Object * volatile) 0x7fff7c6edd90
        orig_local_map = 11883477
        orig_keymap = 11890401
        localized_local_map = 0
        first_binding = 0
        first_unbound = 31
        mock_input = 0
        fkey = {
  parent = 16696629,
  map = 16696629,
  start = 2,
  end = 2
}
        keytran = {
  parent = 11882261,
  map = 11882261,
  start = 2,
  end = 2
}
        indec = {
  parent = 16696661,
  map = 16696661,
  start = 2,
  end = 2
}
        shift_translated = 0
        delayed_switch_frame = 11890401
        original_uppercase = 12110258
        original_uppercase_position = -1
        dummyflag = 0
        starting_buffer = (struct buffer *) 0x1256f20
        fake_prefixed_keys = 11890401
        gcpro1 = {
  next = 0x7fff7c6ee090,
  var = 0x5e8fe5,
  nvars = 12112401
}
#5  0x0000000000540d6b in command_loop_1 () at keyboard.c:1640
        cmd = 6198825
        lose = 0
        keybuf = {11944033, 17488549, 140735281029856, 4294967299, 39, 140735281029856, 140733193388035, 6703026, 167503724555, 12455656, 140735281030144, 6666026,
  12455656, 12455656, 19230500, 4307422952, 140735281029856, 11890401, 24, 11890401, 11890401, 137452549393, 16841589, 11890449, 0, 16841589, 11890401, 11890401,
  19251018, 17625633}
        i = 9967300
        prev_modiff = 0
        prev_buffer = (struct buffer *) 0x0
        already_adjusted = 0
#6  0x00000000005e5f96 in internal_condition_case (bfun=0x5409d8 <command_loop_1>, handlers=11977489, hfun=0x540309 <cmd_error>) at eval.c:1513
        val = 6200100
        c = {
  tag = 11890401,
  val = 11890401,
  next = 0x7fff7c6ee680,
  gcpro = 0x0,
  jmp = {{
      __jmpbuf = {11890401, 4079779853136743786, 0, 140735281040048, 0, 0, 4079779853090606442, -4080065238502552214},
      __mask_was_saved = 0,
      __saved_mask = {
        __val = {0, 8601824993, 11890401, 17464005, 11977297, 13595969, 9967300, 12455656, 7400927115773751296, 12195578, 11890401, 140735281030784, 6194157, 408,
          11890401, 11890401}
      }
    }},
  backlist = 0x7fff7c6eeb30,
  handlerlist = 0x7fff7c6f0430,
  lisp_eval_depth = 5,
  pdlcount = 33,
  poll_suppress_count = 1,
  interrupt_input_blocked = 0,
  byte_stack = 0x7fff7c6eecf0
}
        h = {
  handler = 11977489,
  var = 11890401,
  chosen_clause = 0,
  tag = 0x7fff7c6ee500,
  next = 0x7fff7c6f0430
}
#7  0x00000000005406f7 in command_loop_2 () at keyboard.c:1357
        val = 5
#8  0x00000000005e5972 in internal_catch (tag=12111553, func=0x5406dd <command_loop_2>, arg=11890401) at eval.c:1249
        c = {
  tag = 12111553,
  val = 11890401,
  next = 0x7fff7c6f0320,
  gcpro = 0x0,
  jmp = {{
      __jmpbuf = {11890401, 4079779853197561194, 0, 140735281040048, 0, 0, 4079779853140938090, -4080065238711349910},
      __mask_was_saved = 0,
      __saved_mask = {
        __val = {11890401, 140735281031024, 6081208, 140735281031104, 11890401, 12312177, 11890401, 10677577672, 12295274, 12295274, 12295274, 140735281031024,
          6079639, 4307079697, 19230496, 12295274}
      }
    }},
  backlist = 0x7fff7c6eeb30,
  handlerlist = 0x7fff7c6f0430,
  lisp_eval_depth = 5,
  pdlcount = 33,
  poll_suppress_count = 1,
  interrupt_input_blocked = 0,
  byte_stack = 0x7fff7c6eecf0
}
#9  0x0000000000540665 in command_loop () at keyboard.c:1322
        val = 11890401
#10 0x000000000053fe4f in recursive_edit_1 () at keyboard.c:951
        count = 32
        val = 12196513
#11 0x000000000057e116 in read_minibuf (map=11883477, initial=12703987, prompt=9576827, backup_n=0, expflag=0, histvar=11993441, histpos=0, defalt=12779427,
    allow_props=0, inherit_input_method=0) at minibuf.c:739
        val = 11890401
        count = 25
        mini_frame = 18630372
        ambient_dir = 12779427
        minibuffer = 19230500
        input_method = 11890401
        gcpro1 = {
  next = 0x7fff7c6ee950,
  var = 0x5ccab8,
  nvars = 0
}
        gcpro2 = {
  next = 0xb43670,
  var = 0x0,
  nvars = 19022128
}
        gcpro3 = {
  next = 0x10000ffffffff,
  var = 0x1,
  nvars = 2087643376
}
        gcpro4 = {
  next = 0xba2dda,
  var = 0x27,
  nvars = 11930576
}
        gcpro5 = {
  next = 0x7fff7c6f0ab0,
  var = 0x0,
  nvars = 19022128
}
        enable_multibyte = 11890401
        pos = 0
        histstring = 12198865
        empty_minibuf = 12088996
        dummy = 11890401
        frame = 18630372
#12 0x00000000005804b5 in Fcompleting_read (prompt=9576827, collection=12198721, predicate=11890401, require_match=13184625, initial_input=12703987, hist=11993441,
    def=12779427, inherit_input_method=11890401) at minibuf.c:1823
        val = 2
        histvar = 11993441
        histpos = 0
        position = 11890401
        init = 12703987
        pos = 0
        count = 22
        gcpro1 = {
  next = 0x10a7ac5,
  var = 0xc040e1,
  nvars = 17464005
}
#13 0x00000000005e8f90 in Ffuncall (nargs=8, args=0x7fff7c6eebb0) at eval.c:3077
        fun = 9261604
        original_fun = 12203345
        funcar = 2
        numargs = 7
        lisp_numargs = 11977297
        val = 17464005
        backtrace = {
  next = 0x7fff7c6ef080,
  function = 0x7fff7c6eebb0,
  args = 0x7fff7c6eebb8,
  nargs = 7,
  evalargs = 0 '\0',
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0x7fff7c6eeab0
        i = 8
#14 0x000000000063cbff in Fbyte_code (bytestr=9748715, vector=9748748, maxdepth=72) at bytecode.c:678
        count = 14
        op = 7
        vectorp = (Lisp_Object *) 0x94c118
        bytestr_length = 416
        stack = {
  pc = 0xab4d40 "+\202\377",
  top = 0x7fff7c6eebe8,
  bottom = 0x7fff7c6eebb0,
  byte_string = 9748715,
  byte_string_start = 0xab4c8a "\b\204\006",
  constants = 9748748,
  next = 0x7fff7c6ef220
}
        top = (Lisp_Object *) 0x7fff7c6eebb0
        result = 12569873
#15 0x00000000005e9619 in funcall_lambda (fun=9748548, nargs=4, arg_vector=0x7fff7c6ef108) at eval.c:3233
        val = 17463573
        syms_left = 11890401
        next = 12569873
        count = 8
        i = 4
        optional = 1
        rest = 0
#16 0x00000000005e8fe5 in Ffuncall (nargs=5, args=0x7fff7c6ef100) at eval.c:3092
        fun = 9748548
        original_fun = 12751457
        funcar = 12141633
        numargs = 4
        lisp_numargs = 12140650
        val = 12140650
        backtrace = {
  next = 0x7fff7c6ef5b0,
  function = 0x7fff7c6ef100,
  args = 0x7fff7c6ef108,
  nargs = 4,
  evalargs = 0 '\0',
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0x0
        i = 0
#17 0x000000000063cbff in Fbyte_code (bytestr=9576115, vector=9576148, maxdepth=40) at bytecode.c:678
        count = 5
        op = 4
        vectorp = (Lisp_Object *) 0x921ee0
        bytestr_length = 29
        stack = {
  pc = 0xac0d8a "+\315D\207",
  top = 0x7fff7c6ef120,
  bottom = 0x7fff7c6ef100,
  byte_string = 9576115,
  byte_string_start = 0xac0d71 "\b\205\a",
  constants = 9576148,
  next = 0x7fff7c6ef740
}
        top = (Lisp_Object *) 0x7fff7c6ef100
        result = 12791377
#18 0x00000000005e9619 in funcall_lambda (fun=9576036, nargs=2, arg_vector=0x7fff7c6ef638) at eval.c:3233
        val = 13184625
        syms_left = 11890401
        next = 12791377
        count = 3
        i = 2
        optional = 0
        rest = 0
#19 0x00000000005e8fe5 in Ffuncall (nargs=3, args=0x7fff7c6ef630) at eval.c:3092
        fun = 9576036
        original_fun = 12789473
        funcar = 429675
        numargs = 2
        lisp_numargs = 0
        val = 13184625
        backtrace = {
  next = 0x7fff7c6efab0,
  function = 0x7fff7c6ef630,
  args = 0x7fff7c6ef638,
  nargs = 2,
  evalargs = 0 '\0',
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0xb8d211
        i = 0
#20 0x000000000063cbff in Fbyte_code (bytestr=9576739, vector=9576788, maxdepth=24) at bytecode.c:678
        count = 3
        op = 2
        vectorp = (Lisp_Object *) 0x922160
        bytestr_length = 6
        stack = {
  pc = 0xac0d38 "\207",
  top = 0x7fff7c6ef640,
  bottom = 0x7fff7c6ef630,
  byte_string = 9576739,
  byte_string_start = 0xac0d33 "\300\301\302 \"\207",
  constants = 9576788,
  next = 0x0
}
        top = (Lisp_Object *) 0x7fff7c6ef630
        result = 48
#21 0x00000000005e7a7d in Feval (form=9576709) at eval.c:2383
        numargs = 24
        args_left = 11890401
        i = 3
        maxargs = 3
        argvals = {9576739, 9576788, 24, 140408729115968, 140408729141248, 4222941, 140408669220824, 4210752}
        fun = 11418084
        val = 11890401
        original_fun = 12151281
        original_args = 9576725
        funcar = 12151761
        backtrace = {
  next = 0x7fff7c6efed0,
  function = 0x7fff7c6efb60,
  args = 0x7fff7c6efa70,
  nargs = 3,
  evalargs = 1 '\001',
  debug_on_exit = 0 '\0'
}
        gcpro1 = {
  next = 0x7fff7c6efb90,
  var = 0x5cba25,
  nvars = 1
}
        gcpro2 = {
  next = 0x7fff7c6efb10,
  var = 0x5c44f6,
  nvars = 9576709
}
        gcpro3 = {
  next = 0x10a7905,
  var = 0x7fff7c6efa70,
  nvars = 3
}
#22 0x00000000005e1bc6 in Fcall_interactively (function=12751553, record_flag=11890401, keys=11957412) at callint.c:364
        input = 9576709
        args = (Lisp_Object *) 0x0
        visargs = (Lisp_Object *) 0x0
        specs = 9576709
        filter_specs = 9576709
        teml = 0
        up_event = 11890401
        enable = 11890401
        speccount = 3
        next_event = 5549556
        prefix_arg = 11890401
        string = (unsigned char *) 0x0
        tem = (unsigned char *) 0x0
        varies = (int *) 0x0
        i = 2
        j = 0
        count = 0
        foo = 8192
        prompt1 = "AF\266\000\000\000\000\000\371\252T\000\000\000\000\000AF\266\000\000\000\000\000\340\t\017q\263\177\000\000@", '\0' <repeats 15 times>, "\260\no|\377\177\000\000\333\346\177|\377\177\000\000\000\000\000\000\000\000\000\000\270\242\022\001", '\0' <repeats 12 times>, "\214\347\177|\377\177\000\000\000\000\000"
        tem1 = 0x0
        arg_from_tty = 0
        gcpro1 = {
  next = 0x0,
  var = 0x7fb3746f1000,
  nvars = 455
}
        gcpro2 = {
  next = 0x0,
  var = 0x7fff7c6efd00,
  nvars = 0
}
        gcpro3 = {
  next = 0x7fff7c6efd40,
  var = 0x7fb3744e8e32,
  nvars = 999992
}
        gcpro4 = {
  next = 0x40,
  var = 0x5e83ed,
  nvars = 1893315608
}
        gcpro5 = {
  next = 0x0,
  var = 0x7fb3744e2c76,
  nvars = 1
}
        key_count = 2
        record_then_fail = 0
        save_this_command = 12751553
        save_last_command = 11890401
        save_this_original_command = 12751553
        save_real_this_command = 12751553
#23 0x00000000005e8d3b in Ffuncall (nargs=4, args=0x7fff7c6eff70) at eval.c:3052
        fun = 11405580
        original_fun = 12151665
        funcar = 0
        numargs = 3
        lisp_numargs = 0
        val = 0
        backtrace = {
  next = 0x0,
  function = 0x7fff7c6eff70,
  args = 0x7fff7c6eff78,
  nargs = 3,
  evalargs = 0 '\0',
  debug_on_exit = 0 '\0'
}
        internal_args = (Lisp_Object *) 0x7fff7c6eff78
        i = 0
#24 0x00000000005e8714 in call3 (fn=12151665, arg1=12751553, arg2=11890401, arg3=11890401) at eval.c:2872
        ret_ungc_val = 9576492
        gcpro1 = {
  next = 0x92202c,
  var = 0xb56ee1,
  nvars = 4
}
        args = {12151665, 12751553, 11890401, 11890401}
#25 0x0000000000553e2b in Fcommand_execute (cmd=12751553, record_flag=11890401, keys=11890401, special=11890401) at keyboard.c:10453
        final = 9576492
        tem = 11890401
        prefixarg = 11890401
#26 0x000000000054267e in command_loop_1 () at keyboard.c:1901
        scount = 2
        cmd = 12751553
        lose = 0
        keybuf = {192, 48, 24, 13158437, 2822930839, 140408727136892, 4327615, 140408669165772, 140735281038216, 100677544720, 44108294, 140735281037840, 0,
  140735281038000, 140735281037488, 0, 140408729141248, 4223151, 140408669220824, 4210512, 4294967296, 4294968226, 276967387, 140408729310040, 140735281038304,
  140735281038224, 2822930839, 140735281038248, 140408729115968, 140408727137423}
        i = 2
        prev_modiff = 10
        prev_buffer = (struct buffer *) 0xb60bd0
        already_adjusted = 0
#27 0x00000000005e5f96 in internal_condition_case (bfun=0x5409d8 <command_loop_1>, handlers=11977489, hfun=0x540309 <cmd_error>) at eval.c:1513
        val = 12478693
        c = {
  tag = 11890401,
  val = 11890401,
  next = 0x7fff7c6f04a0,
  gcpro = 0x0,
  jmp = {{
      __jmpbuf = {140408729316352, 4079779860590021994, 0, 140735281040048, 0, 0, 4079779860560661866, -4080065238502552214},
      __mask_was_saved = 0,
      __saved_mask = {
        __val = {0, 140408669192768, 140408729141248, 0, 4294967295, 0, 9220952, 0, 140735281040048, 0, 0, 0, 140408727153782, 140733193388033, 0, 4312547443}
      }
    }},
  backlist = 0x0,
  handlerlist = 0x0,
  lisp_eval_depth = 0,
  pdlcount = 2,
  poll_suppress_count = 1,
  interrupt_input_blocked = 0,
  byte_stack = 0x0
}
        h = {
  handler = 11977489,
  var = 11890401,
  chosen_clause = 12673136,
  tag = 0x7fff7c6f0320,
  next = 0x0
}
#28 0x00000000005406f7 in command_loop_2 () at keyboard.c:1357
        val = 5
#29 0x00000000005e5972 in internal_catch (tag=11958881, func=0x5406dd <command_loop_2>, arg=11890401) at eval.c:1249
        c = {
  tag = 11958881,
  val = 11890401,
  next = 0x0,
  gcpro = 0x0,
  jmp = {{
      __jmpbuf = {140408729316352, 4079779860650839402, 0, 140735281040048, 0, 0, 4079779860610993514, -4080065238711349910},
      __mask_was_saved = 0,
      __saved_mask = {
        __val = {18, 140735281038736, 6081208, 140735281038704, 11890401, 12312177, 11890401, 8589934936, 12295274, 12295274, 12295274, 140735281038736, 6079639,
          4307055736, 11930576, 12295274}
      }
    }},
  backlist = 0x0,
  handlerlist = 0x0,
  lisp_eval_depth = 0,
  pdlcount = 2,
  poll_suppress_count = 1,
  interrupt_input_blocked = 0,
  byte_stack = 0x0
}
#30 0x00000000005406b1 in command_loop () at keyboard.c:1336
No locals.
#31 0x000000000053fe4f in recursive_edit_1 () at keyboard.c:951
        count = 1
        val = 11890401
#32 0x000000000053fff2 in Frecursive_edit () at keyboard.c:1013
        count = 0
        buffer = 11890401
#33 0x000000000053e465 in main (argc=2, argv=0x7fff7c6f0ab8) at emacs.c:1849
        dummy = 4240569
        stack_bottom_variable = 0 '\0'
        do_initial_setlocale = 1
        skip_args = 0
        rlim = {
  rlim_cur = 8720000,
  rlim_max = 18446744073709551615
}
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0

Lisp Backtrace:
"completing-read" (0x7c6eebb8)
"read-file-name" (0x7c6ef108)
"find-file-read-args" (0x7c6ef638)
"byte-code" (0x7c6efa70)
"call-interactively" (0x7c6eff78)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Message #30 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier  <monnier <at> iro.umontreal.ca>
Cc: 4879 <at> debbugs.gnu.org
Subject: Re: bug#4879: Crash in xmenu_show
Date: Fri, 06 Nov 2009 19:17:41 -0500

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fb3746be7a0 (LWP 19530)]
> 0x00000000004701c7 in xmenu_show (f=0x11c46e0, x=227, y=29, for_click=1, keymaps=1, title=12708355, error=0x7fff7c6ed8c0) at xmenu.c:2735
> 2735                  bcopy (SDATA (item_name), item_data,

The problem is that

   XVECTOR (menu_items)->contents[i + MENU_ITEMS_ITEM_EQUIV_KEY];

is now a symbol, but the code (here and in a couple of other places in
xmenu.c, and maybe elsewhere) assumes that it's a string or nil.

It's simple to "fix" by adding an additional check for symbols as menu
descriptors, but we need to understand why the situation has changed.

Stefan, I'm 99% sure this was caused by your keymap changes around
2009-09-11.  Could you please debug them?

Message #35 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 4879 <at> debbugs.gnu.org
Subject: Re: bug#4879: Crash in xmenu_show
Date: Sat, 07 Nov 2009 11:03:28 +0200

> From: Juri Linkov <juri <at> jurta.org>
> Cc: 4879 <at> emacsbugs.donarmstrong.com
> Date: Fri, 06 Nov 2009 23:10:27 +0200
> 
> > What does it mean, exactly?  Why didn't you send the report using "M-x
> > report-emacs-bug RET", where all this information is automatically
> > included?
> 
> `M-x report-emacs-bug RET' includes irrelevant information

OTOH, it includes some very relevant one - the exact way you
configured Emacs for the build, and the language environment in which
you invoked Emacs.  These are there for a reason, and if you don't
want to send the whole report for some reason, at least send these
parts of it.  How can we possibly educate users to use this facility
if the developers themselves don't?

> the date
> it inserts in the version string is the date of compilation that
> provides no help to reproduce the bug.  Is it possible to replace it
> with the date of the last CVS checkout/update that says exactly what
> state of the code repository contains the bug?

Everything's possible -- this is software.  You could write code that
looks in the ChangeLog files for the latest log entries in src/,
lisp/, and leim/, for example.  Or the code could look at the time
stamp of some CVS/Template file (in any directory) -- but this needs
to be changed for those who use VCs other than CVS, and for everybody
when we switch to bzr.

Personally, I never build without "cvs update", so the build time is
almost exactly the checkout time.

Message #40 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Juri Linkov <juri <at> jurta.org>,
        Jan Djärv
 <jan.h.d <at> swipnet.se>,
        4879 <at> debbugs.gnu.org
Subject: Re: bug#4879: Crash in xmenu_show
Date: Sat, 07 Nov 2009 22:43:01 -0500

>>>>> "Chong" == Chong Yidong <cyd <at> stupidchicken.com> writes:

>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x7fb3746be7a0 (LWP 19530)]
>> 0x00000000004701c7 in xmenu_show (f=0x11c46e0, x=227, y=29, for_click=1, keymaps=1, title=12708355, error=0x7fff7c6ed8c0) at xmenu.c:2735
>> 2735                  bcopy (SDATA (item_name), item_data,

> The problem is that

>    XVECTOR (menu_items)->contents[i + MENU_ITEMS_ITEM_EQUIV_KEY];

> is now a symbol, but the code (here and in a couple of other places in
> xmenu.c, and maybe elsewhere) assumes that it's a string or nil.

> It's simple to "fix" by adding an additional check for symbols as menu
> descriptors, but we need to understand why the situation has changed.

> Stefan, I'm 99% sure this was caused by your keymap changes around
> 2009-09-11.  Could you please debug them?

Hmm... not sure how it relates, but I see one possible trouble spot.
Does the patch below help?


        Stefan


--- keyboard.c.~1.1016.~	2009-10-24 22:39:01.000000000 -0400
+++ keyboard.c	2009-11-07 22:41:50.000000000 -0500
@@ -8118,6 +8118,8 @@
 	  tem = concat2 (build_string ("  "), tem);
 	  /* tem = concat3 (build_string ("  ("), tem, build_string (")")); */
 	}
+      else
+	tem = Qnil;
     }
   
 

Message #45 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Juri Linkov <juri <at> jurta.org>,
        Jan Djärv
 <jan.h.d <at> swipnet.se>,
        4879 <at> debbugs.gnu.org
Subject: Re: bug#4879: Crash in xmenu_show
Date: Sun, 08 Nov 2009 00:02:14 -0500

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> Hmm... not sure how it relates, but I see one possible trouble spot.
> Does the patch below help?

It eliminates the bug, yes.  Thanks.

(BTW, you left some trailing whitespace when you last changed this part
of the code.)

Message #50 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Juri Linkov <juri <at> jurta.org>,
        Jan Djärv
 <jan.h.d <at> swipnet.se>,
        4879 <at> debbugs.gnu.org
Subject: Re: bug#4879: Crash in xmenu_show
Date: Sun, 08 Nov 2009 10:07:50 -0500

>> Hmm... not sure how it relates, but I see one possible trouble spot.
>> Does the patch below help?
> It eliminates the bug, yes.  Thanks.

I installed a cosmetically different fix,


        Stefan

Message #57 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Chong Yidong <cyd <at> stupidchicken.com>,
        Jan Djärv
 <jan.h.d <at> swipnet.se>,
        4879 <at> debbugs.gnu.org
Subject: Re: bug#4879: Crash in xmenu_show
Date: Mon, 09 Nov 2009 02:49:37 +0200

>>> Hmm... not sure how it relates, but I see one possible trouble spot.
>>> Does the patch below help?
>> It eliminates the bug, yes.  Thanks.
>
> I installed a cosmetically different fix,

Thanks, it helped.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Message #62 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#4879: Crash in xmenu_show
Date: Wed, 11 Nov 2009 08:11:46 -0700

Eli Zaretskii wrote:
>> From: Juri Linkov <juri <at> jurta.org>
>> Cc: 4879 <at> emacsbugs.donarmstrong.com
>> Date: Fri, 06 Nov 2009 23:10:27 +0200
...
>> the date
>> it inserts in the version string is the date of compilation that
>> provides no help to reproduce the bug.  Is it possible to replace it
>> with the date of the last CVS checkout/update that says exactly what
>> state of the code repository contains the bug?
> 
> Everything's possible -- this is software.  You could write code that
> looks in the ChangeLog files for the latest log entries in src/,
> lisp/, and leim/, for example.  Or the code could look at the time
> stamp of some CVS/Template file (in any directory) -- but this needs
> to be changed for those who use VCs other than CVS, and for everybody
> when we switch to bzr.
> 
> Personally, I never build without "cvs update", so the build time is
> almost exactly the checkout time.

3rd party distributions may not use the same procedure as you, and they seem
to generate a fair number of bug reports.

-- 
Kevin Rodgers
Denver, Colorado, USA

Message #67 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 4879 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#4879: Crash in xmenu_show
Date: Wed, 11 Nov 2009 11:39:57 -0500

> Is it possible to replace it with the date of the last CVS
> checkout/update that says exactly what state of the code repository
> contains the bug?

Patches welcome (but they should also work for Bzr checkouts and
probably Git checkouts as well, and for the code not to suck that
basically means it should be VCS-agnostic).


        Stefan

Message #70 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 4879 <at> debbugs.gnu.org, Juri Linkov <juri <at> jurta.org>
Subject: Re: bug#4879: Crash in xmenu_show
Date: Fri, 13 Nov 2009 23:39:20 -0500

Stefan Monnier wrote:

>> Is it possible to replace it with the date of the last CVS
>> checkout/update that says exactly what state of the code repository
>> contains the bug?
>
> Patches welcome (but they should also work for Bzr checkouts and
> probably Git checkouts as well, and for the code not to suck that
> basically means it should be VCS-agnostic).

Have a file in the repository that is automatically committed (eg via
cron) on a periodic basis with just a date-stamp?

Message #75 received at 4879 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 4879 <at> debbugs.gnu.org, Juri Linkov <juri <at> jurta.org>
Subject: Re: bug#4879: Crash in xmenu_show
Date: Sat, 14 Nov 2009 02:10:52 -0500

>>> Is it possible to replace it with the date of the last CVS
>>> checkout/update that says exactly what state of the code repository
>>> contains the bug?
>> Patches welcome (but they should also work for Bzr checkouts and
>> probably Git checkouts as well, and for the code not to suck that
>> basically means it should be VCS-agnostic).
> Have a file in the repository that is automatically committed (eg via
> cron) on a periodic basis with just a date-stamp?

I'd much rather not clutter the VCS history with umpteen dummy commits.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.