# running dlang dub crashes the kernel



## Alain De Vos (Oct 14, 2021)

Running dlang dub crashes the kernel.
Currently compiling llvm without "GOLD" to see if that fixes .
My make.conf

```
DEFAULT_VERSIONS+=ssl=openssl 
DEFAULT_VERSIONS+=llvm=12 
DEFAULT_VERSIONS+=gcc=10 
DEFAULT_VERSIONS+=lua=5.4 
DEFAULT_VERSIONS+=lua5=5.4 
DEFAULT_VERSIONS+=perl=5.34 
DEFAULT_VERSIONS+=perl5=5.34 
DEFAULT_VERSIONS+=python=3.8 
DEFAULT_VERSIONS+=python3=3.8 
DEFAULT_VERSIONS+=ruby=2.7 
DEFAULT_VERSIONS+=ruby2=2.7 
DEFAULT_VERSIONS+=pgsql=13 
DEFAULT_VERSIONS+=mysql=10.5m 
DEFAULT_VERSIONS+=php=8.0 
DEFAULT_VERSIONS+=tcltk=8.6
```


----------



## _martin (Oct 14, 2021)

Do you have dumps available ? If so paste the info from the /var/crash/info.N where N is the number from your last crash. Check if messages don't have something useful just before the crash. Also share what version of FreeBSD are you running and if you are on GENERIC kernel.


----------



## Alain De Vos (Oct 28, 2021)

The crash seems to only happen when I am in graphical mode (sway window manager) & when i run dub.
I'm currently compiling everything with to see if problem goes away,

```
DEFAULT_VERSIONS+=gcc=11
DEFAULT_VERSIONS+=llvm=13
```


----------



## Alain De Vos (Nov 18, 2021)

After some testing running "dub" crashes my kernel, but only when i am in graphical mode (sway/wayland), not in text mode, which is really weird.
Dub is the only "userland application" i know crashing my kernel. Later i'll try to make a corefile ...
I have so much "tuning" , i.e. not the defaults, i don't know where to start ...

In sysctl.conf i have

```
kern.coredump=0                          #disable coredump  
kern.corefile=/dev/null
```

I compiled the kernel with,

```
nooption DEBUG 
nooption        KDB                     # Enable kernel debugger support. 
nooption         KDB_TRACE               # Print a stack trace for a panic. 
nooption         DDB 
nooption         DDB_CTF
```

Need to fix those first.


----------



## _martin (Nov 18, 2021)

Well without those dumps it's anybody's guess.

With such heavily customized kernel it's really good first to test this with GENERIC kernel. You can always save the current kernel or you could unpack the generic one to, let's say /boot/kernel.generic and boot off that. Test and see if you can still reproduce the crash.


----------



## Alain De Vos (Nov 19, 2021)

What i recently did:
src.conf

```
WITHOUT_MALLOC_PRODUCTION=yes
WITH_DEBUG_FILES=yes
WITH_KDUMP=yes
WITH_KERNEL_SYMBOLS=yes
```
sysctl.conf

```
kern.coredump=1               
kern.corefile=/mykernelcore
```
KERNCONF:

```
option DEBUG
option WITH_CTF
option        KDB
opion         GDB
option         KDB_TRACE
option         DDB
option         DDB_CTF
```
rc.conf

```
dumpdev=/dev/ada2p2 
dumpon_enable="YES" 
savecore_enable="YES" 
dumpdir=/
```


----------



## _martin (Nov 19, 2021)

When it comes to bug hunting you should try to trigger it using generic kernel. For dumpdev usually `dumpdev="AUTO"` in /etc/rc.conf is sufficient. Assuming you have swap devices configured. `dumpon -l` will show you currently defined dump devices.
Avoid overwriting defaults if you really don't have specific reason why you need to do so. Sysctl `kern.coredump` is about the userspace coredumps not kernel ones.

Note you have typo in the `option GDB` KERNCONF. Not needed for what you're trying to achieve (gdb/ddb are stubs for online kernel debugging).

If you really don't want to try out generic kernel for some reason (though with PR you should really do that) make sure you have at least dump devices configured and trigger the crash. Once you have it crash you can share the backtrace of it. As it's custom kernel not much can be done you'd know where it crashed.

One of the ways of setting up generic kernel:
	
	



```
cd /tmp
fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/13.0-RELEASE/kernel.txz
mkdir generic
tar -C generic -xvf kernel.txz boot/
mv generic/boot/kernel /boot/kernel.generic
```

Reboot, escape to boot loader (in menu press 3) and do (assuming you have ZFS on / )

```
unload all
load /boot/kernel.generic/kernel
load /boot/kernel.generic/zfs.ko
boot
```


----------



## Alain De Vos (Nov 20, 2021)

In order to be certain to speak about the same things. Currently recompiling the kernel.
This is my complete kernel config:

```
include GENERIC 
ident MYKERNEL_STOCK
```


----------



## _martin (Nov 20, 2021)

Well that would be _a_ way of doing it. But when I said use generic kernel I really meant use official kernel package. You compiling the kernel, be it using GENERIC config, still can produce different code because of other custom settings. It's also a faster way of testing things as you don't need to compile anything. 

I would really, really change dumpdir in /etc/rc.conf to `/var/crash`, i.e. let it be the default location for dumps.


----------



## Alain De Vos (Nov 20, 2021)

After performing additional testing, i seem to have a case of Heisenbug. Trying to observe it and it went away.
I'm gone let allow the crash dumps in /var/crash as it seems to be a handy feature just in case.
And rebuild the kernel with all my tunings to see if i can get the problem back.
If i cannot reproduce it in one week, i will close this thread as solved, i.e. a glitch in the matrix.
For he who is interested this is my currently running KERNCONF

```
nooption DEBUG
nooption WITH_CTF
nooption KDB                     
nooption KDB_TRACE       
nooption GDB
nooption DDB
nooption DDB_CTF
nooption XENHVM                 
nooption NFSCL
nooption NFSD
nooption NFSLOCKD
nooption NFS_ROOT
nooption     COMPAT_FREEBSD4     
nooption     COMPAT_FREEBSD5       
nooption     COMPAT_FREEBSD6      
nooption     COMPAT_FREEBSD7      
nooption     COMPAT_FREEBSD9      
nooption     COMPAT_FREEBSD10
```


----------

