Fix 'zdb -o' segmentation fault

[loli10K]

Motivation and Context

Since the integration of ed828c0 (OpenZFS 7280 - Allow changing global libzpool variables in zdb and ztest through command line) zdb has been segfaulting consistently while running "zdb_001_neg" in the ZTS.

It looks like glibc doesn't handle NULL as the first parameter to strchr():

root@debian-8-zfs:~# gdb -q -ex 'file zdb' -ex 'run -o'
Reading symbols from zdb...done.
Starting program: /usr/sbin/zdb -o
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
32	../sysdeps/x86_64/multiarch/../strchr.S: No such file or directory.
(gdb) bt
#0  __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
#1  0x00007ffff72dbac6 in set_global_var (arg=0x0) at util.c:185
#2  0x0000000000414ebc in main (argc=2, argv=0x7fffffffece8) at zdb.c:4125
(gdb) up
#1  0x00007ffff72dbac6 in set_global_var (arg=0x0) at util.c:185
185		if ((varval = strchr(arg, '=')) != NULL) {
(gdb) p arg
$1 = 0x0
(gdb) 

Illumos libc has a different behaviour (https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/i386/gen/strchr.s#L39):

	ENTRY(strchr)
	mov 4(%esp), %ecx		/ src string here
	mov 8(%esp), %edx		/ character to find
	mov %ecx, %eax			/ save src
	and $3, %ecx			/ check if src is aligned
	jz prepword			/ search wordwise if it is

	cmpb %dl, (%eax)		/ src == char?
	jz done
	cmpb $0, (%eax)			/ src == 0?
	jz not_found

Maybe this is implementation specific? Anyway, since we can't force the libc on the user i think we should handle this.

How Has This Been Tested?

Manual testing

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• Change has been approved by a ZFS on Linux member.

[mention-bot]

@loli10K, thanks for your PR! By analyzing the history of the files in this pull request, we identified @behlendorf, @tonyhutter and @heary-cao to be potential reviewers.

[behlendorf]

LGTM.