Illegal hardware instruction on dub describe with a custom dub configuration

[ljmf00]

trafficstars

I got a SIGILL (illegal hardware instruction) when I do this command: dub describe -c unittest --nodeps --skip-registry=all --arch=x86_64.

EDIT: I deeply searched and it seems that "targetType": "autodetect", is causing the error.

Seems it's related to the configuration I run/have for unittest .

System information

• dub version: 1.19.0
• OS Platform and distribution: Arch Linux
• Linux Kernel version: 5.5.3-arch1-1
• compiler version Not applicable

Config

{
	"name": "dsqllint",
	"sourcePaths": ["source"],
	"importPaths": ["source"],
	"targetPath": ".out",
	"targetType": "executable",
	"dependencies": {
		"aurorafw:stdx": "0.0.1-alpha.4"
	},
	"configurations": [
		{
			"name": "default"
		},
		{
			"name": "unittest",
			"targetType": "autodetect",
			"sourcePaths": ["tests/source"],
			"importPaths": [
				"tests/source"
			],
			"dependencies": {
				"aurorafw:unit": "0.0.1-alpha.4"
			}
		}
	]
}

Logs

Refreshing local packages (refresh existing: true)...
Looking for local package map at /var/lib/dub/packages/local-packages.json
Looking for local package map at /home/luis/.dub/packages/local-packages.json
Looking for local package map at /home/luis/Workspace/Programming/FromScratch/Git/Gitlab/aurorafossorg/utils/dsqllint/.dub/packages/local-packages.json
iterating dir /home/luis/.dub/packages/
iterating dir /home/luis/.dub/packages/ entry riverd-soundio-1.0.1
iterating dir /home/luis/.dub/packages/ entry riverd-sndfile-1.0.1
iterating dir /home/luis/.dub/packages/ entry riverd-core-1.0.1
iterating dir /home/luis/.dub/packages/ entry riverd-loader-1.0.2
iterating dir /home/luis/.dub/packages/ entry riverd-xcursor-1.0.1
iterating dir /home/luis/.dub/packages/ entry reggae-0.6.7
iterating dir /home/luis/.dub/packages/ entry riverd-x11-0.1.2
iterating dir /home/luis/.dub/packages/ entry riverd-xxf86vm-1.0.1
iterating dir /home/luis/.dub/packages/ entry aurorafw-0.0.1-alpha.4
iterating dir /home/luis/.dub/packages/ entry riverd-ncurses-1.0.5
iterating dir /home/luis/.dub/packages/ entry hidapi-d-1.0.3
iterating dir /home/luis/.dub/packages/ entry unit-threaded-0.10.5
'git --git-dir=/home/luis/Workspace/Programming/FromScratch/Git/Gitlab/aurorafossorg/utils/dsqllint/.git describe --long --tags' failed with exit code 128: fatal: No names found, cannot describe anything.
Determined package version using GIT: dsqllint ~mv-impl
[1]    1058830 illegal hardware instruction (core dumped)  dub describe -c unittest --nodeps --skip-registry=all --arch=x86_64 --vverbos

NOTE: Here i'm using --vverbose option.

[ljmf00]

@s-ludwig, @MartinNowak or @wilzbach do you have an hint on this behavior? Sorry for tagging you all, just because you are the most active developers on dub and this is here for a while.

I don't have a clue why is this happening, but if you want to give me a starting point, I could dig into the code and make a PR if I found something valuable.

[MartinNowak]

Try to run the command with gdb (debugger) so you can see where it actually fails. Sounds more like a compiler error somewhere.

[ljmf00]

Try to run the command with gdb (debugger) so you can see where it actually fails.

Weird behavior, I tried to compile dub in debug mode, and it's working as expected. The problem should be in the code generation when -release is applied. Even with optimizations (-O5) it runs fine.

Currently I'm using the parameters from the package on Arch Linux, https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dub#n26 . By removing -release from ldmd2 -ofbin/dub -release -O5 -version=DubUseCurl -Isource -L-lcurl -L="$LDFLAGS" -release -flto=full -linker=gold -link-defaultlib-shared=false -L--build-id @build-files.txt the command I described initially returns

Configurations must have a concrete target type, dsqllint has autodetect

which should be, in my perspective, the intended behavior.

I don't know if the backtrace in release mode is really helpful, but here is what I got:

(gdb) r describe -c unittest --nodeps --skip-registry=all --arch=x86_64
Starting program: /usr/bin/dub describe -c unittest --nodeps --skip-registry=all --arch=x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Detaching after fork from child process 26001]
[Detaching after fork from child process 26002]
[Detaching after fork from child process 26003]
[Detaching after fork from child process 26004]
[Detaching after fork from child process 26005]

Program received signal SIGILL, Illegal instruction.
0x00005555556999c3 in ?? ()
(gdb) bt
#0  0x00005555556999c3 in ?? ()
#1  0x0000555555596cdb in ?? ()
#2  0x000055555559697e in ?? ()
#3  0x00005555555ef4e5 in ?? ()
#4  0x00005555557047fc in ?? ()
#5  0x0000555555718483 in ?? ()
#6  0x0000555555778e9c in ?? ()
#7  0x0000555555778d93 in ?? ()
#8  0x0000555555778bee in ?? ()
#9  0x00007ffff7bcf023 in __libc_start_main () from /usr/lib/libc.so.6
#10 0x00005555555944ee in ?? ()

Disassembling near the stopped address:

Dump of assembler code from 0x5555557ce046 to 0x5555557ce06e:
   0x00005555557ce046:	lea    -0x2(%rax),%esi
   0x00005555557ce049:	(bad)  
   0x00005555557ce04a:	decl   0x63(%rax)
   0x00005555557ce04d:	adc    $0x88,%al
   0x00005555557ce04f:	add    %rax,%rdx
   0x00005555557ce052:	jmpq   *%rdx
   0x00005555557ce054:	jmp    0x5555557ce056
=> 0x00005555557ce056:	ud2    
   0x00005555557ce058:	jmp    0x5555557ce05a
   0x00005555557ce05a:	xor    %eax,%eax
   0x00005555557ce05c:	mov    %eax,%ecx
   0x00005555557ce05e:	mov    %rcx,%rax
   0x00005555557ce061:	mov    %rcx,%rdx
   0x00005555557ce064:	add    $0x190,%rsp
   0x00005555557ce06b:	pop    %rbp
   0x00005555557ce06c:	retq   
   0x00005555557ce06d:	jmp    0x5555557ce06f

Should the compiler generate ud2 instructions?

Sounds more like a compiler error somewhere.

In conclusion, I would say that.

[Geod24]

It doesn't sound like a compiler error. assert(0) are turned into HLT (or apparently, ud2) on -release. The error you mention points to here: https://github.com/dlang/dub/blob/85b710b7bd1486fbe3f45ce516c0484ef24617eb/source/dub/compilers/dmd.d#L259

(I'm linking DMD but all 3 compilers have a similar assert). Since assert should not be hit, ever, there's two possible fixes for this:

1. Either the assert should be a throw / enforce statement as it is the right place to validate an environmental (in this case, config file) error;
2. Or the assert is correct and the environmental error should have been caught before;