ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/mesh/adv.c

RE: ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/mesh/adv.c

a.da — Wed, 15 Jan 2025 06:45:06 GMT

This is an update.

After modifying "proxy_msg.c" attached to the pull request, the issue with be unable to allocate beacon adv has been resolved.
I merged the changes committed to "zephyrproject-rtos:main".

static void proxy_msg_send_pending(struct k_work *work)
{
	struct bt_mesh_proxy_role *role = CONTAINER_OF(work, struct bt_mesh_proxy_role, work);
	struct bt_mesh_adv *adv;

	if (!role->conn) {
		return;
	}

	adv = proxy_queue_get(role);
	if (!adv) {
		return;
	}

After using the modified "proxy_msg.c", the fatal error mentioned in the title has not occurred so far.
I will continue to monitor the situation.

Thank you for your support.

a.da

RE: ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/mesh/adv.c

a.da — Wed, 15 Jan 2025 01:27:25 GMT

Hi Terje,

Unfortunately, the situation has worsened.
I overwrote the file attached to the pull request with the Light fixture SDK sample.
It’s just "adv.h" and "proxy_msg.c".
When I provisioned it using the "nRF Mesh" app, it was unable to allocate beacon adv.

[00:00:29.251,403] <dbg> bt_mesh_access: bt_mesh_model_recv: app_idx 0xfffe src 0x0001 dst 0x06b5
[00:00:29.251,464] <dbg> bt_mesh_access: bt_mesh_model_recv: len 3: 800800
[00:00:29.251,464] <dbg> bt_mesh_access: bt_mesh_model_recv: OpCode 0x00008008
[00:00:29.293,182] <dbg> bt_mesh_access: bt_mesh_access_send: net_idx 0x0000 app_idx 0xfffe dst 0x0001
[00:00:29.293,273] <dbg> bt_mesh_access: bt_mesh_access_send: len 52: 0200590000000000ff00070001000d0000000200021000100410061007100013011303120412001101110200030000100f131013
[00:00:31.339,904] <err> bt_mesh_beacon: Unable to allocate beacon adv
[00:00:31.339,904] <err> bt_mesh_beacon: Failed to advertise subnet 0: err -12

devzone.nordicsemi.com/.../250115_5F00_adv.log

It seems that other files committed to "zephyrproject-rtos:main" are also needed.
However, I have not been able to identify which ones they are.
I will continue the investigation, so could you please provide support?

Just to keep you informed.

a.da

RE: ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/mesh/adv.c

tesc — Tue, 14 Jan 2025 14:01:27 GMT

Hi,

Thank you for the additional information. We now have a fix, in the following pull request: https://github.com/zephyrproject-rtos/zephyr/pull/83934. The changes are listed on the files changed page of that pull request.

Please check if applying those changes fixes the issue also for your application.

Regards,
Terje

RE: ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/mesh/adv.c

a.da — Fri, 10 Jan 2025 07:14:28 GMT

Hi Terje,

I stripped it down to a minimal example. Please overwrite the Light fixture SDK sample.

devzone.nordicsemi.com/.../8117.project.zip

The issue also occurred when receiving two SIG Model Messages and one Vendor Model Message.
Light Lightness Get, Light CTL Temperature Get, and one more.
This is a log from the 1st boot to the occurrence of the Fatal Error, using a minimal example.
Some of the data is masked.
The issue occurred on the 6th transmission after binding the Application Key, line 1001.

devzone.nordicsemi.com/.../250110_5F00_adv.log

The issue could not be reproduced in the "nRF Mesh", as there is no way to send messages simultaneously.
Can the investigation continue with this information?
Please let me know if you need anything else.

a.da

RE: ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/mesh/adv.c

a.da — Fri, 10 Jan 2025 01:16:18 GMT

Hi Terje,

Project:
Our project is a custom application based on SDK samples(Light fixture).
The "prj.conf" has been modified based on the sample.
The smartphone app is not "nRF Mesh," it is custom-built(iOS).

Steps to reproduce:
There is one device in the mesh network.
The smartphone app sends four Mesh Messages simultaneously.
0x82 0x4b Light Lightness Get,
0x82 0x61 Light CTL Temperature Get,
and two Vendor Model Message that requests a status response like "Light Lightness Get".
But it doesn't happen every time.

First, I will strip it down to a minimal example that is closer to the sample.
I will also consider applying the pull request.
Please give me a moment.

Kind regards,

a.da

RE: ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/mesh/adv.c

tesc — Thu, 09 Jan 2025 10:10:27 GMT

Hi,

What are the steps to reproduce the issue? If this only happens on a custom project, we would highly appreciate if you strip it down to a minimal example still triggering the issue, and send it to us. Please start a private case here on DevZone and send it there, if you do not want to send it in public.

We also need the steps to reproduce, regardless of whether it is for SDK samples or a custom application. E.g. which sample, are there prj.conf changes needed, how to interact with the device in order to trigger the issue.

Alternatively, in the mean time, there is an active pull request for the Bluetooth Mesh stack, which may or may not solve the issue, as it touches on related parts of the stack to the one failing in the issue that you are seeing. Since we have not yet reproduced the issue, we do not know whether this pull request fixes it or not, but I guess you could try applying those changes in your end and see if it resolves the issue. Please note that since this is from the latest branch of Zephyr / nRF Connect SDK, some (maybe undocumented) migration may be needed.

Please note that we would still like the steps to reproduce, so that we can check this also in our end, as well as investigate further if other changes are needed.

Regards,
Terje

RE: ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/mesh/adv.c

a.da — Thu, 09 Jan 2025 00:18:26 GMT

Hi Terje,

Thank you for your continued support. I will respond as quickly as possible as well.

Kind regards,

a.da

RE: ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/mesh/adv.c

tesc — Wed, 08 Jan 2025 13:25:41 GMT

Hi,

Thank you for the report, it is highly appreciated.

You have done some thorough investigations and provided us with what looks like the relevant information. Hopefully this is enough for us to figure out what leads to the assert. I will ask for more information here in this thread, if we need more.

From what I can tell, this type of issue is most likely a bug in the stack itself. Configuration changes may or may not change the prevalence of the issue, but we will likely not know until we find the root cause. I am afraid I do not have any time estimate for when we will know more, but rest assured we are looking into the issue and I will provide an update here when more is known at our side.

Regards,
Terje

RE: ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/mesh/adv.c

Naeem Maroof — Tue, 31 Dec 2024 03:04:02 GMT

Hi,

I am not able to locate the cause for this issue. I will transfer the case to some BLE Mesh expert. However, please note that this is holiday season in Norway and most of engineers are away till 6th of Jan. It might take few days to reach back to you.

Thank you for your understanding and regards,