Van Ly <van.ly%sdf.org@localhost> writes:
> When you run uemacs, the terminal screen clears and errors as follows:
>
> --> [Setting up....][3] Abort trap (core dumped) uemacs
I see this too.
Compiling it, I notice:
../src/unix.c: In function 'bktoshell':
../src/unix.c:1226:5: warning: type of 'f' defaults to 'int' [-Wimplicit-int]
1226 | int bktoshell(f, n)
| ^~~~~~~~~
../src/unix.c:1226:5: warning: type of 'n' defaults to 'int' [-Wimplicit-int]
and on running:
[Setting up....]Abort trap (core dumped): garlic.lexort.com uemacs - - - buffer overflow detected; terminated
with a backtrace from gdb
#0 0x00006f803a99118a in _lwp_kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0x00006f803a99118a in _lwp_kill () from /usr/lib/libc.so.12
#1 0x00006f803a96f5b0 in ?? () from /usr/lib/libc.so.12
#2 0x00006f803a96f5da in __chk_fail () from /usr/lib/libc.so.12
#3 0x00006f803a9650f2 in __strcpy_chk () from /usr/lib/libc.so.12
#4 0x0000000172810bd4 in ?? ()
#5 0x0000000172810439 in ?? ()
#6 0x0000000172811446 in ?? ()
#7 0x0000000172807e70 in ?? ()
#8 0x0000000172817fab in ?? ()
#9 0x00000001728227a4 in ?? ()
#10 0x000000017280680d in ?? ()
#11 0x00007f7efe00bbb8 in ?? () from /usr/libexec/ld.elf_so
#12 0x0000000000000001 in ?? ()
#13 0x00007f7fffd75600 in ?? ()
#14 0x0000000000000000 in ?? ()
which means that almost certainly the upstream code is buggy. I don't
know if you somehow turned off hardening enough to not get the overflow
detection.
You did not explain quite a lot in your email, such as (while much of
this is perhaps not important, people making bug reports can almost
never know what is and isn't important):
are you running 10.0 or up-to-date netbsd-10
what cpu type
whether you are using binary packages, and if so the URL, or you have
built yourself
whether you have modified OS esttings in sysctl.conf
I see you did include mk.conf. Line numbers and miswrapping make it
hard to read.
Overall you have a fairly large amount of non-default settings. Building
packages with non-default settings and using binary packages at the same
time basically gets you undefined behavior, although sometimes it is ok.
But what you have done is too much. (The license gives you the freeedom
to do this - but I don't want to help debug it.)
In general, it is best to try to reproduce any errors in a
minimally-different installation. That means
- not using a different compiler (that btw you didn't explain where it
came from)
- not setting CPPFLAGS/LDFLAGS
- not changing SSP/FORTIFY/etc
- not setting things that are the default value (LOCALBASE)
- not setting CPUFLAGS
If the error persists with a standard approach, others are likely to be
much more willing to look into it. If you can say that changing one
thing changes the behavior from ok to bad, that's also interesting.
But what I am hearing is "I have this non-standard pretty complicated
setup and something doesn't work".
Because there are warnings during the build, you should read the code
and see what's going on. You should check the upstream bugtracker and
likely file a bug, if pkgsrc is up-to-date. If pkgsrc is not up-to-date
(latest formal release), see my other msg about wip and preparing an
update. You can fix the bug you find from the warning by hand and see
if that helps, too. Even if the code with the warning is not
problematic, upstream should fix it, unless the code is formally correct
and there is a case that the compiler is unreasonable. This doesn't
seem like one of those times, so far.