unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "andrés ramírez" <rrandresf@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 38133@debbugs.gnu.org
Subject: bug#38133: 27.0.50; compiling master and core dump with r139382-1
Date: Fri, 08 Nov 2019 16:40:00 +0000	[thread overview]
Message-ID: <86ftiywcdb.fsf@gmail.com> (raw)
In-Reply-To: <83lfsqbb67.fsf@gnu.org>

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).






  reply	other threads:[~2019-11-08 16:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86ftiywcdb.fsf@gmail.com \
    --to=rrandresf@gmail.com \
    --cc=38133@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /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 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).