* bug#38133: 27.0.50; compiling master and core dump with r139382-1
@ 2019-11-08 13:53 rrandresf
2019-11-08 14:36 ` Eli Zaretskii
2019-11-08 23:25 ` bug#38133: 27.0.50; compiling master and core dump with r139382-1 Paul Eggert
0 siblings, 2 replies; 12+ messages in thread
From: rrandresf @ 2019-11-08 13:53 UTC (permalink / raw)
To: 38133
Hi. There. I have compiled emacs today 20191108.
Emacs core dumps when trying to open and X-frame it open fine with a tty
frame "-nw".
gdb stops at this line:
/home/aramirez/abs/emacs-lucid-git/src/emacs/lwlib/lwlib-Xlw.c: 139
--8<---------------cut here---------------start------------->8---
XtSetArg (al[ac], XtNmenu, instance->info->val); ac++;
--8<---------------cut here---------------end--------------->8---
and this is the backtrace from gdb:
--8<---------------cut here---------------start------------->8---
(gdb) bt
#0 0x006283d5 in xlw_create_menubar (instance=0xd12250) at lwlib-Xlw.c:139
#1 0x006275d0 in instantiate_widget_instance (instance=instance@entry=0xd12250) at lwlib.c:726
#2 0x00627698 in allocate_widget_instance (info=0xc7a6e0, parent=parent@entry=0xb60b10, pop_up_p=pop_up_p@entry=0 '\000') at lwlib.c:223
#3 0x00627b46 in lw_make_widget (id=1, parent=0xb60b10, pop_up_p=0 '\000') at lwlib.c:770
#4 0x00627b96 in lw_create_widget (type=0x6477bd "menubar", name=0x6477bd "menubar", id=1, val=0xc7aef0, parent=0xb60b10, pop_up_p=0 '\000', pre_activate_cb=0x4792ce <popup_activate_callback>, selection_cb=0x47929a <menubar_selection_callback>, post_activate_cb=0x479139 <popup_deactivate_callback>, highlight_cb=0x479264 <menu_highlight_callback>) at lwlib.c:786
#5 0x0047a6e7 in set_frame_menubar (f=<optimized out>, first_time=<optimized out>, deep_p=<optimized out>) at xmenu.c:959
#6 0x0047a97a in initialize_frame_menubar (f=0xc16200) at xmenu.c:1032
#7 0x004f056e in Fx_create_frame (parms=0xa2647b) at xfns.c:4101
#8 0x00585406 in funcall_subr (subr=0x8f7990 <Sx_create_frame>, numargs=1, args=0xbfffdf54) at eval.c:2867
#9 0x00583d4c in Ffuncall (nargs=2, args=0xbfffdf50) at eval.c:2794
#10 0x005bd239 in exec_byte_code (bytestr=0xb31e78bc, vector=0xb31e6fcd, maxdepth=0x36, args_template=0x402, nargs=1, args=<optimized out>) at bytecode.c:633
#11 0x005867e6 in funcall_lambda (fun=fun@entry=0xb31e6fb5, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfffe18c) at eval.c:2989
#12 0x00583d62 in Ffuncall (nargs=2, args=0xbfffe188) at eval.c:2796
#13 0x005bd239 in exec_byte_code (bytestr=0xb31e78dc, vector=0xb31e6f95, maxdepth=0xe, args_template=0x406, nargs=1, args=<optimized out>) at bytecode.c:633
#14 0x005867e6 in funcall_lambda (fun=fun@entry=0xb31e6f6d, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfffe444) at eval.c:2989
#15 0x00583d62 in Ffuncall (nargs=2, args=0xbfffe440) at eval.c:2796
#16 0x005840c3 in Fapply (nargs=2, args=0xbfffe440) at eval.c:2381
#17 0x005853a8 in funcall_subr (subr=0x8fa930 <Sapply>, numargs=2, args=0xbfffe440) at eval.c:2847
#18 0x00583d4c in Ffuncall (nargs=3, args=0xbfffe43c) at eval.c:2794
#19 0x005bd239 in exec_byte_code (bytestr=0xb311aff4, vector=0xb311b005, maxdepth=0x3e, args_template=0x202, nargs=1, args=<optimized out>) at bytecode.c:633
#20 0x005867e6 in funcall_lambda (fun=fun@entry=0xb311afdd, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfffe664) at eval.c:2989
#21 0x00583d62 in Ffuncall (nargs=2, args=0xbfffe660) at eval.c:2796
#22 0x005bd239 in exec_byte_code (bytestr=0xb31e802c, vector=0xb3119a85, maxdepth=0x3a, args_template=0x402, nargs=1, args=<optimized out>) at bytecode.c:633
#23 0x005867e6 in funcall_lambda (fun=fun@entry=0xb3119a65, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfffe958) at eval.c:2989
#24 0x00583d62 in Ffuncall (nargs=2, args=0xbfffe954) at eval.c:2796
#25 0x005bd239 in exec_byte_code (bytestr=0xb32ff09c, vector=0xb32ff045, maxdepth=0x1a, args_template=0x2, nargs=0, args=<optimized out>) at bytecode.c:633
#26 0x005867e6 in funcall_lambda (fun=fun@entry=0xb32ff02d, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfffeb60) at eval.c:2989
#27 0x00583d62 in Ffuncall (nargs=1, args=0xbfffeb5c) at eval.c:2796
#28 0x005bd239 in exec_byte_code (bytestr=0xb3302e04, vector=0xb3300b3d, maxdepth=0x3a, args_template=0x2, nargs=0, args=<optimized out>) at bytecode.c:633
#29 0x005867e6 in funcall_lambda (fun=fun@entry=0xb3300b25, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbffff3bc) at eval.c:2989
#30 0x00583d62 in Ffuncall (nargs=1, args=0xbffff3b8) at eval.c:2796
#31 0x005bd239 in exec_byte_code (bytestr=0xb33033b4, vector=0xb3302eed, maxdepth=0x32, args_template=0x2, nargs=0, args=<optimized out>) at bytecode.c:633
#32 0x005867e6 in funcall_lambda (fun=fun@entry=0xb3302ed5, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbffff730) at eval.c:2989
#33 0x00585d05 in apply_lambda (fun=fun@entry=0xb3302ed5, args=<optimized out>, count=count@entry=4) at eval.c:2926
#34 0x005863aa in eval_sub (form=0xb33b5e83) at eval.c:2318
#35 0x0058814a in Feval (form=0xb33b5e83, lexical=0x0) at eval.c:2102
#36 0x00503666 in top_level_2 () at keyboard.c:1100
#37 0x00582ea8 in internal_condition_case (bfun=0x503638 <top_level_2>, handlers=0x48, hfun=0x508b94 <cmd_error>) at eval.c:1355
#38 0x0050361f in top_level_1 (ignore=0x0) at keyboard.c:1108
#39 0x00582e0c in internal_catch (tag=0x6a68, func=0x5035a4 <top_level_1>, arg=0x0) at eval.c:1116
#40 0x0050351b in command_loop () at keyboard.c:1069
#41 0x00508764 in recursive_edit_1 () at keyboard.c:714
#42 0x00508aac in Frecursive_edit () at keyboard.c:786
#43 0x005025f9 in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:2055
(gdb)
--8<---------------cut here---------------end--------------->8---
AR
In GNU Emacs 27.0.50 (build 2, i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
Repository revision: 5761a1a3939e23d8e8c725241dd9398a12f191b0
Repository branch: master
System Description: Arch Linux 32
Recent messages:
Loading em-cmpl...done
Loading em-dirs...done
Loading em-glob...done
Loading em-hist...done
Loading em-ls...done
Loading em-prompt...done
Loading em-script...done
Loading em-term...done
Loading em-unix...done
funcall-interactively: End of buffer [2 times]
Command attempted to use minibuffer while in minibuffer
Configured using:
'configure '--program-transform-name=s/^ctags$/ctags.emacs/'
--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/usr/share --with-x-toolkit=lucid
--mandir=/usr/share/man --pdfdir=/usr/share/doc/emacs --with-modules
--with-xft --without-gconf --without-gsettings --with-imagemagick
--without-xwidgets --without-pop --with-gameuser=:games
--disable-build-details 'CFLAGS=-Og -g3'
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
CPPFLAGS=-D_FORTIFY_SOURCE=2
PKG_CONFIG_PATH=/usr/lib/imagemagick6/pkgconfig'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP
Important settings:
value of $LC_COLLATE: C
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Debugger
Minor modes in effect:
electric-pair-mode: t
display-time-mode: t
which-function-mode: t
savehist-mode: t
show-paren-mode: t
erc-services-mode: t
erc-networks-mode: t
erc-track-mode: t
erc-match-mode: t
erc-autojoin-mode: t
erc-fill-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr em-unix em-term term disp-table ehelp em-script
em-prompt em-ls em-hist em-pred em-glob em-dirs esh-var em-cmpl em-basic
em-banner eshell help-fns radix-tree cl-print debug backtrace help-mode
emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa
derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils vc-git diff-mode bug-reference elec-pair
cap-words superword subword gdb-mi bindat gud add-log my-noexternals
server time org-wl netrc emms-get-lyrics ob-latex ob-sql ob-sqlite
ob-plantuml ob-org ob-ledger ob-clojure ob-gnuplot ob-ruby ob-python
ob-R ob-ditaa ob-dot ob-awk ob-C org-element avl-tree generator org
org-macro org-footnote org-pcomplete pcomplete org-list org-faces
org-entities time-date noutline outline easy-mmode org-version
ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp
ob-comint comint ansi-color ring ob-core ob-eval org-compat org-macs
org-loaddefs find-func cal-menu calendar cal-loaddefs jka-compr
my-misc-setup ido which-func savehist paren em-alias esh-mode esh-cmd
esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util
my-erc-setup erc-services erc-networks erc-track erc-match erc-sasl cl
erc-menu erc-join erc-fill erc-stamp erc-goodies erc erc-backend
erc-compat format-spec auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map seq pp erc-loaddefs
my-defuns-setup imenu thingatpt info-look info google-c-style gtags
cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs edmacro kmacro cl-loaddefs cl-lib advice
term/xterm xterm byte-opt gv bytecomp byte-compile cconv tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 8 199535 64869)
(symbols 24 21945 8)
(strings 16 70192 2951)
(string-bytes 1 2459965)
(vectors 8 29656)
(vector-slots 4 354665 74156)
(floats 8 114 1107)
(intervals 28 599 13)
(buffers 568 20))
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#38133: 27.0.50; compiling master and core dump with r139382-1
2019-11-08 13:53 bug#38133: 27.0.50; compiling master and core dump with r139382-1 rrandresf
@ 2019-11-08 14:36 ` Eli Zaretskii
2019-11-08 14:44 ` andrés ramírez
2019-11-08 23:25 ` bug#38133: 27.0.50; compiling master and core dump with r139382-1 Paul Eggert
1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2019-11-08 14:36 UTC (permalink / raw)
To: rrandresf; +Cc: 38133
> From: rrandresf@gmail.com
> Date: Fri, 08 Nov 2019 08:53:22 -0500
>
>
> Hi. There. I have compiled emacs today 20191108.
>
> Emacs core dumps when trying to open and X-frame it open fine with a tty
> frame "-nw".
Sorry, I don't think I understand the scenario. Can you describe step
by step what you did, starting with how you invoked Emacs from the
shell prompt?
Thanks.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#38133: 27.0.50; compiling master and core dump with r139382-1
2019-11-08 14:36 ` Eli Zaretskii
@ 2019-11-08 14:44 ` andrés ramírez
2019-11-08 15:21 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: andrés ramírez @ 2019-11-08 14:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 38133
Hi Eli.
Eli> Sorry, I don't think I understand the scenario. Can you describe
Eli> step by step what you did, starting with how you invoked Emacs
Eli> from the shell prompt?
$ emacs -Q (fails)
$ emacs -Q -nw (works fine)
AR
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#38133: 27.0.50; compiling master and core dump with r139382-1
2019-11-08 14:44 ` andrés ramírez
@ 2019-11-08 15:21 ` Eli Zaretskii
2019-11-08 15:43 ` andrés ramírez
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2019-11-08 15:21 UTC (permalink / raw)
To: andrés ramírez; +Cc: 38133
> From: andrés ramírez <rrandresf@gmail.com>
> Cc: 38133@debbugs.gnu.org
> Date: Fri, 08 Nov 2019 14:44:43 +0000
>
> $ emacs -Q (fails)
Thanks.
Can you start Emacs from GDB, and post the backtrace from the crash?
Also, did you specify these link switches:
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
and if so, what happens if you don't? IOW, does Emacs configured and
built with just "./configure; make" crash in the same way?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#38133: 27.0.50; compiling master and core dump with r139382-1
2019-11-08 15:21 ` Eli Zaretskii
@ 2019-11-08 15:43 ` andrés ramírez
2019-11-08 16:11 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: andrés ramírez @ 2019-11-08 15:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 38133
Hi Eli.
Eli> Can you start Emacs from GDB, and post the backtrace from the
Eli> crash?
I have done it on the first mail (bug report).
Eli> Also, did you specify these link switches:
Eli> LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
No. I am just packaging master with default flags but no LDFLAGS
especified on the script (I have re-checked it).
Eli> and if so, what happens if you don't? IOW, does Emacs configured
Eli> and built with just "./configure; make" crash in the same way?
I am compiling with this options (at the moment):
--8<---------------cut here---------------start------------->8---
../configure --program-transform-name='s/^ctags$/ctags.emacs/'--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/usr/share --with-x-toolkit=lucid --mandir=/usr/share/man --pdfdir=/usr/share/doc/emacs --with-modules --with-xft --without-gconf --without-gsettings --with-imagemagick --without-xwidgets --without-pop --with-gameuser=:games --disable-build-details
--8<---------------cut here---------------end--------------->8---
I Got a different issue which i workarounded two lines below:
mkdir build; cd build; ../configure .....; make (got an error)
gcc: error: ../lwlib/liblw.a: No such file or directory
then i did
--8<---------------cut here---------------start------------->8---
cp ../lwlib/liblw.a lwlib/
--8<---------------cut here---------------end--------------->8---
and make ended sucessfully.
Then I tested ./src/emacs. And it failed as explained in the first bug report
wich includes backtrace.
BR
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#38133: 27.0.50; compiling master and core dump with r139382-1
2019-11-08 15:43 ` andrés ramírez
@ 2019-11-08 16:11 ` Eli Zaretskii
2019-11-08 16:40 ` andrés ramírez
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2019-11-08 16:11 UTC (permalink / raw)
To: andrés ramírez; +Cc: 38133
> From: andrés ramírez <rrandresf@gmail.com>
> Cc: 38133@debbugs.gnu.org
> Date: Fri, 08 Nov 2019 15:43:33 +0000
>
> Eli> Can you start Emacs from GDB, and post the backtrace from the
> Eli> crash?
>
> I have done it on the first mail (bug report).
I thought that was from a core dump?
If that was from a running Emacs, then why don't I see what fatal
signal crashed Emacs? It is the first thing GDB announces when a
debugged program crashes. If you elided that, please post that part,
it's important.
> Eli> Also, did you specify these link switches:
> Eli> LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
>
> No. I am just packaging master with default flags but no LDFLAGS
> especified on the script (I have re-checked it).
So where do they come from? Do you see them in src/Makefile?
> I Got a different issue which i workarounded two lines below:
>
> mkdir build; cd build; ../configure .....; make (got an error)
> gcc: error: ../lwlib/liblw.a: No such file or directory
>
> then i did
> --8<---------------cut here---------------start------------->8---
> cp ../lwlib/liblw.a lwlib/
> --8<---------------cut here---------------end--------------->8---
>
> and make ended sucessfully.
Does this mean liblw.a was created in the source directory, not in the
build directory?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#38133: 27.0.50; compiling master and core dump with r139382-1
2019-11-08 16:11 ` Eli Zaretskii
@ 2019-11-08 16:40 ` andrés ramírez
2019-11-08 17:08 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: andrés ramírez @ 2019-11-08 16:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 38133
Hi Eli.
Eli> If that was from a running Emacs, then why don't I see what fatal
Eli> signal crashed Emacs? It is the first thing GDB announces when a
Eli> debugged program crashes. If you elided that, please post that
Eli> part, it's important.
--8<---------------cut here---------------start------------->8---
Current directory is ~/
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from emacs...
(gdb) run
Starting program: /usr/bin/emacs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0xb2bb7b40 (LWP 14866)]
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x006283d5 in xlw_create_menubar (instance=0xd122f0) at lwlib-Xlw.c:139
139 XtSetArg (al[ac], XtNmenu, instance->info->val); ac++;
(gdb) bt
#0 0x006283d5 in xlw_create_menubar (instance=0xd122f0) at lwlib-Xlw.c:139
#1 0x006275d0 in instantiate_widget_instance (instance=instance@entry=0xd122f0) at lwlib.c:726
#2 0x00627698 in allocate_widget_instance (info=0xc7a6e0, parent=parent@entry=0xb60b10, pop_up_p=pop_up_p@entry=0 '\000') at lwlib.c:223
#3 0x00627b46 in lw_make_widget (id=1, parent=0xb60b10, pop_up_p=0 '\000') at lwlib.c:770
#4 0x00627b96 in lw_create_widget (type=0x6477bd "menubar", name=0x6477bd "menubar", id=1, val=0xc7afd0, parent=0xb60b10, pop_up_p=0 '\000', pre_activate_cb=0x4792ce <popup_activate_callback>, selection_cb=0x47929a <menubar_selection_callback>, post_activate_cb=0x479139 <popup_deactivate_callback>, highlight_cb=0x479264 <menu_highlight_callback>) at lwlib.c:786
#5 0x0047a6e7 in set_frame_menubar (f=<optimized out>, first_time=<optimized out>, deep_p=<optimized out>) at xmenu.c:959
#6 0x0047a97a in initialize_frame_menubar (f=0xc16200) at xmenu.c:1032
#7 0x004f056e in Fx_create_frame (parms=0xa2647b) at xfns.c:4101
#8 0x00585406 in funcall_subr (subr=0x8f7990 <Sx_create_frame>, numargs=1, args=0xbfffdf54) at eval.c:2867
#9 0x00583d4c in Ffuncall (nargs=2, args=0xbfffdf50) at eval.c:2794
#10 0x005bd239 in exec_byte_code (bytestr=0xb31e78bc, vector=0xb31e6fcd, maxdepth=0x36, args_template=0x402, nargs=1, args=<optimized out>) at bytecode.c:633
#11 0x005867e6 in funcall_lambda (fun=fun@entry=0xb31e6fb5, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfffe18c) at eval.c:2989
#12 0x00583d62 in Ffuncall (nargs=2, args=0xbfffe188) at eval.c:2796
#13 0x005bd239 in exec_byte_code (bytestr=0xb31e78dc, vector=0xb31e6f95, maxdepth=0xe, args_template=0x406, nargs=1, args=<optimized out>) at bytecode.c:633
#14 0x005867e6 in funcall_lambda (fun=fun@entry=0xb31e6f6d, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfffe444) at eval.c:2989
#15 0x00583d62 in Ffuncall (nargs=2, args=0xbfffe440) at eval.c:2796
#16 0x005840c3 in Fapply (nargs=2, args=0xbfffe440) at eval.c:2381
#17 0x005853a8 in funcall_subr (subr=0x8fa930 <Sapply>, numargs=2, args=0xbfffe440) at eval.c:2847
#18 0x00583d4c in Ffuncall (nargs=3, args=0xbfffe43c) at eval.c:2794
#19 0x005bd239 in exec_byte_code (bytestr=0xb311aff4, vector=0xb311b005, maxdepth=0x3e, args_template=0x202, nargs=1, args=<optimized out>) at bytecode.c:633
#20 0x005867e6 in funcall_lambda (fun=fun@entry=0xb311afdd, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfffe664) at eval.c:2989
#21 0x00583d62 in Ffuncall (nargs=2, args=0xbfffe660) at eval.c:2796
#22 0x005bd239 in exec_byte_code (bytestr=0xb31e802c, vector=0xb3119a85, maxdepth=0x3a, args_template=0x402, nargs=1, args=<optimized out>) at bytecode.c:633
#23 0x005867e6 in funcall_lambda (fun=fun@entry=0xb3119a65, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0xbfffe958) at eval.c:2989
#24 0x00583d62 in Ffuncall (nargs=2, args=0xbfffe954) at eval.c:2796
#25 0x005bd239 in exec_byte_code (bytestr=0xb32ff09c, vector=0xb32ff045, maxdepth=0x1a, args_template=0x2, nargs=0, args=<optimized out>) at bytecode.c:633
#26 0x005867e6 in funcall_lambda (fun=fun@entry=0xb32ff02d, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbfffeb60) at eval.c:2989
#27 0x00583d62 in Ffuncall (nargs=1, args=0xbfffeb5c) at eval.c:2796
#28 0x005bd239 in exec_byte_code (bytestr=0xb3302e04, vector=0xb3300b3d, maxdepth=0x3a, args_template=0x2, nargs=0, args=<optimized out>) at bytecode.c:633
#29 0x005867e6 in funcall_lambda (fun=fun@entry=0xb3300b25, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbffff3bc) at eval.c:2989
#30 0x00583d62 in Ffuncall (nargs=1, args=0xbffff3b8) at eval.c:2796
#31 0x005bd239 in exec_byte_code (bytestr=0xb33033b4, vector=0xb3302eed, maxdepth=0x32, args_template=0x2, nargs=0, args=<optimized out>) at bytecode.c:633
#32 0x005867e6 in funcall_lambda (fun=fun@entry=0xb3302ed5, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0xbffff730) at eval.c:2989
#33 0x00585d05 in apply_lambda (fun=fun@entry=0xb3302ed5, args=<optimized out>, count=count@entry=4) at eval.c:2926
#34 0x005863aa in eval_sub (form=0xb33b5e83) at eval.c:2318
#35 0x0058814a in Feval (form=0xb33b5e83, lexical=0x0) at eval.c:2102
#36 0x00503666 in top_level_2 () at keyboard.c:1100
#37 0x00582ea8 in internal_condition_case (bfun=0x503638 <top_level_2>, handlers=0x48, hfun=0x508b94 <cmd_error>) at eval.c:1355
#38 0x0050361f in top_level_1 (ignore=0x0) at keyboard.c:1108
#39 0x00582e0c in internal_catch (tag=0x6a68, func=0x5035a4 <top_level_1>, arg=0x0) at eval.c:1116
#40 0x0050351b in command_loop () at keyboard.c:1069
#41 0x00508764 in recursive_edit_1 () at keyboard.c:714
#42 0x00508aac in Frecursive_edit () at keyboard.c:786
#43 0x005025f9 in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:2055
(gdb)
--8<---------------cut here---------------end--------------->8---
Eli> Also, did you specify these link switches:
Eli> LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
>>
>> No. I am just packaging master with default flags but no LDFLAGS
>> especified on the script (I have re-checked it).
Eli> So where do they come from? Do you see them in src/Makefile?
Yes. You are Right. Should I remove then?
>> I Got a different issue which i workarounded two lines below:
>>
>> mkdir build; cd build; ../configure .....; make (got an error) gcc:
>> error: ../lwlib/liblw.a: No such file or directory
Eli> Does this mean liblw.a was created in the source directory, not
Eli> in the build directory?
Not sure about this. Because on the same directory where I am packaging
for my distro. I have created a build directory (where I am
testing. according to our discussion).
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#38133: 27.0.50; compiling master and core dump with r139382-1
2019-11-08 16:40 ` andrés ramírez
@ 2019-11-08 17:08 ` Eli Zaretskii
2019-11-08 17:23 ` andrés ramírez
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2019-11-08 17:08 UTC (permalink / raw)
To: andrés ramírez; +Cc: 38133
> From: andrés ramírez <rrandresf@gmail.com>
> Cc: 38133@debbugs.gnu.org
> Date: Fri, 08 Nov 2019 16:40:00 +0000
>
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x006283d5 in xlw_create_menubar (instance=0xd122f0) at lwlib-Xlw.c:139
> 139 XtSetArg (al[ac], XtNmenu, instance->info->val); ac++;
OK, so which of these caused the crash? Is one of them a NULL pointer
or an invalid pointer, or is ac a garbled value?
> Eli> LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
> >>
> >> No. I am just packaging master with default flags but no LDFLAGS
> >> especified on the script (I have re-checked it).
>
> Eli> So where do they come from? Do you see them in src/Makefile?
>
> Yes. You are Right. Should I remove then?
I'd suggest to try, yes.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#38133: 27.0.50; compiling master and core dump with r139382-1
2019-11-08 17:08 ` Eli Zaretskii
@ 2019-11-08 17:23 ` andrés ramírez
2019-11-08 19:08 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: andrés ramírez @ 2019-11-08 17:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 38133
Hi Eli. SOLVED.
When You pointed out LDFLAGS, that gave me some hints. About similar
problems in the past (i have read on emacs-devel). Most of them were solved with 'make bootstrap'. So
I modified my packaging script for also including {./autogen.sh; make
bootstrap}. This solved It.
>> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>> 0x006283d5 in xlw_create_menubar (instance=0xd122f0) at
>> lwlib-Xlw.c:139 139 XtSetArg (al[ac], XtNmenu,
>> instance->info->val); ac++;
Eli> OK, so which of these caused the crash? Is one of them a NULL
Eli> pointer or an invalid pointer, or is ac a garbled value?
Probably this is going to be irrelevant. But as the debugging session
was still open:
--8<---------------cut here---------------start------------->8---
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x006283d5 in xlw_create_menubar (instance=0xd12520) at lwlib-Xlw.c:139
139 XtSetArg (al[ac], XtNmenu, instance->info->val); ac++;
(gdb) p al
$1 = {{name = 0x6337dc "menu", value = -1236906428}, {name = 0xb633fb60 <malloc+400> "\211Dž\300\017\204", <incomplete sequence \306>, value = 13594960}, {name = 0xc7b1c0 "", value = 3}, {name = 0x709d2c "\254\232\060", value = 13594960}, {name = 0xc7b1c0 "", value = 3}}
(gdb) p al[ac]
$2 = {name = 0x6337dc "menu", value = -1236906428}
(gdb) p ac
$3 = 0
(gdb) p XtNmenu
$4 = "menu"
(gdb) p instance->info->val
Cannot access memory at address 0xc
(gdb)
--8<---------------cut here---------------end--------------->8---
AR.
ps: should I close de bug report?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#38133: 27.0.50; compiling master and core dump with r139382-1
2019-11-08 17:23 ` andrés ramírez
@ 2019-11-08 19:08 ` Eli Zaretskii
2019-11-08 19:27 ` bug#38133: close 38133 andrés ramírez
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2019-11-08 19:08 UTC (permalink / raw)
To: andrés ramírez; +Cc: 38133
> From: andrés ramírez <rrandresf@gmail.com>
> Cc: 38133@debbugs.gnu.org
> Date: Fri, 08 Nov 2019 17:23:54 +0000
>
> Hi Eli. SOLVED.
>
> When You pointed out LDFLAGS, that gave me some hints. About similar
> problems in the past (i have read on emacs-devel). Most of them were solved with 'make bootstrap'. So
> I modified my packaging script for also including {./autogen.sh; make
> bootstrap}. This solved It.
Great, thanks.
> 139 XtSetArg (al[ac], XtNmenu, instance->info->val); ac++;
> (gdb) p al
> $1 = {{name = 0x6337dc "menu", value = -1236906428}, {name = 0xb633fb60 <malloc+400> "\211Dž\300\017\204", <incomplete sequence \306>, value = 13594960}, {name = 0xc7b1c0 "", value = 3}, {name = 0x709d2c "\254\232\060", value = 13594960}, {name = 0xc7b1c0 "", value = 3}}
> (gdb) p al[ac]
> $2 = {name = 0x6337dc "menu", value = -1236906428}
> (gdb) p ac
> $3 = 0
> (gdb) p XtNmenu
> $4 = "menu"
> (gdb) p instance->info->val
> Cannot access memory at address 0xc
OK, so instance or instance->info is a NULL pointer. But this is no
longer important.
> ps: should I close de bug report?
Yes, please.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#38133: 27.0.50; compiling master and core dump with r139382-1
2019-11-08 13:53 bug#38133: 27.0.50; compiling master and core dump with r139382-1 rrandresf
2019-11-08 14:36 ` Eli Zaretskii
@ 2019-11-08 23:25 ` Paul Eggert
1 sibling, 0 replies; 12+ messages in thread
From: Paul Eggert @ 2019-11-08 23:25 UTC (permalink / raw)
To: rrandresf; +Cc: 38133-done
Sounds like a common problem: liblw.a is left over from a previous build
with different configuration parameters, and is incompatible with the
current build. Anyway, problem solved so closing the bug report.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-11-08 23:25 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-08 13:53 bug#38133: 27.0.50; compiling master and core dump with r139382-1 rrandresf
2019-11-08 14:36 ` Eli Zaretskii
2019-11-08 14:44 ` andrés ramírez
2019-11-08 15:21 ` Eli Zaretskii
2019-11-08 15:43 ` andrés ramírez
2019-11-08 16:11 ` Eli Zaretskii
2019-11-08 16:40 ` andrés ramírez
2019-11-08 17:08 ` Eli Zaretskii
2019-11-08 17:23 ` andrés ramírez
2019-11-08 19:08 ` Eli Zaretskii
2019-11-08 19:27 ` bug#38133: close 38133 andrés ramírez
2019-11-08 23:25 ` bug#38133: 27.0.50; compiling master and core dump with r139382-1 Paul Eggert
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).