'net help' or 'kernel help' shell commands lead to a fatal fault

[tbursztyka]

uart:~$ net help
net - Networking commands
Options:
-h, --help :Show command help.
Subcommands:
allocs :Print network memory allocations.
app :Print network application API usage information.
arp :Print information about IPv4 ARP cache.
conn :Print information about network connections.
dns :Show how DNS is configured.
gptp :Print information about gPTP support.
http :Print information about active HTTP connections.
iface :Print information about network interfaces.
ipv6 :Print information about IPv6 specific information and configuration.
mem :Print information about network memory usage.
nbr :Print neighbor information.
ping :Ping a network host.
route :Show network route.
rpl :Show RPL mesh routing status.
stacks :Show network stacks information.
stats :Show network statistics.
tcp :Connect/send/close TCP connection.
vlan :S***** USAGE FAULT *****
Illegal use of the EPSR
***** Hardware exception *****
Current thread ID = 0x204003c0
Faulting instruction address = 0x0
Fatal fault in thread 0x204003c0! Aborting.

[jukkar]

What sample application you are using here?

I tried "net help" in echo-server sample and I see no errors.

[aurel32]

This is a generic shell issue, i can reproduce the problem with the shell_module sample running kernel help on both SAM E70 and Nucleo L432KC:

uart:~$ kernel help
kernel - Kernel commands
Options:
  -h, --help  :Show command help.
Subcommands:
  cycles   :Kernel cycles.
  uptime   :Kernel uptime.
  version  :Kernel versi
    ***** USAGE FAULT *****
  Illegal use of the EPSR
***** Hardware exception *****
Current thread ID = 0x20000634
Faulting instruction address = 0x0
Fatal fault in thread 0x20000634! Aborting.

[aurel32]

bisected to:

a89690d10f175cac792c829ed042c0e6f65eb4e2 is the first bad commit
commit a89690d10f175cac792c829ed042c0e6f65eb4e2
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Tue Nov 6 15:34:11 2018 +0200

    shell: Add APIs to set number of arguments
    
    This allows the shell core to perform precheck before calling the
    handler which then can assume the number of arguments is correct.
    
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>

:040000 040000 de27efd5ded816083a17ccfaecb5acf25bcfcc31 cd208c117cceb20788ced161eb37484ba0e13a3d M      doc
:040000 040000 916c3871afef6373299d89ff7d4090a71bae2d24 e5980db374dbffff2db2558f0fa749d977b15cb7 M      include
:040000 040000 b28506ccd04e6c55f23f73a7cf178bd7df073835 7da4f08ab9314920cb28809628b6044824aaf6a3 M      subsys

@Vudentz, could you please have a look?

[qianfan-Zhao]

This issue happens after 'shell_help_print'.

If print help message by using someting like this: 'kernel help', 'net help' or sometings in this way, can trigger 'shell_help_print'.
If a command need params but don't input any on the shell such as 'demo' also can trigger shell_help_print.

The exec_cmd function doesn't exit after shell_help_print, shell->ctx->active_cmd.handler is a NULL pointer, after that the next code try do active_cmd.handler, the BUG happens.

static int exec_cmd(const struct shell *shell, size_t argc, char **argv)
{
	int ret_val = 0;

	if (shell->ctx->active_cmd.handler == NULL) {
		if (shell->ctx->active_cmd.help) {
			shell_help_print(shell, NULL, 0);
		} else {
			shell_fprintf(shell, SHELL_ERROR,
				      SHELL_MSG_SPECIFY_SUBCOMMAND);
			ret_val = -ENOEXEC;
			goto clear;
		}
	}

...

	if (!ret_val) {
		ret_val = shell->ctx->active_cmd.handler(shell, argc, argv);
	}

clear:
	help_flag_clear(shell);

	return ret_val;
}

[qianfan-Zhao]

Besides can we provide a way to report bug on NULL dereference at runtime?

An idea of my own: Mark the address 0 as unacessed by using MPU?