[Bug 168] New: pdump causes segfault under OpenBSD during compile

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

Bug ID: 168
Summary: pdump causes segfault under OpenBSD during compile
Product: SXEmacs
Version: 22.1.15
Hardware: PC
OS: BSD
Status: NEW
Severity: major
Priority: P5
Component: Compile/Install
Assignee: ***@sxemacs.org
Reporter: ***@sxemacs.org
QA Contact: sxemacs-***@sxemacs.org

Attempting to compile on OpenBSD, the build fails as shown for make target
sxemacs.dmp :

Loading site-load...
Finding pointers to doc strings...
Note: Strange doc (not fboundp) for function root @ 461099
Finding pointers to doc strings...done
Dumping under the name sxemacs.dmp
/home/burkhardth/sxemacs/=build/src/.libs/sxemacs:/usr/local/lib/libcompface.so.1.0:
/usr/local/lib/libmp3lame.so.2.1 : WARNING: symbol(freqs) size mismatch, relink
your program
/usr/local/bin/bash: line 14: 6632 Segmentation fault (core dumped)
DYLD_LIBRARY_PATH=.:./.libs:../src/ui/lwlib:../src/ui/lwlib/.libs:/opt/sxemacs/lib:$DYLD_LIBRARY_PATH:
LD_LIBRARY_PATH=.:./.libs:../src/ui/lwlib:../src/ui/lwlib/.libs:/opt/sxemacs/lib:$LD_LIBRARY_PATH:
SHLIB_PATH=.:./.libs:../src/ui/lwlib:../src/ui/lwlib/.libs:/opt/sxemacs/lib:$SHLIB_PATH:
SOURCE_TREE_ROOT= BUILD_TREE_ROOT= ./sxemacs -batch -l shadow -f
list-load-path-shadows
Makefile:2538: recipe for target 'sxemacs.dmp' failed
gmake[3]: *** [sxemacs.dmp] Error 139
gmake[3]: Leaving directory '/home/burkhardth/sxemacs/=build/src'
Makefile:2207: recipe for target 'all-recursive' failed
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory '/home/burkhardth/sxemacs/=build/src'
Makefile:881: recipe for target 'all' failed
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory '/home/burkhardth/sxemacs/=build/src'
Makefile:818: recipe for target 'all-recursive' failed
gmake: *** [all-recursive] Error 1

gdb shows that this error occurs in the portable dumper, but is not terribly
helpful otherwise:

#0 0x1ad44a17 in pdump_load () from
/home/burkhardth/sxemacs/=build/src/.libs/sxemacs
#1 0x1ac7ddeb in sxemacs_v22_1_15_173_g9706bca_pentiumm_unknown_openbsd5_7 ()
from /home/burkhardth/sxemacs/=build/src/.libs/sxemacs
#2 0x1ac7e204 in main () from
/home/burkhardth/sxemacs/=build/src/.libs/sxemacs

This is specific to OpenBSD as far as I can tell, FreeBSD doesn't produce the
same error, and I haven't tested NetBSD yet but will report back.

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #1 from Horst G�nther Burkhardt III <***@sxemacs.org> ---
Steps to reproduce:

- Attempt to compile SXEmacs on OpenBSD :
- bash autogen.sh
- cd \=build && mkdir \=build
- bash ../configure
- gmake build-report

I'm willing to provide SSH access to the OpenBSD box I have if required.

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #2 from Steve Youngs <***@sxemacs.org> ---
(In reply to Horst G�nther Burkhardt III from comment #1)

Post by i***@sxemacs.org
I'm willing to provide SSH access to the OpenBSD box I have if required.

OK, yep, I'll take a look. Send me login details.

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #3 from Steve Youngs <***@sxemacs.org> ---
Created attachment 156
--> http://issues.sxemacs.org/attachment.cgi?id=156&action=edit
Installation

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #4 from Steve Youngs <***@sxemacs.org> ---
Created attachment 157
--> http://issues.sxemacs.org/attachment.cgi?id=157&action=edit
config.log

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #5 from Steve Youngs <***@sxemacs.org> ---
Created attachment 158
--> http://issues.sxemacs.org/attachment.cgi?id=158&action=edit
gmake output

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #6 from Steve Youngs <***@sxemacs.org> ---
Created attachment 159
--> http://issues.sxemacs.org/attachment.cgi?id=159&action=edit
gdb output

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

Steve Youngs <***@sxemacs.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@sxemacs.org

--- Comment #7 from Steve Youngs <***@sxemacs.org> ---
As far as I can see, it is not pdump. If you look at the gdb output
(Attachment 159) you'll see it's related to threading.

Erm, I've got no clue at this point, sorry.

I'll add Nelson to the Cc list, maybe he can shed a little light.

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #8 from Nelson Ferreira <***@sxemacs.org> ---
I'll have to confirm later but this looks like the issue really is that the
almost out of memory warning came before a lock in the print system was
initialized. It probably is a very simple fix for the crash.

You may still endup with low memory related issues

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #9 from Steve Youngs <***@sxemacs.org> ---
Is anything happening on this one? I've just had a report via IRC with very
similar (read: pretty much identical) symptoms on Linux (Arch Linux I think)

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

Steve Youngs <***@sxemacs.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|major |normal

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

Karl M. Hegbloom <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #10 from Karl M. Hegbloom <***@gmail.com> ---
I can confirm that it's not working right under Ubuntu 16.10, x86_64, for both
v22.1.16 and for git master as of 2016/10/29 16:00 MDT.

I'm not certain, but I think that this appears to be related to the other bug
report in the "build" category pertaining to address randomization.

How do I disable that? (I will look it up, but if I don't find it...)



Making all in lisp
make[1]: Entering directory
'/home/karlheg/src/Emacs/sxemacs-22.1.16/build/lisp'
Building finder database ...
DYLD_LIBRARY_PATH=../src:../src/.libs:../src/ui/lwlib:../src/ui/lwlib/.libs:/usr/local/lib:$DYLD_LIBRARY_PATH:
LD_LIBRARY_PATH=../src:../src/.libs:../src/ui/lwlib:../src/ui/lwlib/.libs:/usr/local/lib:$LD_LIBRARY_PATH:
SHLIB_PATH=../src:../src/.libs:../src/ui/lwlib:../src/ui/lwlib/.libs:/usr/local/lib:$SHLIB_PATH:
EMACSPACKAGEPATH=
SOURCE_TREE_ROOT=/home/karlheg/src/Emacs/sxemacs-22.1.16/build/..
BUILD_TREE_ROOT=/home/karlheg/src/Emacs/sxemacs-22.1.16/build ../src/sxemacs
-batch -vanilla -no-autoloads \
-l finder -f finder-compile-keywords
Makefile:1205: recipe for target 'autoc.stamp' failed
make[1]: *** [autoc.stamp] Segmentation fault (core dumped)



***@syrinx:~/src/Emacs/sxemacs-22.1.16/build$ gdb src/.libs/lt-sxemacs
lisp/core
GNU gdb (Ubuntu 7.12-0ubuntu1) 7.12
Copyright (C) 2016 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 "x86_64-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 src/.libs/lt-sxemacs...done.
[New LWP 4075]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by
`/home/karlheg/src/Emacs/sxemacs-22.1.16/build/src/.libs/lt-sxemacs -batch
-vani'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 pdump_load_finish () at ../../src/dumper.c:1146
1146 (*ptr.address) = ptr.value + delta;
(gdb) where full
#0 pdump_load_finish () at ../../src/dumper.c:1146
ptr = <error reading variable ptr (Cannot access memory at address
0x7fb3afcf7e68)>
i = 0
p = 0x7fb3afcf7e70 <error: Cannot access memory at address
0x7fb3afcf7e70>
delta = 140409719717888
header = 0x7fb3af778000
#1 pdump_load (argv0=<optimized out>) at ../../src/dumper.c:1421
exe_path =
"/home/karlheg/src/Emacs/sxemacs-22.1.16/build/src/.libs/lt-sxemacs.dmp",
'\000' <repeats 4025 times>
real_exe_path =
"/home/karlheg/src/Emacs/sxemacs-22.1.16/build/src/.libs/lt-sxemacs", '\000'
<repeats 118 times>, "H\202\240\274\263\177\000\000
\201\204\207\375\177\000\000"...
libarchdir_path =
"/usr/local/lib/sxemacs-22.1.16/core2-unknown-linux-gnu/sxemacs", '\000'
<repeats 4033 times>
w = <optimized out>
dir = <optimized out>
p = <optimized out>
#2 0x000056172e8163b3 in sxemacs_v22_1_16_core2_unknown_linux_gnu (argc=8,
argv=0x7ffd87849fa8, envp=<optimized out>, restart=0) at ../../src/emacs.c:1299
inhibit_early_packages_save = 1
inhibit_autoloads_save = 0
debug_paths_save = 0
inhibit_site_modules_save = 0
stack_bottom_variable = 0 '\000'
skip_args = 1
load_me = <optimized out>
inhibit_window_system = <optimized out>
pkgd = 0x0
#3 0x000056172e7c56f8 in main (argc=<optimized out>, argv=<optimized out>,
envp=0x7ffd87849ff0) at ../../src/emacs.c:2707
vol_argc = 8
vol_argv = 0x7ffd87849fa8
vol_envp = 0x7ffd87849ff0
restarted = 0
arg = <optimized out>
(gdb)

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #11 from Karl M. Hegbloom <***@gmail.com> ---
I can now confirm that on the same Ubuntu 16.10, building with:

setarch $(uname -m) -R make [make args]

... allows the build and dump to complete, but the binary won't run with ASLR
enabled, so it must also be run with:

setarch $(uname -m) -R sxemacs

So, a wrapper script for running it will be required until it can deal with the
ASLR itself.

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #12 from Karl M. Hegbloom <***@gmail.com> ---
<sigh> Sorry. I should have tested more first. When I make install, it won't
run; it seg faults even with setarch... what I tested that worked was in the
build tree, cd tests, then:

setarch $(uname -m) -R make check-formats

... and I got a sxemacs frame on the screen.

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #13 from Karl M. Hegbloom <***@gmail.com> ---
Ok, last one, I promise. :-)

If I do:

sudo setarch $(uname -m) -R make install

... then it will run with:

setarch $(uname -m) -R sxemacs

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #14 from Steve Youngs <***@sxemacs.org> ---
Sooooo, our pdump can't handle stack randomisation? And I'm guessing that
Ubuntu has a GCC and libc that has it turned on by default?

Is there a compiler flag we could use to negate the need for wrapping with
'setarch -R'? Or is this predominately a run-time affair? I really don't want
to resort to forcing folks to run SXEmacs via a wrapper script.

Nelson, I know you're busy mate, but... thoughts? Ideas?

[i***@sxemacs.org]

http://issues.sxemacs.org/show_bug.cgi?id=168

--- Comment #15 from Nelson Ferreira <***@sxemacs.org> ---
Something is different on Karl's Ubuntu 16.10

Just did a clean build on mine without any issues.

Made sure it was up to date, so this was after an apt-get update ; apt-get
dist-upgrade