Below is a report from a ZFS/FreeBSD user.
I am not sure what exactly happened but something concerns me in
zcp_convert_return_values() code.
-------------------------------------------------------------------
void
zcp_convert_return_values(lua_State *state, nvlist_t *nvl,
const char *key, zcp_eval_arg_t *evalargs)
{
int err;
lua_pushcfunction(state, zcp_lua_to_nvlist_helper);
lua_pushlightuserdata(state, (char *)key);
lua_pushlightuserdata(state, nvl);
lua_pushvalue(state, 1);
lua_remove(state, 1);
err = lua_pcall(state, 3, 0, 0); /* zcp_lua_to_nvlist_helper */
if (err != 0) {
zcp_lua_to_nvlist(state, 1, nvl, ZCP_RET_ERROR); <==== here
evalargs->ea_result = SET_ERROR(ECHRNG);
}
}
-------------------------------------------------------------------
I am not sure if we can assume anything about state of 'state' after a call to
lua_pcall. I mean that zcp_lua_to_nvlist() assumes that 'state' would have
something expected at index one.
-------- Forwarded Message --------
Subject: ZFS destroy caused panic ? 11.2 (r335771)
Date: Tue, 3 Jul 2018 15:19:43 -0400
From: Mike Tancsa <m...@sentex.net>
To: FreeBSD-STABLE Mailing List <freebsd-sta...@freebsd.org>
I got the following panic while deleting a test snapshot
panic: unprotected error in call to Lua API (Invalid value type
'function' for key 'error')
cpuid = 4
KDB: stack backtrace:
#0 0xffffffff806fb437 at kdb_backtrace+0x67
#1 0xffffffff806b4a57 at vpanic+0x177
#2 0xffffffff806b48d3 at panic+0x43
#3 0xffffffff814500e4 at zcp_panic_cb+0x24
#4 0xffffffff8149b591 at luaD_throw+0x31
#5 0xffffffff814a4042 at luaG_errormsg+0x72
#6 0xffffffff814ae109 at lua_error+0x9
#7 0xffffffff8144f376 at zcp_convert_return_values+0x96
#8 0xffffffff8144ff4f at zcp_eval+0x71f
#9 0xffffffff813fe9f1 at dsl_destroy_snapshots_nvl+0x1b1
#10 0xffffffff81478644 at zfs_ioc_destroy_snaps+0x164
#11 0xffffffff8147f269 at zfsdev_ioctl+0x6f9
#12 0xffffffff80582418 at devfs_ioctl_f+0x128
#13 0xffffffff807174bd at kern_ioctl+0x26d
#14 0xffffffff807171dc at sys_ioctl+0x15c
#15 0xffffffff80945078 at amd64_syscall+0xa38
#16 0xffffffff80923cfd at fast_syscall_common+0x101
I was not able to get a backtrace saved. Any ideas what this might be
about ?
--
-------------------
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/Tb8ec0397edc615b0-M291fda76e6af1ea2edb88dbd
Delivery options: https://openzfs.topicbox.com/groups
