boot: Segmentation fault message

[jggimi]

Install media is the RAMDISK kernel and its embedded userland, which does not run rc(8) and does not have kvm_mkdb(8) installed. There's a one-line dummy /etc/rc file for init(8).

[shep]

I think problems don't start on init. /bsd.rd shows nothing abnormal on init. The first sign something has gone off the rails is after mkdev, it warns that it is unable redo the kernel (I can't recall: generate unique kernel vs relink kernel).

[jggimi]

Originally Posted by shep

I can't recall...

KARL - Kernel Address Randomized Link - is used to create a GENERIC or GENERIC.MP kernel with unique entry points in advance of every boot.

• During installation, the RAMDISK kernel install script should produce the following message:

  Relinking to create unique kernel... done.

  If you don't get "done" after the ellipsis, write down the error message you receive instead, so that you will be able to create a useful error report.
• During every standard GENERIC/GENERIC.MP boot, rc(8) will execute the script /usr/libexec/reorder_kernel. If kernel relinking succeeds, the console and /var/log/messages will show:

  reorder_kernel: kernel relinking done

  If you don't get this message, note what error you do get. It is common to receive the following message, which will occur if the chain of SHA hashes has been broken, intentionally or not:

  Failed to verify /bsd's checksum, therefore a randomly linked kernel (KARL)
  is not being built. KARL can be re-enabled for next boot by issuing as root:
  
  sha256 -h /var/db/kernel.SHA256 /bsd

  An intentional hash break will occur through the use of a custom kernel or a kernel altered with config(8).

[shep]

I again re-install Crux/Grub2.2 followed by the latest install66.fs. There were no error messages the OpenBSD install other than the lack of rtwn firmware. I rebooted into Crux Linux and downloaded the BOOT*.EFI files from my mirror and installed them to /boot/efi/openbsd/*. Generated a new grub.cfg and rebooted. Still get the Segmentation fault message. System otherwise runs normally and was able to install rtwn firmware from a usb drive.

cat /var/log/messages | grep relink
shows that the kernel successfully relinked x2
Able to install intel and vmm firmware w/ fw_update.
There is a /var/db/kernel.SHA256.

The Segmentation fault message is consistent on this system over 3 installs.
Will run gdb and append to this post.

gdb /usr/sbin/kvm_mkdb /var/crash/kvm_mkdb.core

Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4 should be 2) [in module /usr/libexec/ld.so]
Variable "dst" is not available

There is more info with (gdb) bt. Is there a way I can direct the output to a log file?

[jggimi]

From what you've posted, it looks like a damaged symbol table in a library.

You can "log" your session with script(1), with tmux(1), and you can even duplicate standard output to a file descriptor in many shells. But $ script followed by your gdb session, then $ col -b < typescript > my.logfile is probably the simplest and quickest way.

---

Since you are receiving consistent segmentation faults, you should be able to determine if your multiboot environment is a factor by *installing* the OS onto a USB stick without a second OS, and then booting the stick on this hardware.

[shep]

...you should be able to determine if your multiboot environment is a factor by *installing* the OS onto a USB stick without a second OS, and then booting the stick on this hardware.

One reason for the delayed response is that I got rid of the dual boot and installed OpenBSD as the only OS to the hard drive. There was no Segmentation fault with OpenBSD as the only OS.

Here is the output:

Script started on Mon Nov 11 18:02:47 2019
Kanga# ge eb  db /usr/sbin/kvm_mkdb  db /var/gra   crash/kvm_m                
Kanga# gdb /usr/sbin/kvm_mkdb /var/crash/kvm_mkdb.core                                                                  
Kanga# gdb /usr/sbin/kvm_mkdb /var/crash/kvm_mkdb.core  

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.6"...(no debugging symbols found)

Core was generated by `kvm_mkdb'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /usr/sbin/kvm_mkdb
Reading symbols from /usr/lib/libc.so.96.0...done.
Loaded symbols for /usr/lib/libc.so.96.0
Reading symbols from /usr/libexec/ld.so...Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
#0  _libc_strlcpy (dst=Variable "dst" is not available.
) at /usr/src/lib/libc/string/strlcpy.c:36
36	/usr/src/lib/libc/string/strlcpy.c: No such file or directory.
	in /usr/src/lib/libc/string/strlcpy.c
(gdb) bt
#0  _libc_strlcpy (dst=Variable "dst" is not available.
) at /usr/src/lib/libc/string/strlcpy.c:36
#1  0x0000137aff002d5f in ?? () from /usr/sbin/kvm_mkdb
#2  0x0000137aff0030c6 in ?? () from /usr/sbin/kvm_mkdb
#3  0x0000137aff002864 in ?? () from /usr/sbin/kvm_mkdb
#4  0x0000137aff002620 in ?? () from /usr/sbin/kvm_mkdb
#5  0x0000137aff00213b in ?? () from /usr/sbin/kvm_mkdb
#6  0x0000000000000000 in ?? ()
Current language:  auto; currently minimal
(gdb) quit    bt
#0  _libc_strlcpy (dst=Variable "dst" is not available.
) at /usr/src/lib/libc/string/strlcpy.c:36
#1  0x0000137aff002d5f in ?? () from /usr/sbin/kvm_mkdb
#2  0x0000137aff0030c6 in ?? () from /usr/sbin/kvm_mkdb
#3  0x0000137aff002864 in ?? () from /usr/sbin/kvm_mkdb
#4  0x0000137aff002620 in ?? () from /usr/sbin/kvm_mkdb
#5  0x0000137aff00213b in ?? () from /usr/sbin/kvm_mkdb
#6  0x0000000000000000 in ?? ()
(gdb) quit

[jggimi]

Your backtrace shows only a call to strlcpy(3), a C library function. There are three calls to the function within the source code:

$ cd /usr/src/usr.sbin/kvm_mkdb
$ grep -n strlcpy *.c
kvm_mkdb.c:95:  strlcpy(dbdir, _PATH_VARDB, sizeof(dbdir));
kvm_mkdb.c:102:                 rval = strlcpy(dbdir, optarg, sizeof(dbdir));
nlist.c:218:            strlcpy(buf + 1, strtab + sbuf.st_name, sizeof buf - 1);
 $

As noted earlier in the thread, a .core file produced by a binary with debugging symbols (compiled with -g) can help you determine which of these three are involved. The lack of variables in the trace is likely due to compiler optimizations, so compiling without optimizations (compiled with -O0) may also help.

Assuming you have the source tree and your user is a member of both the wsrc and the wobj groups:

$ cd /usr/src/usr.sbin/kvm_mkdb
$ make obj
$ make DEBUG="-g -O0"
cc -O2 -pipe -g -O0 -Werror-implicit-function-declaration -MD -MP  -c /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c
cc -O2 -pipe -g -O0 -Werror-implicit-function-declaration -MD -MP  -c /usr/src/usr.sbin/kvm_mkdb/nlist.c
cc -O2 -pipe -g -O0 -Werror-implicit-function-declaration -MD -MP  -c /usr/src/usr.sbin/kvm_mkdb/testdb.c
cc -g -O0  -o kvm_mkdb kvm_mkdb.o nlist.o testdb.o
$ cd obj
$ gdb kvm_mkdb
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.6"...
(gdb) break main
Breakpoint 1 at 0x2359: file /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c, line 68.
(gdb) run
Starting program: /usr/obj/usr.sbin/kvm_mkdb/kvm_mkdb 
Breakpoint 1 at 0x3620eb80359: file /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c, line 68.
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]

Breakpoint 1, main (argc=1, argv=0x7f7ffffe8188) at /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c:68
68              gid_t kvm_gid = -1;
Current language:  auto; currently minimal
(gdb) n
69              int fd, rval, ch, verbose = 0;
(gdb)

After setting a breakpoint at main() from here I can step through the program line-by-line -- I did step once with a (n)ext command. I can inspect variables, look at data structures, etc. And yes, I get the same DWARF version error with library symbols you saw.

---

Notes on compiling OS userland programs to debug them:

1. To obtain the source tree, see the release(8) man page. Additional information may be found in FAQ 5 on compiling from source.
2. $DEBUG is normally an empty string, included in $CFLAGS. You can see this with $ make -V CFLAGS and $ make -V DEBUG in any of the OS programs' top-level source directory (containing a Makefile).
3. $ make obj creates the correct local "obj" symbolic link to and structure in /usr/obj/, and requires the user to have membership in both the wsrc and wobj groups.

[jggimi]

I found this recommendation on misc@ to use the more modern gdb package and its "egdb" binary on architectures that build with clang. That will eliminate the DWARF version error message.

I've previously used egdb with ports written in C++, and sometimes gdb(1) for built-in utilities. But that gdb() use was before the transition to clang.

[shep]

Great guide - took longer to cvs the src than to generate the output.

Used the native gdb. If needed, I can install/run w/egdb.

Script started on Tue Nov 12 10:21:56 2019
Kanga# gdb kvm_mkdb
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.6"...
(gdb) breakmmain
Breakpoint 1 at 0x2359: file /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c, line 68.
(gdb) run
Starting program: /usr/obj/usr.sbin/kvm_mkdb/kvm_mkdb
Breakpoint 1 at 0x1a480da359: file /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c, line 68.
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]

Breakpoint 1, main (argc=1, argv=0x7f7ffffe1bc8) at /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c:68
68		gid_t kvm_gid = -1;
Current language:  auto; currently minimal
(gdb) n
69		int fd, rval, ch, verbose = 0;
(gdb) n
73		if (pledge("stdio rpath wpath cpath fattr getpw flock id unveil", NULL) == -1)
(gdb) n
77		if ((gr = getgrnam("kmem")) == NULL) {
(gdb) n
80			kvm_gid = gr->gr_gid;
(gdb) n
81			if (setresgid(kvm_gid, kvm_gid, kvm_gid) == -1)
(gdb) n
0x0000001a480da400 in main (argc=1, argv=0x7f7ffffe1bc8) from /usr/obj/usr.sbin/kvm_mkdb/kvm_mkdb
(gdb) n
Single stepping until exit from function main,
which has no line number information.

Program received signal SIGSEGV, Segmentation fault.
_libc_strlcpy (dst=Variable "dst" is not available.
) at /usr/src/lib/libc/string/strlcpy.c:36
36				if ((*dst++ = *src++) == '\0')
(gdb) nill

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) kill
The program is not being run.
(gdb) quit
Kanga# col -b < typescript > backtrace-kvm-mkdb.txt

[jggimi]

The last visible stepped line in your output, #81, is highlighted below:

	/* Try to use the kmem group to be able to fchown() in kvm_mkdb(). */
	if ((gr = getgrnam("kmem")) == NULL) {
		warn("can't find kmem group");
	} else {
		kvm_gid = gr->gr_gid;
		if (setresgid(kvm_gid, kvm_gid, kvm_gid) == -1)
			err(1, "setresgid");
	}

That's setresuid(2), a syscall. A backtrace might show what happened between returning from that syscall and the later failure.

[shep]

Script started on Tue Nov 12 11:40:46 2019
Kanga# gdb kvm_mkdb
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.6"...
(gdb) break main
Breakpoint 1 at 0x2359: file /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c, line 68.
(gdb) run
Starting program: /usr/obj/usr.sbin/kvm_mkdb/kvm_mkdb
Breakpoint 1 at 0x83c963f2359: file /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c, line 68.
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]

Breakpoint 1, main (argc=1, argv=0x7f7ffffedb58) at /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c:68
68		gid_t kvm_gid = -1;
Current language:  auto; currently minimal
(gdb) n
69		int fd, rval, ch, verbose = 0;
(gdb) n
73		if (pledge("stdio rpath wpath cpath fattr getpw flock id unveil", NULL) == -1)
(gdb) n
77		if ((gr = getgrnam("kmem")) == NULL) {
(gdb) n
80			kvm_gid = gr->gr_gid;
(gdb) n
81			if (setresgid(kvm_gid, kvm_gid, kvm_gid) == -1)
(gdb) n
0x0000083c963f2400 in main (argc=1, argv=0x7f7ffffedb58) from /usr/obj/usr.sbin/kvm_mkdb/kvm_mkdb
(gdb) n
Single stepping until exit from function main,
which has no line number information.

Program received signal SIGSEGV, Segmentation fault.
_libc_strlcpy (dst=Variable "dst" is not available.
) at /usr/src/lib/libc/string/strlcpy.c:36
36				if ((*dst++ = *src++) == '\0')
(gdb) bt
#0  _libc_strlcpy (dst=Variable "dst" is not available.
) at /usr/src/lib/libc/string/strlcpy.c:36
#1  0x0000083c963f3495 in __elf_knlist (fd=6, db=0x83f55384800, ksyms=1) at /usr/src/usr.sbin/kvm_mkdb/nlist.c:218
#2  0x0000083c963f3851 in create_knlist (name=0x83c963f1136 "/dev/ksyms", fd=6, db=0x83f55384800)
    at /usr/src/usr.sbin/kvm_mkdb/nlist.c:316
#3  0x0000083c963f2b81 in kvm_mkdb (fd=6, dbdir=0x7f7ffffed6a0 "/var/db/", nlistpath=0x83c963f1136 "/dev/ksyms",
    nlistname=0x83f41f329d0 "bsd", gid=2, verbose=0) at /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c:201
#4  0x0000083c963f2800 in main (argc=0, argv=0x7f7ffffedb60) at /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c:143
(gdb) bt
#0  _libc_strlcpy (dst=Variable "dst" is not available.
) at /usr/src/lib/libc/string/strlcpy.c:36
#1  0x0000083c963f3495 in __elf_knlist (fd=6, db=0x83f55384800, ksyms=1) at /usr/src/usr.sbin/kvm_mkdb/nlist.c:218
#2  0x0000083c963f3851 in create_knlist (name=0x83c963f1136 "/dev/ksyms", fd=6, db=0x83f55384800)
    at /usr/src/usr.sbin/kvm_mkdb/nlist.c:316
#3  0x0000083c963f2b81 in kvm_mkdb (fd=6, dbdir=0x7f7ffffed6a0 "/var/db/", nlistpath=0x83c963f1136 "/dev/ksyms",
    nlistname=0x83f41f329d0 "bsd", gid=2, verbose=0) at /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c:201
#4  0x0000083c963f2800 in main (argc=0, argv=0x7f7ffffedb60) at /usr/src/usr.sbin/kvm_mkdb/kvm_mkdb.c:143
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) quit
Kanga# col -b < typescript > bt_kvm

I think the variable "dst" has to do with daylight savings time. I read in the mailing lists that ntpd is currently being revised. I have the correct date/time via the date command.

[jggimi]

No, dst is the destination address. See the man page for strlcpy(3). The caller was nlist.c, line 218, according to your backtrace.

		*buf = '_';
		strlcpy(buf + 1, strtab + sbuf.st_name, sizeof buf - 1);
		key.data = (u_char *)buf;
		key.size = strlen((char *)key.data);
		if (db->put(db, &key, &data, 0))
			err(1, "record enter");

Line 70 shows buf is a 1024-byte character string. From my poor skills with C, I expect the buf variable is assigned the value of an underscore character, then the address of buf plus 1 byte is mapped to strlcopy's first variable, dst.

I assume dst is not available because the C library is optimized, and it's value existed ephemerally in a CPU register rather than being stored in slow RAM where gdb can find it.

You can set a breakpoint in nlist prior to the library call to examine variables.

[shep]

I hope I enter break nlist in the right sequence.

Kanga# scriptipt
Script started, output file is typescript
Kanga# gdb kvm_mkdb
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.6"...
(gdb) run
Starting program: /usr/obj/usr.sbin/kvm_mkdb/kvm_mkdb
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]

Program received signal SIGSEGV, Segmentation fault.
_libc_strlcpy (dst=Variable "dst" is not available.
) at /usr/src/lib/libc/string/strlcpy.c:36
36				if ((*dst++ = *src++) == '\0')
Current language:  auto; currently minimal
(gdb) break nlist
Breakpoint 1 at 0x75a82910789: file /usr/src/lib/libc/gen/nlist.c, line 295.
(gdb) n

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) bt
No stack.
(gdb) quit
Kanga# run kvm_mkdb
Starting program: /usr/obj/usr.sbin/kvm_mkdb/kvm_mkdb
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]

Program received signal SIGSEGV, Segmentation fault.
_libc_strlcpy (dst=Variable "dst" is not available.
) at /usr/src/lib/libc/string/strlcpy.c:36
36				if ((*dst++ = *src++) == '\0')
Current language:  auto; currently minimal
(gdb) break nlist
Breakpoint 1 at 0x75a82910789: file /usr/src/lib/libc/gen/nlist.c, line 295.
(gdb) n

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) bt
No stack.
(gdb) quit
Kanga# col -bm<mtype

[jggimi]

No, I recommend breaking right before the failed strlcopy. Here's an example of inspecting variables with egdb, because Todd Miller was right, the built-in gdb(1) is too old for clang compiled objects. It wasn't geting variable lengths correct when I inspected them.

You can see the character array buf before and after strlcpy(3), which is used as the dst operand in the library call, as well as the values in the src and datasize fields used in the strlcpy(). Looks good from here:

# egdb kvm_mkdb
 GNU gdb (GDB) 7.12.1
Copyright (C) 2017 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-unknown-openbsd6.6".
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 kvm_mkdb...done.
(gdb) br nlist.c:217
Breakpoint 1 at 0x346e: file /usr/src/usr.sbin/kvm_mkdb/nlist.c, line 217.
(gdb) r
Starting program: /usr/obj/usr.sbin/kvm_mkdb/kvm_mkdb

Breakpoint 1, __elf_knlist (fd=3, db=0x825185e1e80, ksyms=1) at /usr/src/usr.sbin/kvm_mkdb/nlist.c:217
217            *buf = '_';
(gdb) p buf
$1 = "(*\016\000\000\000\000\000(*\016\000\000\000\000\000@\001\000\000\000\000\000\000@\001\000\000\000\000\000\000\b\000\000\000\000\000\000\000R\345td\004\000\000\000\000\340\r\000\000\000\000\000\000\340\r\000\000\000\000\000\000\340\r\000\000\000\000\000\300L\000\000\000\000\000\000\000P\000\000\000\000\000\000\001\000\000\000\000\000\000\000P\345td\004\000\000\000D#\002\000\000\000\000\000D#\002\000\000\000\000\000D#\002\000\000\000\000\000\324\064\000\000\000\000\000\000\324\064\000\000\000\000\000\000\004\000\000\000\000\000\000\000\346\333\243e\006\000\000\000)\036\376\377\377\376\000\000\003\000\000\000\000\000\000\000\030\000\000\000\060\000\000\000p\025\377\377\177\177\000\000p\024\377\377\177\177\000\000"...
(gdb) n
218            strlcpy(buf + 1, strtab + sbuf.st_name, sizeof buf - 1);
(gdb) p buf
$2 = "_*\016\000\000\000\000\000(*\016\000\000\000\000\000@\001\000\000\000\000\000\000@\001\000\000\000\000\000\000\b\000\000\000\000\000\000\000R\345td\004\000\000\000\000\340\r\000\000\000\000\000\000\340\r\000\000\000\000\000\000\340\r\000\000\000\000\000\300L\000\000\000\000\000\000\000P\000\000\000\000\000\000\001\000\000\000\000\000\000\000P\345td\004\000\000\000D#\002\000\000\000\000\000D#\002\000\000\000\000\000D#\002\000\000\000\000\000\324\064\000\000\000\000\000\000\324\064\000\000\000\000\000\000\004\000\000\000\000\000\000\000\346\333\243e\006\000\000\000)\036\376\377\377\376\000\000\003\000\000\000\000\000\000\000\030\000\000\000\060\000\000\000p\025\377\377\177\177\000\000p\024\377\377\177\177\000\000"...
(gdb) p sizeof buf
$3 = 1024
(gdb) p strtab
$4 = (caddr_t) 0x825df03c000 ""
(gdb) p sbuf.st_name
$5 = 1
(gdb) p strtab + sbuf.st_name
$6 = 0x825df03c001 "bi_size_ok"
(gdb) n
219            key.data = (u_char *)buf;
(gdb) p buf
$7 = "_bi_size_ok\000\000\000\000\000@\001\000\000\000\000\000\000@\001\000\000\000\000\000\000\b\000\000\000\000\000\000\000R\345td\004\000\000\000\000\340\r\000\000\000\000\000\000\340\r\000\000\000\000\000\000\340\r\000\000\000\000\000\300L\000\000\000\000\000\000\000P\000\000\000\000\000\000\001\000\000\000\000\000\000\000P\345td\004\000\000\000D#\002\000\000\000\000\000D#\002\000\000\000\000\000D#\002\000\000\000\000\000\324\064\000\000\000\000\000\000\324\064\000\000\000\000\000\000\004\000\000\000\000\000\000\000\346\333\243e\006\000\000\000)\036\376\377\377\376\000\000\003\000\000\000\000\000\000\000\030\000\000\000\060\000\000\000p\025\377\377\177\177\000\000p\024\377\377\177\177\000\000"...
(gdb)

[jggimi]

For clarity when reading (e)gdb output, the line-of-code shown in each breakpoint or step has not yet been executed. So the breakpoint at line 217 is before the underscore character is assigned to buf.

[shep]

I was unable to pkg_add gdb - Unknown element: @static-lib lib/python3.7m/libpython3.7m.a in SCALAR(0xa888a3db328),

I tried building from ports and that failed. Python 3 seems to be transitioning 3.7 -> 3.8. Installed the latest snapshot and still get the same pkg_add error. Still get the same Seqmentation fault on the new install. Will try again in a couple of days.

[jggimi]

Meanwhile, you could practice with egdb on one of your -release systems, to help gain familiarity with the debugger.

Like many complex gnu tools, the detailed user documentation exists in Info format.

I have struggled with the info(1) user interface required for Info docs. For decades. Only in the last couple of weeks I learned that one can actually get useful information from info(1). Just by piping the snot out of it.

So, $ info gdb | less will work for the built-in gdb(1), and once you have the package installed, $ info -d /usr/local/info gdb | less will work for the modern gdb.

[shep]

The Segmentation Fault occurs on an ASrock j3355m motherboard with a known problematic BIOS. Based on this thread:

http://openbsd-archive.7691.n7.nabbl...-td253125.html

I did an experiment where I swapped the hard drive, from an Asus M68 motherboard that had the same Crux/OpenBSD dualboot install. It bypassed Grub2, booted directly into OpenBSD but did not give the segmentation fault. Kernel relinking failed. I was able to restore relinking when I returned the drive to the Asus Mobo and ran sha256 -h /var/db/kernel.SHA256 /bsd command.

My suspicion is that part, if not all of the problem, is the GPT/MBR boot table location/structure. I debated formating the ASrock j3355m drive on another system but would have to accept kernel that do not relink. The other thought is just trying MBR partitions with csm enabled in the bios.

The ASrock j3355m board was bought as a cheap system that I could abuse (test other OS/Dual booting/Simple ports etc) without investing alot of $$$.at < 20 watts TDP..

[jggimi]

You may have the same motherboard, but the symptoms presented are completely different.

[shep]

With MBR partitioning on the j3355m, Dual boot generates no Segmentation Faults and relinks without error. Not really a fix but would the project really be motivated to accommodate, buggy, non-standard uefi dual booting MOBO's?

Still I learned about getting a window into running code via gdb and stepping through it. Thanks @jggimi.