ASSERT_PARAM(-218959118 0), in arch_main.c at line 343 (IDFGH-6126)

Opening - same as https://github.com/espressif/esp-idf/issues/6517. Still occurs in 4.3.1

Same here, it happens to me on 4.2.2.
It is less frequent than it used to be, but it still happens
ASSERT_PARAM(-218959118 0), in arch_main.c at line 343
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0).

Core  0 register dump:
PC      : 0x40088b64  PS      : 0x00060434  A0      : 0x801395d0  A1      : 0x3ffbf8f0
A2      : 0x00000001  A3      : 0x00000000  A4      : 0x60008048  A5      : 0x00000000
A6      : 0x00000004  A7      : 0x3ffbdcb8  A8      : 0x80088b64  A9      : 0x3ffbf8d0
A10     : 0x0000f2f2  A11     : 0x00000037  A12     : 0x00000014  A13     : 0xffffffff
A14     : 0x00000000  A15     : 0xfffffffc  SAR     : 0x00000004  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x40088a9c  LEND    : 0x40088aa3  LCOUNT  : 0x00000000
Core  0 was running in ISR context:
EPC1    : 0x401ccdf3  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x40088b64

Backtrace:0x40088b61:0x3ffbf8f0 0x401395cd:0x3ffbf910 0x40019fb5:0x3ffbf930 0x40046683:0x3ffbf960 0x40047515:0x3ffbf980 0x4008bbb1:0x3ffbf9a0 0x4008b805:0x3ffbf9c0 0x4008df12:0x3ffbf9e0 0x4008f18f:0x3ffbfa00 0x4008645d:0x3ffbfa20 0x401399f5:0x3ffb5f10 0x40139fd5:0x3ffb5f30 0x4009487e:0x3ffb5f60
Core  1 register dump:
PC      : 0x4009296d  PS      : 0x00060d34  A0      : 0x80092ad5  A1      : 0x3ffbcc00
A2      : 0x3ffc76a8  A3      : 0x00060d20  A4      : 0x800949c4  A5      : 0x3ffbcb20
A6      : 0x00000000  A7      : 0x3ffbc500  A8      : 0x00000015  A9      : 0x00000001
A10     : 0x000001a4  A11     : 0x00000000  A12     : 0x00060d20  A13     : 0x00060d23
A14     : 0x00000001  A15     : 0x3ffbc500  SAR     : 0x0000001d  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000

Backtrace:0x4009296a:0x3ffbcc00 0x40092ad2:0x3ffbcc20 0x40092cf0:0x3ffbcc40 0x4009487e:0x3ffbcc60

@Alvin1Zhang
This issue has been reported quite long time ago, and at least 3 people reported that the fix does not really fix the issue.
https://github.com/espressif/esp-idf/issues/6517#issuecomment-891186177

This ongoing issue is the reason we removed the ESP32 from a product we're developing.

Thanks for reporting the issue.
The crash was because after the controller ran out of memory, malloc failure happens and assert is triggered. The issue is usually caused by the slow processing of the application layer, which caused the controller memory could not be released in time. We did some optimization before, however, if the latest IDF version still has the issue, please refer to the following suggestions and give it a try.

Reduce time-consuming operations at the application layer, such as a large number of log printing.
Increase the CPU speed, for example, increase the CPU frequency to 240Mhz. If dual-core is supported, run bluedroid host and Controller on different cores.
If you are scanning at the same time:
Try to reduce controller memory consumption, for example, by making the following changes in the configuration:
(1) Change BLE adv report flow control number to 20 and BLE adv lost event threshold value to 100
(2) Disable BLE full scan feature supported
(3) Enable BLE queue congestion check
(4) Disable Report adv data and scan response individually when BLE active scan
(5) Enable duplicate Scan when setting scan parameters to filter out duplicate broadcast packets

Meanwhile, we tried but unfortunately did not reproduce the issue yesterday. Could you please provide a tiny demo with the steps of reappearance? We will keep looking into this. Thanks.
Tiana, Espressif

@TianaESP we have a similar error but 1) is not possible as we need the tasks todo the stuff they need todo. 2) Doesn't work as we have a very narrow power margin. 3) We can certainly try that but we are not using bluedroid we are using the nimble stack which seems to also use libbtdm in which this assertion seems to happen.
May i ask what is the particular reason why there is not source for this part? As that would make debugging easier.
(Not much of a fan of re'ing such stuff or reading xtensa assembly.. )
We can reporduce the issue with a run that takes around +3 hours.
Not sure if there can be a minimal repro made as you guy's would still require the hardware on which we do the tests.
We can supply stacktraces and registers if that may help. Or if you wish we can certainly setup a remote session or something in order to get this working again. This is basically a show stopper for our entire project so if this can't be fixed we have to move to a diffrent RTOS and do a lot of the work again.

I'm not to sure if the controller memory is the problem as we have 4096 allocated to it so that is plenty or do you mean there is a leak inside the controller task? That would be very unfortnunate.

Meanwhile, we tried but unfortunately did not reproduce the issue yesterday. Could you please provide a tiny demo with the steps of reappearance? We will keep looking into this. Thanks.

@TianaESP
Just to clarify about your comments above.
So you should be able to reproduce it by

Reduce CPU speed
Disable dual-core
Add more logging

In additional, this issue does not happen immediately.
The device can run for hours then it suddenly hit assert.
So it's really difficult for application developers to know what could be wrong.

@AxelLin in our case we have dual-core running, we have the highest frequnecy set, we have it still happening.

@Platin21  Can you please provide the specific commit id of IDF and describe what the host task did?

@TianaESP
We are using version 4.3.1 and 4.4 but it was the same on ealier builds. We didn't want to go full master as we are not sure about the stability of the other features that we use with that. Are there any recent changes that should have fixed this?

I can certainly provide you a trace not sure if that will help alot though. We don't have JTAG on the board so debugging is somewhat difficult.
E (3332242) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (3332242) task_wdt:  - IDLE (CPU 1)
E (3332242) task_wdt: Tasks currently running:
E (3332242) task_wdt: CPU 0: IDLE
E (3332242) task_wdt: CPU 1: btController
E (3332242) task_wdt: Print CPU 0 (current core) backtrace

Backtrace:0x40112F9E:0x3FFBE9A00x40083299:0x3FFBE9D0 0x4018BF4F:0x3FFBC7E0 0x400D4D3D:0x3FFBC800 0x40093907:0x3FFBC820

E (3332242) task_wdt: Print CPU 1 backtrace

Backtrace:0x40085055:0x3FFBEFB00x40083299:0x3FFBEFD0 0x40174091:0x3FFE7C20 0x40174659:0x3FFE7C40

I (3332399) UDS: Read data id fe20
I (3332406) UDS: Read data id fe1f
I (3332425) UDP SERVER: Received 9 bytes from <IP_ADDRESS>:
I (3332426) UDP SERVER: JoDaHomas
I (3332430) UDP SERVER: Waiting for data
E (3337242) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (3337242) task_wdt:  - IDLE (CPU 1)
E (3337242) task_wdt: Tasks currently running:
E (3337242) task_wdt: CPU 0: IDLE
E (3337242) task_wdt: CPU 1: btController
E (3337242) task_wdt: Print CPU 0 (current core) backtrace

Backtrace:0x40112F9E:0x3FFBE9A00x40083299:0x3FFBE9D0 0x4018BF4F:0x3FFBC7E0 0x400D4D3D:0x3FFBC800 0x40093907:0x3FFBC820

E (3337242) task_wdt: Print CPU 1 backtrace

Backtrace:0x40085055:0x3FFBEFB00x40083299:0x3FFBEFD0 0x40174091:0x3FFE7C20 0x40174659:0x3FFE7C40

I (3337321) UDP SERVER: Received 9 bytes from <IP_ADDRESS>:
I (3337321) UDP SERVER: JoDaHomas
I (3337325) UDP SERVER: Waiting for data
I (3337647) UDS: Read data id fe20
I (3337653) UDS: Read data id fe1f
E (3342242) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (3342242) task_wdt:  - IDLE (CPU 1)
E (3342242) task_wdt: Tasks currently running:
E (3342242) task_wdt: CPU 0: IDLE
E (3342242) task_wdt: CPU 1: btController
E (3342242) task_wdt: Print CPU 0 (current core) backtrace

Backtrace:0x40112F9E:0x3FFBE9A00x40083299:0x3FFBE9D0 0x4018BF4F:0x3FFBC7E0 0x400D4D3D:0x3FFBC800 0x40093907:0x3FFBC820

E (3342242) task_wdt: Print CPU 1 backtrace

Backtrace:0x40085055:0x3FFBEFB00x40083299:0x3FFBEFD0 0x40174091:0x3FFE7C20 0x40174659:0x3FFE7C40

I (3342356) UDP SERVER: Received 9 bytes from <IP_ADDRESS>:
I (3342357) UDP SERVER: JoDaHomas
I (3342360) UDP SERVER: Waiting for data
I (3342928) UDS: Read data id fe20
I (3342934) UDS: Read data id fe1f
E (3347242) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (3347242) task_wdt:  - IDLE (CPU 1)
E (3347242) task_wdt: Tasks currently running:
E (3347242) task_wdt: CPU 0: IDLE
E (3347242) task_wdt: CPU 1: btController
E (3347242) task_wdt: Print CPU 0 (current core) backtrace

Backtrace:0x40112F9E:0x3FFBE9A00x40083299:0x3FFBE9D0 0x4018BF4F:0x3FFBC7E0 0x400D4D3D:0x3FFBC800 0x40093907:0x3FFBC820

E (3347242) task_wdt: Print CPU 1 backtrace

Backtrace:0x40085055:0x3FFBEFB00x40083299:0x3FFBEFD0 0x40174091:0x3FFE7C20 0x40174659:0x3FFE7C40

I (3347382) UDP SERVER: Received 9 bytes from <IP_ADDRESS>:
I (3347383) UDP SERVER: JoDaHomas
I (3347388) UDP SERVER: Waiting for data
I (3348169) UDS: Read data id fe20
I (3348178) UDS: Read data id fe1f
ASSERT_PARAM(-218959118 0), in arch_main.c at line 343                                               <==== The reported ASSERT
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0).

CONSOLE>xtensa-esp32-elf-addr2line.exe -e cu-offroad.elf -p -a 0x40112F9E:0x3FFBE9A00x40083299:0x3FFBE9D0 0x4018BF4F:0x3FFBC7E0 0x400D4D3D:0x3FFBC800 0x40093907:0x3FFBC820
0x40112f9e: #idf path#/esp_system/task_wdt.c:191 (discriminator 3)
0x4018bf4f: #idf path#/hal/esp32/include/hal/cpu_ll.h:183
0x400d4d3d: #idf path#/esp_system/freertos_hooks.c:63
0x40093907: #idf path#/freertos/tasks.c:3823

CONSOLE>xtensa-esp32-elf-addr2line.exe -e cu-offroad.elf -p -a 0x40112F9E:0x3FFBE9A00x40083299:0x3FFBE9D0 0x4018BF4F:0x3FFBC7E0 0x400D4D3D:0x3FFBC800 0x40093907:0x3FFBC820
0x40112f9e: #idf path#/esp_system/task_wdt.c:191 (discriminator 3)
0x4018bf4f: #idf path#/hal/esp32/include/hal/cpu_ll.h:183
0x400d4d3d: #idf path#/esp_system/freertos_hooks.c:63
0x40093907: #idf path#/freertos/tasks.c:3823

CONSOLE>xtensa-esp32-elf-addr2line.exe -e cu-offroad.elf -p -a 0x40085055:0x3FFBEFB00x40083299:0x3FFBEFD0 0x40174091:0x3FFE7C20 0x40174659:0x3FFE7C40
0x40085055: #idf path#/esp_system/crosscore_int.c:92
0x40174091: ??:?
0x40174659: ??:?

CONSOLE>xtensa-esp32-elf-addr2line.exe -e cu-offroad.elf -p -a 0x40085055:0x3FFBEFB00x40083299:0x3FFBEFD0 0x40174091:0x3FFE7C20 0x40174659:0x3FFE7C40
0x40085055: #idf path#/esp_system/crosscore_int.c:92
0x40174091: ??:?
0x40174659: ??:?

CONSOLE>xtensa-esp32-elf-addr2line.exe -e cu-offroad.elf -p -a 0x4018bf4f:0x3ffbc7e00x400d4d3d:0x3ffbc800 0x40093907:0x3ffbc820
0x4018bf4f: #idf path#/hal/esp32/include/hal/cpu_ll.h:183
0x40093907: #idf path#/freertos/tasks.c:3823

CONSOLE>xtensa-esp32-elf-addr2line.exe -e cu-offroad.elf -p -a 0x40089686:0x3ffbeec00x40173c79:0x3ffbeee0 0x40019fb5:0x3ffbef00 0x400466c3:0x3ffbef30 0x4008c772:0x3ffbef50 0x4008c45d:0x3ffbef70 0x4008eb6a:0x3ffbef90 0x4008fde7:0x3ffbefb0 0x40083299:0x3ffbefd0 0x40174091:0x3ffe7c20 0x40174659:0x3ffe7c40
0x40089686: ??:?
0x40019fb5: ??:0
0x400466c3: ??:0
0x4008c772: ??:?
0x4008c45d: ??:?
0x4008eb6a: ??:?
0x4008fde7: intc.c:?
0x40083299: #idf path#/freertos/port/xtensa/xtensa_vectors.S:1105
0x40174091: ??:?
0x40174659: ??:?

In this case it was running for around 3 hours which is for our use case not that uncommon. And as i said we are willing to take some time to debug the issue but for us it's not a clear case. And we can only see that libbtdm as inside the controller task we have a failure.

We have a demo which the device do scan , adv and connect to four other devices. But we run about one day and could not reproduce the issue.

@skyESP
1:
rel4.4 https://github.com/espressif/esp-idf/tree/release/v4.4
rel4.3 https://github.com/espressif/esp-idf/tree/release/v4.3
This report was from a run with version 4.4
2:
Just a normal BLE process with RPA Enabled.
As in start with adv then do a connect then we have GATT Attributes that we retrieve every 5 seconds. Our process also does do a scan for sensors but that is not active during the tests.

During the test, Does the Adv is still continue? If it does,what's the frequence?

@skyESP

No it doesn’t continue
As i already said we use nimble
What part of bt? The host our task or the controller?

And no we have no option to switch to blue droid as that would nog fit in memory anymore.

@Platin21
OK,Thanks for your information. We are trying to reproduce the issue.
Fore the third question. You can do as following.
We have menuconfig to chose running on core0 or core1.
run idf.py menuconfig
For wifi:
(Top) → Component config → Wi-Fi → WiFi Task Core ID
For bt
(Top) → Component config → Bluetooth → Bluetooth controller(ESP32 Dual Mode Bluetooth) → The cpu core which bluetooth controller run
Another two questions
1.What's the priority of the task  for retrieving CAN Messages ? Does it higher than controller task?
2.From your describe you just use polling mode not using interrupt for handling the task, Am I right?

@skyESP
Let me check if that changes anything and i get back to you.

20 from max 25. The BLE one is also slightly evalated i think it’s 15 there.
It’s done via Interrupt

OK, You set the  priority of the controller task lower than the task to handle the can message.
Here please do two tests.

Set the controller task higher than the  task to handle the can message.If still have problem please do the step 2.
2.Reduce the load or stop the  the  task to handle the can message and check if the issue is still here.
I suspect that the controller task is blocked by other task or the interrupt.

@skyESP where can one change the controller priority? Seems to be not a option inside Component config -> Bluetooth -> Bluetooth Controller. Or what is the default level there?

Isn’t really a fix but for testing sure i can do that.

1.You can change the priority in the code where you create the task.
2.From our experience the controller should not be blocked by other tasks or interrupt for long time. Through I do not know how long and how much work you did in your task,so I advance you to do this to  test and verify my suspection. If it works,this can be a fix.

@skyESP you mean the task that handles the BLE so neither the controller nor the host?

@Platin21
hi，
1.You had better keep the priority of controller and host task as our demo example.
2.The task you create yourself should lower than the controller and host ble task.

I didn’t change anything there what i was not sure about is if our task should have a higher prio than the can one
This was the case anyways i think meanwhile i dunno what the default prio of these other two tasks is.
Possible but that needs to be elaborated in a Email. And i suspect it makes more sense that we setup something as i already said and you maybe can guess that the pcb on which the esp sits is custom.

@skyESP so back to the priorities the host task seems to run on 21 and the LL task seems to run on 24 so our can task is acutally already lower in priority. And to the other tasks on the system all of them run with priority 0 so should not be possbile for it to interfere at all then.

hi,@Platin21
Sorry for replay late. Yes Priority 0 of other tasks should not interfere them.
For the example  ble_ibeacon demo in our IDF sdk.
The controller task is 23,hci host task  is 22, BTU task is 20 ,BTC task is 19.

Yeah that makes it clearer now.
We will setup something tomorrow and i will leave my response here. But yeah it sounds very promising. We are now switching the priorities to be under a value of 18. Would be a huge step for us forward if that works out.

After switching the "priority and increasing" the buffer the bug still happens.
@skyESP Can we arrange a meeting in some ways to get maybe a clearer outcome?

I can share also the crash log again but it is basically the samething as it was.

＠Platin21
hi,If you stop the task to handle the CAN message. Did this issue still happen?

@skyESP if i stop this task i can’t use CAN so even if it doesn’t happen then that’s not a solution.

Ok,Then what did you do in the interrupt of the CAN? Does this part cost lot of time? Could you share the related code?

Its basically a loop that does rx and tx of can messages and stores them in a static array.
Looks something like that:
static void
can_isr( void *arg )
{
  uint8_t events;
  events = can_base->interrupt;

  if( /* check for b0 event */ ) {
    can_rx_isr();
  }
  if(/* check for b1 event */) {
    can_tx_isr();
  }
  /* Check if overrun or bus error occured */
  if( (events & B7) ) {
    can_error_flag = 1u;
    can_error_code_capture = can_base->err_code;
  }
}

In side can_rx_isr() is just a function that stores the frame we got and validates it.
In the tx side we write to the transmit fifo and that seems to be it. (Just a byte copy)
I have to say though without the load of the uds the controller seems to just work fine.

What we are now trying is to make a task that simulates a load and see if that makes any diffrence.

hi,@Platin21
I think you can post a message from the can_isr to other tasks to  handle the "can_rx_isr()" and "can_tx_isr()".
It should not do lots of work in the interrupt.

@skyESP any estimates how long would be to long to todo something in the interrupt?

The working cases of the controller is complicated(Scan state,adv state,connecting state while receive and transmit data in different frequency), so it is hard to have such data.

@skyESP just a thing on that side the int in our case isn't happening on the same core is a problem with the int then still possible?

Do you mean you can handle the int in another core? I think you can have a try. The ble controller and host is default running on the core 0. You can make the core 1 handle the int. But I am not sure this way can help.

We have found that this error is provoked if you regularly use SPIFFS. Maybe during erase cycles.
Unfortunately, without the source code this is almost impossible to catch.
In an earlier post you stated:
"The crash was because after the controller ran out of memory, malloc failure happens and assert is triggered. The issue is usually caused by the slow processing of the application layer, which caused the controller memory could not be released in time"
What is the amount of memory required?
What is the longest "processing of the application layer" that is allowed?

@ChrisEAlfred we are not useing spiffs we are using fat and nvs. In our case basically all memory that the normal esp32 has i think 1k bytes is still left.
Yeah that processing was also interesting for me but it seems like that’s nit easy to say.

SPIFFS and NV storage use the same memory.
So I guess the question is ... does using the ESP32 NV in any way provoke this problem?
Our tests appear to indicate that this is the case.

@ChrisEAlfred thing is we didn’t have this controller error when i just run it without having the int from the can driver and after 8 hours still nothing. Teh average time for that to happen was 6 to 4 hours. If it’s the NVS then i’m not sure why this didn’t happen in this case.

@skyESP it seems it's related to our CAN Side. Could it be that somehow something gets overlaped in the sheduler that makes this problem happening?

@ChrisEAlfred we disabled this setting and still get the error so from what i can see there isn't a diffrence.

So for the CAN Side we can't move that to use Polling as that makes the timings not to comply.
@skyESP any other ideas?

@bshmid i don't think this would be a solution in our case or did you als have troubles when you used the can twai isr source.

@Platin21,I think you can post the work that cost lots of time to one task,the priority of the task should lower than the BTC task.
If you must read or write flash,you should not do it in interrupt.

@bshmid i don't think this would be a solution in our case or did you als have troubles when you used the can twai isr source. It's all about timings..

I wasn't using the can twai isr source, but I got the error message discussed in this post while running some simple stuff in a while loop.

@bshmid i don't think this would be a solution in our case or did you als have troubles when you used the can twai isr source. It's all about timings..

I wasn't using the can twai isr source, but I got the error message discussed in this post while running some simple stuff in a while loop.

Ok that sounds intressting how "simple" was it in your case? So simple that you'd be able todo a repro so i would also be able to verify if we have this on our board??

Here is it (before fixing):
`  while (1){
pService->start();
BLEDevice::startAdvertising();
Serial.println("Characteristic defined!");
Serial.print(pServer->getConnectedCount());
Serial.println(" devices connected");
if (pServer->getConnectedCount()){   //delay(2);
newString = pCharacteristic->getValue().c_str();
myString = newString;
Serial.println(myString);
val0 = myString.substring(0, 4).toInt();
val1 = myString.substring(4, 8).toInt();
val2 = myString.substring(8, 12).toInt();
val3 = myString.substring(12, 16).toInt();
dac.analogWrite(dac.A,val0);
dac.analogWrite(dac.B,val1);
dac.analogWrite(dac.C,val2);
dac.analogWrite(dac.D,val3);
Serial.print(pServer->getConnectedCount());
Serial.println(" devices connected");
}`

That's it? And how long does it take to fail on your side?

A few seconds.

@bshmid Are these arduino abstractions or did you do them yourselfes? Because I'd like to verify that on our board too.

@bshmid Are these arduino abstractions or did you do them yourselfes? Because I'd like to verify that on our board too.

Sorry, I don't understand your question.

@bshmid can you provide the full code as in including the setup code?

Ahh got it done myself.

Anything happening on that side? I had to fix a other bug before being able to look at this again.
@skyESP did you try out the example from @bshmid above?

Following. idf 4.3.1. ESP32 Chip rev 3.  Saw one of these last night, both ble and wifi running on core 0 connected.  Fairly CPU intensive calculations running on low priority thread on core 1 completed just prior to crash.  SPI bus probably busy switching screens.
ASSERT_PARAM(-218959118 0), in arch_main.c at line 343
I (39889008) ui: onDismissed: 428 : CalibratingScreen
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0).
Core  0 register dump:
PC      : 0x400852a7  PS      : 0x00060c34  A0      : 0x80181940  A1      : 0x3ffbe970
0x400852a7: r_assert_param at ??:?
A2      : 0x00000001  A3      : 0x00000000  A4      : 0x60008048  A5      : 0x00000000
A6      : 0x00000004  A7      : 0x3ffbdbe4  A8      : 0x800852a4  A9      : 0x3ffbe950
A10     : 0x00000000  A11     : 0x00000037  A12     : 0x00000014  A13     : 0xffffffff
A14     : 0x00000000  A15     : 0xfffffffc  SAR     : 0x00000004  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x400851dc  LEND    : 0x400851e3  LCOUNT  : 0x00000000
0x400851dc: r_assert_param at ??:?
0x400851e3: r_assert_param at ??:?
Core  0 was running in ISR context:
EPC1    : 0x400d44d3  EPC2    : 0x40234e0a  EPC3    : 0x00000000  EPC4    : 0x400852a7
0x400d44d3: uart_hal_write_txfifo at /home/dev/esp/esp-idf/components/hal/uart_hal_iram.c:35
0x40234e0a: esp_pm_impl_waiti at /home/dev/esp/esp-idf/components/esp_pm/pm_impl.c:829
0x400852a7: r_assert_param at ??:?
Backtrace:0x400852a4:0x3ffbe970 0x4018193d:0x3ffbe990 0x40019fb5:0x3ffbe9b0 0x40089ada:0x3ffbe9e0 0x400883b9:0x3ffbea20 0x400880d1:0x3ffbea40 0x4008a86e:0x3ffbea60 0x4008baeb:0x3ffbea80 0x400847e5:0x3ffbeaa0 0x401f7a11:0x3ffdb5f0 0x401f7a76:0x3ffdb630 0x401b199e:0x3ffdb650 0x402352cd:0x3ffdb670 0x401c3ebf:0x3ffdb690 0x401c38c9:0x3ffdb6b0 0x401be8f5:0x3ffdb6d0 0x401beb86:0x3ffdb700 0x401bf9dd:0x3ffdb730 0x401bfa19:0x3ffdb780 0x401bfa46:0x3ffdb7b0 0x401bbac5:0x3ffdb7e0 0x401ba8b5:0x3ffdb820 0x401bf73a:0x3ffdb890 0x401c3806:0x3ffdb8c0 0x401b436d:0x3ffdb8e0
0x400852a4: r_assert_param at ??:?
0x4018193d: r_platform_reset at ??:?
0x40089ada: r_lld_pdu_rx_handler at ??:?
0x400883b9: r_lld_evt_end at ??:?
0x400880d1: r_lld_evt_end_isr at ??:?
0x4008a86e: r_rwble_isr at ??:?
0x4008baeb: r_rwbtdm_isr_wrapper at intc.c:?
0x400847e5: _xt_lowint1 at /home/dev/esp/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1105
0x401f7a11: ieee80211_search_node at ??:?
0x401f7a76: esp_wifi_internal_tx_by_ref at ??:?
0x401b199e: wifi_transmit_wrap at /home/dev/esp/esp-idf/components/esp_wifi/src/wifi_netif.c:70
0x402352cd: esp_netif_transmit_wrap at /home/dev/esp/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:880
0x401c3ebf: low_level_output at /home/dev/esp/esp-idf/components/lwip/port/esp32/netif/wlanif.c:137
0x401c38c9: ethernet_output at /home/dev/esp/esp-idf/components/lwip/lwip/src/netif/ethernet.c:312 (discriminator 2)
0x401be8f5: etharp_output_to_arp_index at /home/dev/esp/esp-idf/components/lwip/lwip/src/core/ipv4/etharp.c:785
0x401beb86: etharp_output at /home/dev/esp/esp-idf/components/lwip/lwip/src/core/ipv4/etharp.c:901
0x401bf9dd: ip4_output_if_opt_src at /home/dev/esp/esp-idf/components/lwip/lwip/src/core/ipv4/ip4.c:1089
0x401bfa19: ip4_output_if_opt at /home/dev/esp/esp-idf/components/lwip/lwip/src/core/ipv4/ip4.c:890
0x401bfa46: ip4_output_if at /home/dev/esp/esp-idf/components/lwip/lwip/src/core/ipv4/ip4.c:867
0x401bbac5: tcp_output_segment at /home/dev/esp/esp-idf/components/lwip/lwip/src/core/tcp_out.c:1607
(inlined by) tcp_output at /home/dev/esp/esp-idf/components/lwip/lwip/src/core/tcp_out.c:1360
0x401ba8b5: tcp_input at /home/dev/esp/esp-idf/components/lwip/lwip/src/core/tcp_in.c:557
0x401bf73a: ip4_input at /home/dev/esp/esp-idf/components/lwip/lwip/src/core/ipv4/ip4.c:784
0x401c3806: ethernet_input at /home/dev/esp/esp-idf/components/lwip/lwip/src/netif/ethernet.c:186
0x401b436d: tcpip_thread_handle_msg at /home/dev/esp/esp-idf/components/lwip/lwip/src/api/tcpip.c:180
(inlined by) tcpip_thread at /home/dev/esp/esp-idf/components/lwip/lwip/src/api/tcpip.c:154
Core  1 register dump:
PC      : 0x40234e0a  PS      : 0x00060b34  A0      : 0x800db280  A1      : 0x3ffca7a0
0x40234e0a: esp_pm_impl_waiti at /home/dev/esp/esp-idf/components/esp_pm/pm_impl.c:829
A2      : 0x00000000  A3      : 0x400918d0  A4      : 0x00000000  A5      : 0x000000a5
0x400918d0: _cleanup_r at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/findfp.c:205
A6      : 0x00000014  A7      : 0x00000001  A8      : 0x801c9f22  A9      : 0x3ffca770
A10     : 0x00000000  A11     : 0x3ffbf0b8  A12     : 0x3ffbf0b8  A13     : 0x00000000
A14     : 0x00060f20  A15     : 0x3f874ed0  SAR     : 0x00000007  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000
Backtrace:0x40234e07:0x3ffca7a0 0x400db27d:0x3ffca7c0 0x40098e54:0x3ffca7e0
0x40234e07: cpu_ll_waiti at /home/dev/esp/esp-idf/components/hal/esp32/include/hal/cpu_ll.h:183
(inlined by) esp_pm_impl_waiti at /home/dev/esp/esp-idf/components/esp_pm/pm_impl.c:827
0x400db27d: esp_vApplicationIdleHook at /home/dev/esp/esp-idf/components/esp_common/src/freertos_hooks.c:63
0x40098e54: prvIdleTask at /home/dev/esp/esp-idf/components/freertos/tasks.c:3839

hi@bill1davis
Please check if there is high level task or interrupt which cost lots of time running. The crash reason is as before."The crash was because after the controller ran out of memory, malloc failure happens and assert is triggered. The issue is usually caused by the slow processing of the high level application task or interrupt, which caused the controller memory could not be released in time."

hi@skyESP
We have a high priority task running on core 1 that runs for a short time at 10hz.  We have another low priority task on core 1 that does floating point computation that can run for up to 200ms without explicitly giving up its timeslot.  We have a couple of very simple interrupt handlers that just queue events and return.  BLE and Wifi are both configured to run on core 0.
My thinking is that having our demanding threads running on core 1 should minimize interference with the radios.  Do I need to adjust the priority of my high priority task on core 1 below some level?  Thanks!

I think you had better adjust the priority of high priority task on core 1 lower than the BTU and BTC task.

In my response https://github.com/espressif/esp-idf/issues/7805#issuecomment-974900198 we reported that using SPIFFS provokes the issue.
We are redirecting the ESP32 logs to SPIFFS using esp_log_set_vprintf. Is it possible this can cause the issue?

As i said ealier we are using FATFS and NVS. And both of these don't use the SPIFFS. As NVS ist just a key value store unformated and FATFS is FAT. So if that is because of this i would suspect that it happens because of some common layer between these systems. But maybe in our case it's just the memory usage that makes problems.

Hi, I'm facing the same issue.
Is there a definitive way to solve this problem?
I get this error when I'm finishing writing in the flash using NVS multiple times.  I got the following logs:
E (165428) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (165428) task_wdt:  - IDLE0 (CPU 0)
E (165428) task_wdt: Tasks currently running:
E (165428) task_wdt: CPU 0: btController
E (165428) task_wdt: CPU 1: IDLE1
E (165428) task_wdt: Print CPU 0 (current core) backtrace
Backtrace:0x400D45AC:0x3FFBE4F0 0x40082561:0x3FFBE510 0x400F49A4:0x3FFB4E50 0x400F4F6D:0x3FFB4E70
E (165428) task_wdt: Print CPU 1 backtrace
Backtrace:0x40081966:0x3FFBEAF0 0x40082561:0x3FFBEB10 0x4000BFED:0x3FFBC420 0x4008F911:0x3FFBC430 0x400D47BC:0x3FFBC450 0x400D47C7:0x3FFBC480 0x400D4862:0x3FFBC4A0 0x4008FEA8:0x3FFBC4C0
E (170428) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (170428) task_wdt:  - IDLE0 (CPU 0)
E (170428) task_wdt: Tasks currently running:
E (170428) task_wdt: CPU 0: btController
E (170428) task_wdt: CPU 1: IDLE1
E (170428) task_wdt: Print CPU 0 (current core) backtrace
Backtrace:0x400D45AC:0x3FFBE4F0 0x40082561:0x3FFBE510 0x400F49A4:0x3FFB4E50 0x400F4F6D:0x3FFB4E70
E (170428) task_wdt: Print CPU 1 backtrace
Backtrace:0x40081966:0x3FFBEAF0 0x40082561:0x3FFBEB10 0x4000BFED:0x3FFBC420 0x4008F911:0x3FFBC430 0x400D47BC:0x3FFBC450 0x400D47C7:0x3FFBC480 0x400D4862:0x3FFBC4A0 0x4008FEA8:0x3FFBC4C0
E (175428) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (175428) task_wdt:  - IDLE0 (CPU 0)
E (175428) task_wdt: Tasks currently running:
E (175428) task_wdt: CPU 0: btController
E (175428) task_wdt: CPU 1: IDLE1
E (175428) task_wdt: Print CPU 0 (current core) backtrace
Backtrace:0x400D45AC:0x3FFBE4F0 0x40082561:0x3FFBE510 0x400F49A4:0x3FFB4E50 0x400F4F6D:0x3FFB4E70
E (175428) task_wdt: Print CPU 1 backtrace
Backtrace:0x40081966:0x3FFBEAF0 0x40082561:0x3FFBEB10 0x4000BFED:0x3FFBC420 0x4008F911:0x3FFBC430 0x400D47BC:0x3FFBC450 0x400D47C7:0x3FFBC480 0x400D4862:0x3FFBC4A0 0x4008FEA8:0x3FFBC4C0
E (180428) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (180428) task_wdt:  - IDLE0 (CPU 0)
E (180428) task_wdt: Tasks currently running:
E (180428) task_wdt: CPU 0: btController
E (180428) task_wdt: CPU 1: IDLE1
E (180428) task_wdt: Print CPU 0 (current core) backtrace
Backtrace:0x400D45AC:0x3FFBE4F0 0x40082561:0x3FFBE510 0x400F49A4:0x3FFB4E50 0x400F4F6D:0x3FFB4E70
E (180428) task_wdt: Print CPU 1 backtrace
Backtrace:0x40081966:0x3FFBEAF0 0x40082561:0x3FFBEB10 0x4000BFED:0x3FFBC420 0x4008F911:0x3FFBC430 0x400D47BC:0x3FFBC450 0x400D47C7:0x3FFBC480 0x400D4862:0x3FFBC4A0 0x4008FEA8:0x3FFBC4C0
ASSERT_PARAM(-218959118 0), in arch_main.c at line 343
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0).
I must say in my program I'm using ISR to replicate the example of espressif called "timer_group_example_main". I use this example to implement a timer and a tick counter, but, when I use this, this error appears and crash the program and doesn't restart until I press the EN button in the ESP-WROVER-KIT. I must say that when I disable BLE_MODEM_SLEEP the error doesn't appear immediately but randomly after several hours.

@Platin21 Hi, you never could find the solution to this bug?

Yes we never got a reply in the sense of this is how one can fix it. Or these are conditions where this happens. We also ended long term testing some months ago as we can’t do anything without getting help from espressif. But we will have todo these tests again anyways as the device needs for certification a minimum runtime of 16 hours. We are using a ublox variant of the esp32 to make that also clear.

@guirespi are you able to make a minimal repro? Sad thing is also that there are people just writing in this issue there own stuff which is completely unrelated so the conversation driftet to there off topic problems.

@Platin21 I will try it this week from the blephr and timer_group_example example and do some task that writes and erase the flash periodically. I think those are the conditions to trigger the wdt timeout.

I think you had better adjust the priority of high priority task on core 1 lower than the BTU and BTC task.

@skyESP
But you cannot complete control the task priority because the assigned priorities of tasks shifts after creation. see https://github.com/espressif/esp-idf/issues/7580

So after sometime not having any time to test this we found that the bug still happens. We where thinking that it doesn't happen anymore after we changed some stuff on the nimble side. This turned out to be wrong. We still have the same problem there. In this case we where using the idf version 4.3.2 there is no option just by the flash size too switch to a newer version. So the question is did anything change that could change the beavhoiur of the libbtm in newer versions?
Basically the same as above:
ASSERT_PARAM(-218959118 0), in arch_main.c at line 358
Guru Meditation Error: Core  0 panic'ed (IllegalInstruction). Exception was unhandled.

Decoded Lines:
r_assert
??:?
r_assert_param
??:?
r_platform_reset
??:?
??
??:0
??
??:0
r_llm_le_adv_report_ind
??:?
r_llm_pdu_defer
??:?
r_lld_pdu_check
??:?
r_lld_evt_deffered_elt_handler
??:?
??
??:0
??
??:0
r_rw_schedule
??:?
btdm_controller_task
??:?
The CPU workload is in our setup only using 30% with two cores active + 240mhz. So from a load side i can't see a reason why.
Memory is one point that we have a relativly high usage of 70% of the available heap. with a freespace of 41,4 KB.
Basically meaning that we neither have no memory nor is the cpu doing a lot of work. Which makes the load as a cause not really plausible. So any other ideas?
@skyESP @TianaESP

We are now also testing with 4.4.1 to see if it still happens.

After testing with the above mentioned Version we still have the same Problem so the current IDF doesn't fix it:
ASSERT_PARAM(-218959118 0), in arch_main.c at line 358
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x40090094: 000000f0 00004136 f01d0000
Core  1 register dump:
PC      : 0x4009009b  PS      : 0x00060c34  A0      : 0x80083f4d  A1      : 0x3ffb5ed0
A2      : 0x00000000  A3      : 0xf2f2f2f2  A4      : 0x00000000  A5      : 0x3f412c66
A6      : 0x00000166  A7      : 0xfffffffc  A8      : 0x8000814b  A9      : 0x3ffb5e40
A10     : 0x00000000  A11     : 0x3ffb5e63  A12     : 0x3ffb5e0f  A13     : 0x00000038
A14     : 0x00000000  A15     : 0x3ffb5e14  SAR     : 0x00000004  EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000  LBEG    : 0x40083e55  LEND    : 0x40083e5d  LCOUNT  : 0x00000000
Backtrace:0x40090098:0x3ffb5ed00x40083f4a:0x3ffb5ef0 0x4010b189:0x3ffb5f10 0x40019fb5:0x3ffb5f30 0x4001a1f2:0x3ffb5f60 0x4011987b:0x3ffb5f80 0x4011afe5:0x3ffb5ff0 0x401180f3:0x3ffb6040 0x40115372:0x3ffb6090 0x40019d11:0x3ffb60d0 0x40055b4d:0x3ffb60f0 0x4010b58b:0x3ffb6110 0x4010bc10:0x3ffb6130
ELF file SHA256: 5e1605f6b8f2252a
Rebooting...

So any other leads? NVS didn't do the trick, we also don't have a lot of load and there is plenty of memory left as in 42kb memory.
And here is the decoded output:
r_assert
C:/Espressif_4_4_1/frameworks/esp-idf-v4.4.1/components/bt/controller/esp32/bt.c:2018
r_platform_reset
??:?
??
??:0
??
??:0
r_llm_le_adv_report_ind
??:?
r_llm_pdu_defer
??:?
r_lld_pdu_check
??:?
r_lld_evt_deffered_elt_handler
??:?
??
??:0
??
??:0
r_rw_schedule
??:?
btdm_controller_task
??:?

@Alvin1Zhang This issue has been reported quite long time ago, and at least 3 people reported that the fix does not really fix the issue. #6517 (comment)

@skyESP @TianaESP
Any update/fix for this issue?

EEEK I just had this happen. The worst part is it doesn't call abort so my motors were still running and it caused a crash.

Could you please provide the completed log? I need to known the controller compile version.

We have fixed this bug(commit ed7d2d3f0db5fcb626a3ebb799b9bcce66f674e4 for branch release/v4.4). Please update the code.

Hi, after a long time of testing I can say that this error happens when a long time operation (like saving a blog larger than 2k bytes in the nvs) and BLE is receiving or writing data. It still happens in ESP IDF v4.4.2, @esp-cjh. I saw that the bugfix was made in the esp32c3 family... what about the others?

Anyone have any finite fixes for this?

I'm using WiFi, BLE, TWAI, and SPIFFS and some print logs my application.
OTA works 2-3 times consistently and then the 4th attempt it usually just crashes. I can also comment to @guirespi  that I'm also using storage that is 1MB which may be a factor on the memory corruption. However I'm always un mounting, registering the drive before accessing as well as a clean format once I load the OTA application upon it.

We havent seen it since auditing our high priority tasks and making sure they are lower than btu and btc as @skyESP  suggested.
The task in question was doing almost nothing, but it made a difference that it was preempting the bt tasks, I guess.

@guirespi
We have fixed this bug (commit 8769f62c3b687a4dedf25c748fe040b47ea6b2d4 for branch release/v4.3). Please cherry-pick the commit and see if problems also arise.

@esp-cjh We tested the idf 4.4.4 where the fix is present but the problem still happen while writing on FLASH. The target device is the esp32.
See the Backtrace below.
ASSERT_PARAM(-218959118 0), in arch_main.c at line 358
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x4008fda4: 000000f0 00004136 f01d0000
0x4008fda4: coex_bb_reset_unlock_wrapper at /opt/esp/idf/components/bt/controller/esp32/bt.c:1302
Core  1 register dump:
PC      : 0x4008fdab  PS      : 0x00060734  A0      : 0x80083e11  A1      : 0x3ffc1320
0x4008fdab: r_assert at /opt/esp/idf/components/bt/controller/esp32/bt.c:2019
A2      : 0x00000000  A3      : 0xf2f2f2f2  A4      : 0x00000000  A5      : 0x3f433b26
A6      : 0x00000166  A7      : 0xfffffffc  A8      : 0x8000814b  A9      : 0x3ffc1290
A10     : 0x00000000  A11     : 0x3ffc12b3  A12     : 0x3ffc125f  A13     : 0x00000038
A14     : 0x00000000  A15     : 0x3ffc1264  SAR     : 0x00000004  EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000  LBEG    : 0x40083d19  LEND    : 0x40083d21  LCOUNT  : 0x00000000
0x40083d19: r_assert_param at ??:?
0x40083d21: r_assert_param at ??:?
Backtrace:0x4008fda8:0x3ffc13200x40083e0e:0x3ffc1340 0x40143d39:0x3ffc1360 0x40019fb5:0x3ffc1380 0x4008862a:0x3ffc13b0 0x40086f25:0x3ffc13f0 0x40086c3e:0x3ffc1410 0x4008940a:0x3ffc1430 0x4008a673:0x3ffc1450 0x400832d5:0x3ffc1470 0x40083242:0x3ffc1490 0x40083226:0x00000000  |<-CORRUPTED
0x4008fda8: r_assert at /opt/esp/idf/components/bt/controller/esp32/bt.c:2018
0x40083e0e: r_assert_param at ??:?
0x40143d39: r_platform_reset at ??:?
0x4008862a: r_lld_pdu_rx_handler at ??:?
0x40086f25: r_lld_evt_end at ??:?
0x40086c3e: r_lld_evt_end_isr at ??:?
0x4008940a: r_rwble_isr at ??:?
0x4008a673: r_rwbtdm_isr_wrapper at intc.c:?
0x400832d5: hli_c_handler at /opt/esp/idf/components/bt/controller/esp32/hli_api.c:101
0x40083242: _highint4_stack_switch at /opt/esp/idf/components/bt/controller/esp32/hli_vectors.S:185
0x40083226: xt_highint4 at /opt/esp/idf/components/bt/controller/esp32/hli_vectors.S:169

@ianzo OK. Could you please provide the procedure or source code to reproduce this issue?

Hi @esp-cjh, long time ago we avoid this bug disabling the option in SDKConfig "Enable Bluetooth modem sleep", but the bug was triggered when I was writting to the flash a chunk of 4 kB using your nvs_flash library and then connecting to BLE, with modem sleep enable, and writting to a  characteristic some value that will be written into the flash too.
It is curious that this only happen if the option of modem sleep is enable and without it I was able to write the chunk of 4096 B and also write the value wrote through the BLE characteristic. By the way, this happened to me while using ESP IDF 4.4.2.
P.S. after this bug was avoided, our device was able to write to flash chunks of 4096 periodically, communicate with a sensor via UART and write its value into flash each 220 ms, all this coexisting with BLE up to 21 consecutive days without resets. (A blackout cause the restart of the device at the end)

@guirespi Thanks. We will reproduce the bug and fixed it ASAP.

@guirespi How often do you write flash? How often do you write GATT characteristic value?

Hi @esp-cjh, the writing in the GATT characteristic was user choice. The problem triggers when the user writes and the chunk of 4096 bytes is written too by a task. I was able to make this by setting the local time in the esp32 with a server and then schedule the writing by a specific hour. E.g. every quarter hour the chunk is written and just when this starts, I write to the characteristic.

@guirespi I write characteristic value all the time and write flash (4096 bytes) every 2 seconds. But can't reproduce the problem. Is there something wrong with my reproduction? By the way, the task used to write flash has a low priority.

@esp-cjh is the write to the characteristic at the same as the writing of the flash? Just to be clear, in my example I wrote to a gatt characteristic 500 bytes and those bytes are written to the flash. At the same time, the part of 4096 is written too. The two byte's arrays correspond to different key-values pairs and were saved using the nvs api.
About your question, the ble task had the highest priority and the the other task has a value near it. I don't have right now the exact  values but if I remember right it was 22 and 16 respectively. Also, the option "ble modem sleep" was enable when this bug happened.
I hope this helps to reproduce the bug, sorry if it doesn't work or I'm misunderstanding the problem.

@esp-cjh I forgot about something. When I said the 500 bytes of the gatt characteristic are written to the flash, is more like that from the 500 bytes, I separate those in 10 parts, and those 10 parts are written in different key-value pairs in a for loop. And then I notify to the user an 'OK' via the same characteristic.

@esp-cjh the last detail haha Each write of a key-value pair creates a different nvs handle and when the change is commited, closes it. If other key-value has to be written, then I create another nvs handle and so on.
The chunk of 4096 bytes also creates its own nvs handle when try to write to the flash and then closes it when finish.

@ianzo OK. Could you please provide the procedure or source code to reproduce this issue?

@esp-cjh if you make a task that reads from FLASH through the Bluetooth characteristics meanwhile another task is writing in FLASH, then you can reproduce the bug. Hereafter there is the Backtrace that replicates the problem and the issue is present with idf 5.0.2 as well!
Backtrace: 0x4016C272:0x3FFBE6F0 0x40082E15:0x3FFBE710 0x4008C551:0x3FFCD9E0 0x4008D003:0x3FFCDA10 0x40168399:0x3FFCDA80 0x40130F71:0x3FFCDAB0 0x4013487F:0x3FFCDAD0 0x401324DE:0x3FFCDB00 0x40133BEB:0x3FFCDB50 0x40131411:0x3FFCDB90 0x40130D68:0x3FFCDBC0 0x400D6723:0x3FFCDC10 0x401FD504:0x3FFCDC30 0x401FD5AD:0x3FFCDC60 0x400E43EA:0x3FFCDC80 0x400E5262:0x3FFCDD60 0x400E58B9:0x3FFCDDB0 0x400ECA71:0x3FFCDE10 0x400EB7E0:0x3FFCDE50 0x400EBD93:0x3FFCDF00 0x400EA9A5:0x3FFCDF30 0x400DCB02:0x3FFCDF80 0x400D9B2C:0x3FFCDFC0
0x4016c272: task_wdt_isr at /opt/esp/idf/components/esp_system/task_wdt.c:183
0x40082e15: _xt_lowint1 at /opt/esp/idf/components/freertos/port/xtensa/xtensa_vectors.S:1114
0x4008c551: spi_flash_disable_interrupts_caches_and_other_cpu at /opt/esp/idf/components/spi_flash/cache_utils.c:165 (discriminator 1)
0x4008d003: spi_flash_guard_start at /opt/esp/idf/components/spi_flash/flash_ops.c:243
(inlined by) spi_flash_read at /opt/esp/idf/components/spi_flash/flash_ops.c:709
0x40168399: esp_partition_read at /opt/esp/idf/components/spi_flash/partition.c:426
0x40130f71: spiffs_api_read at /opt/esp/idf/components/spiffs/spiffs_api.c:36
0x4013487f: spiffs_phys_rd at /opt/esp/idf/components/spiffs/spiffs/src/spiffs_cache.c:161
0x401324de: spiffs_obj_lu_find_entry_visitor at /opt/esp/idf/components/spiffs/spiffs/src/spiffs_nucleus.c:166
0x40133beb: spiffs_object_find_object_index_header_by_name at /opt/esp/idf/components/spiffs/spiffs/src/spiffs_nucleus.c:1711
0x40131411: SPIFFS_open at /opt/esp/idf/components/spiffs/spiffs/src/spiffs_hydrogen.c:230 (discriminator 2)
0x40130d68: vfs_spiffs_open at /opt/esp/idf/components/spiffs/esp_spiffs.c:523
0x400d6723: esp_vfs_open at /opt/esp/idf/components/vfs/vfs.c:399 (discriminator 3)
0x401fd504: _fopen_r at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/fopen.c:129
0x401fd5ad: fopen at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/fopen.c:168
0x400e43ea: config_check_params_def(web_api_arg_s*) at /project/esp/main/webserver.cpp:1350
0x400e5262: web_call_func(httpd_req*, web_api const*, web_api_arg_s*, int, char const**) at /project/esp/main/webserver.cpp:3776
0x400e58b9: all_api_handler(httpd_req*) at /project/esp/main/webserver.cpp:3848
0x400eca71: httpd_uri at /project/esp/main/esp_http_server/src/httpd_uri.c:313
0x400eb7e0: httpd_parse_req at /project/esp/main/esp_http_server/src/httpd_parse.c:645
(inlined by) httpd_req_new at /project/esp/main/esp_http_server/src/httpd_parse.c:715
0x400ebd93: httpd_sess_process at /project/esp/main/esp_http_server/src/httpd_sess.c:354
0x400ea9a5: httpd_server at /project/esp/main/esp_http_server/src/httpd_main.c:319
0x400dcb02: select_loop at /project/esp/main/select_mgmt.c:139
0x400d9b2c: appmain_task at /project/esp/main/dabmgr.c:134
Backtrace: 0x4008D6B5:0x3FFBECF0 0x40082E15:0x3FFBED10 0x4000BFED:0x3FFBD260 0x400954D2:0x3FFBD270 0x4016C5DB:0x3FFBD290 0x4016C5E7:0x3FFBD2B0 0x400D5B62:0x3FFBD2D0 0x40092E03:0x3FFBD2F0
0x4008d6b5: esp_crosscore_isr at /opt/esp/idf/components/esp_system/crosscore_int.c:92
0x40082e15: _xt_lowint1 at /opt/esp/idf/components/freertos/port/xtensa/xtensa_vectors.S:1114
0x400954d2: vPortClearInterruptMaskFromISR at /opt/esp/idf/components/freertos/port/xtensa/include/freertos/portmacro.h:571
(inlined by) vPortExitCritical at /opt/esp/idf/components/freertos/port/xtensa/port.c:332
0x4016c5db: esp_task_wdt_reset at /opt/esp/idf/components/esp_system/task_wdt.c:330
0x4016c5e7: idle_hook_cb at /opt/esp/idf/components/esp_system/task_wdt.c:80
0x400d5b62: esp_vApplicationIdleHook at /opt/esp/idf/components/esp_system/freertos_hooks.c:51 (discriminator 1)
0x40092e03: prvIdleTask at /opt/esp/idf/components/freertos/tasks.c:3987
ASSERT_PARAM(-218959118 0), in arch_main.c at line 364
Guru Meditation Error: Core  0 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x4008fe2c: 000000f0 00004136 f01d0000
0x4008fe2c: coex_bb_reset_unlock_wrapper at /opt/esp/idf/components/bt/controller/esp32/bt.c:1161
Core  0 register dump:
PC      : 0x4008fe33  PS      : 0x00060c34  A0      : 0x80083f45  A1      : 0x3ffc1338
0x4008fe33: r_assert at /opt/esp/idf/components/bt/controller/esp32/bt.c:1868
A2      : 0x00000000  A3      : 0xf2f2f2f2  A4      : 0x00000000  A5      : 0x3f434846
A6      : 0x0000016c  A7      : 0xfffffffc  A8      : 0x8000814b  A9      : 0x3ffc12a8
A10     : 0x00000000  A11     : 0x3ffc12cb  A12     : 0x3ffc1277  A13     : 0x00000034
A14     : 0x00000000  A15     : 0x3ffc127c  SAR     : 0x00000004  EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000  LBEG    : 0x40083e4d  LEND    : 0x40083e55  LCOUNT  : 0x00000000
0x40083e4d: r_assert_param at ??:?
0x40083e55: r_assert_param at ??:?
Backtrace: 0x4008fe30:0x3ffc1338 |<-CORRUPTED
0x4008fe30: r_assert at /opt/esp/idf/components/bt/controller/esp32/bt.c:1867

@ianzo
Have you resolved the issue? could you provide the code to help me reproduce the issue.

Thanks for reporting, would you please help share if any further updates for the issue? Thanks.

fixed commit:
master 9a46d06532d27954af138cd40e36c599681bb62f
v4.4 f39df9a9c002066b4d2cbc26f086dd5738d94b25
v4.3 8769f62c3b687a4dedf25c748fe040b47ea6b2d4


[Question] - Use Jest instead of Mocha?

I would suggest using jest instead of mocha.
For several reasons:

Reduce dependency for chai
More advanced mocking features
Support to execute one test only direct inside the Webstorm GUI.

What do you think about this suggestion?

Sorry, no, as we discovered in other issues, please read here and i'm just more familiar with mocha and chai

No worries!
Thanks for the hint with the typing error! 👍


Change build flags

-I flag is CFLAGS not LDFLAGS
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. go run cgo.go
go build command-line-arguments: invalid flag in #cgo LDFLAGS: -I/home/emjay/workspace/go-with-intel-sgx/App
Makefile:225: recipe for target 'cgo' failed

Sorry for my late response, I'll merge this PR.


groups: sidebar dividers shown for sections with no joined/visible channels

Describe the bug, optionally with screenshots
Dividers shown for channels that are not visible. Read Only and Admin are the channels in
Urbit Fan Club

Only render the sidebar section divider if the the number of joined channels in that section is non-zero.


Streamlining and speeding up the catalog database and APIs

Background
As part of productionising the catalog, we are looking at settling its database and APIs to match current use and support future features, as well as speeding them up to scale to larger workloads. To do so, we will cut some basically unused features, add new ones, and reshape things slightly.
This work does NOT address the following aspects that are also important, but would need to be tackled as separate such spikes:

Implementing locations as entities
Implementing entity statuses
Implementing entity relations
Splitting apart entities into several contributing fragments

Changes

[ ] Remove support for shorthand syntax when listing entities in the API, e.g. to query for /api/catalog/entities?name=foo instead of ?metadata.name=foo. The shorthands add more confusion and risk than they are worth.
[ ] Remove the feature of handling "too similarly" named entities in the database. This was used to forbid creating both the entity "foo-bar" and the entity "foobar" at the same time, for example. It was added prematurely, comes with significant runtime cost in its current naïve implementation, and led to frustration when ingesting existing imperfect real-world data.
[ ] Introduce a new indexed entity database column full_name, that contains the triplet of kind:namespace/name, lowercased, with "default" as namespace when not given, and has a UNIQUE constraint on it. This partially covers the above point, but is also a requirement for future "weak" references by name to be supported, such as for relationships.
[ ] Introduce a new entity database column data, which contains the entire entity data in JSON form (except the generated values metadata.etag, metadata.generation and metadata.uid). This replaces the two columns metadata and spec, which are removed. The reason for this is (1) simplification of the model since it's unnecessary to store them separately, and (2) there is no real technical reason to only support entities with a spec root tag.
[ ] Remove the entity database columns api_version, kind, name, and namespace. They serve no purpose by being special-cased as columns after the full_name column was added above. If we keep searches "by name" in the API as a special thing, they can still filter using the entities_search table like everything else does, or even full_name.
[ ] Redesign the low level database class to be "batch first". The current refresh loop is massively hampered by using a high level one-item-at-a-time API on top of the actual database, which performs massive amounts of work over and over again, triggers multiple transactions per action, etc. The new lowest-level database API will be similar to before, but as an example, instead of addEntity it would have addEntities that does all of the work of computing new search terms and similar in one large operation. The entity refresh loop can then take advantage of these faster operations.

https://github.com/spotify/backstage/pull/2750

considering this addressed for now - going to do some cleanup of the interfaces, but the ticket as such is addressed enough to be closed


Glow seems to be broken (regression from 772485c)

Operating system or device - Godot version:
Fedora, NVidia GTX900 series, Propietary drivers, Godot version cf286ed28765606fc6834e7fdbaf5550159454b4
Issue description:

Enabling glow on 3d scene causes some weird environment tinting artifacts
glow off

glow on

Steps to reproduce:
Just enable glow, in your environment.
Link to minimal example project:

Related issue: https://github.com/godotengine/godot/issues/9756

Can confirm, issue comes with 772485c.
However, before that commit, glow option makes this artifact (image by kubecz3k)

aparently glow works when DOF is enabled

what, we reverted?
On Tue, Jul 25, 2017 at 4:25 PM, Daniel Ramirez<EMAIL_ADDRESS>wrote:

aparently glow works when DOF is enabled
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/9797#issuecomment-317845435,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z26bPIMAqiofwHcB8JuEMj3jqbCy-ks5sRkEcgaJpZM4Oggor
.

@reduz  im not sure if it was working before under the same conditions.


Add custom headings to listViews

add our campuscompass headings to the top of the lists

See PR#15

Merged #15


WEEK4CHALLENGE tinh.toquang

My submission for Code Challenge of Week 4

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Tô Quang Tịnh seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Option to populate provision profile with local luis config

When your provision luis for local dev through tooling it would be great to have an option to apply  that config to a selected publish profile instead of making the user intuitively add it to it

Found in R13 bug bash but is an R14 task


Bug Fixes on start script for rest api jetty.

Updates to get each sub project building and running properly, except for web-client-jetty.
Problem Description

Fixes #.

Describe the problem you are trying to solve.
Solution
Describe your solution.
how you tested the change
Describe what was done to test the change. This section can be left blank
if automated tests demonstrating usage are provided in the PR.
Where the following done:

[ ] Tests. Check all that apply:

[ ] Unit tests created or modified that run during ant test.
[ ] Integration tests created or modified that run during integration testing
(Formerly called regression tests.)
[ ] Test procedure descriptions for manual testing

[ ] Was relevant documentation updated?
[ ] Were relevant config element (e.g. XML data) updated as appropriate

If you aren't sure leave unchecked and we will help guide you to want needs changing where.

https://github.com/opendcs/rest_api/issues/38


Tests

At a minimum let's do some sort of linting test. Maybe also check the JSON files.

Linting check has been implemented. Maybe do more tests?

When #8 is done, write a test that checks whether only accepted categories are used.


Design doesn't working in Insomnia Designer

What is your question?
I have been imported a postman collection to insomnia designer and it works fine to debug the requests, but when i switch to Design this error message appear:

I sincronized the project with a git repo, and tried set a spec version in .insomnia/ApiSpec yaml without sucess:

Someone can help me please? thanks!

From the screenshot your specification contents are empty, this would be the cause for the lack of rendering since the renderer relies on the specification contents to infer the version.
This would be expected as we haven't built support for import of OpenAPI specifications with postman collections into Designer.

I understand, but where i can set the specification in insomnia files? i tried set the "openapi: '3.0.0'"  in .insomnia/ApiSpec yaml but this doesn't work.
I have used the insomnia editor to design the REST API of this project
You can find the collection design in this repo

@riibeirogabriel You'd set the specification under contents in the ApiSpec or within the editor pane to the right of the preview pane:

Works here, thanks @nijikokun!!


Remove Implicit Compass Dependency

Slick currently calls image-url using three arguments. This signature is compass-specific, so if a (Rails) project that uses Slick isn't using compass this will result in an error.
Sass::SyntaxError at /
wrong number of arguments (3 for 1) for `image-url'

Please switch to calling image-url with a single argument as this is supported by both Compass and Sprockets.
Line 20 of slick.scss:
@function slick-image-url($url) {
  @if function-exists(image-url) {
    @return image-url($url); // Here
  }
  @else  {
    @return url($slick-loader-path + $url);
  }
}

Fixed on dev

Thanks @kenwheeler


fix(notify): customize the title of the verification email based on the copyright

这个 PR 实现什么功能/修复什么问题:

[x] 功能、bugfix描述
[x] 冒烟测试

是否需要 backport 到之前的 release 分支:

release/3.5
release/3.4

/area notify
/cc @zexi

Codecov Report

Merging #8640 into master will increase coverage by 8.95%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #8640      +/-   ##
==========================================
+ Coverage    8.92%   17.87%   +8.95%
==========================================
  Files         418       88     -330
  Lines       50664     8823   -41841
==========================================
- Hits         4520     1577    -2943
+ Misses      45713     7073   -38640
+ Partials      431      173     -258

Flag
Coverage Δ

aFlag
17.87% <ø> (+8.95%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/mcclient/options/loadbalancerbackendgroups.go

pkg/cloudcommon/db/quotas/models.go

pkg/apigateway/clientman/authtoken.go

pkg/compute/regiondrivers/aws.go

pkg/cloudcommon/db/virtualjointbase.go

pkg/compute/guestdrivers/kvm.go

pkg/baremetal/tasks/maintenance.go

pkg/cloudcommon/db/virtualresource.go

pkg/util/qemuimg/init.go

pkg/cloudcommon/db/lock.go

... and 320 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa1a511...d3aae00. Read the comment docs.


[ Trivial ] add more error infor

add more error infor when tflite and input dim mismatch.
Self evaluation:

Build test:	 [X]Passed [ ]Failed [ ]Skipped
Run test:	 [X]Passed [ ]Failed [ ]Skipped

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #2151. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.


Fix a crash when running "SWS/AW: Fade in/out/crossfade selected area of selected items" if a selected item contains empty takes

GetMediaItemTake returns null for empty takes -> GetSetMediaItemTakeInfo(NULL, "D_STARTOFFS", NULL) is also null -> crash.

:white_check_mark: Build sws 751-master completed (commit https://github.com/reaper-oss/sws/commit/7f8ec465aa by @cfillion)

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-crossfade-empty-take-crash-7f8ec465.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-crossfade-empty-take-crash-7f8ec465.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-crossfade-empty-take-crash-7f8ec465.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-crossfade-empty-take-crash-7f8ec465.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-crossfade-empty-take-crash-7f8ec465.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-crossfade-empty-take-crash-7f8ec465.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-crossfade-empty-take-crash-7f8ec465.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-crossfade-empty-take-crash-7f8ec465.tar.xz

Windows 64-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x64.pdb
build/sws-<IP_ADDRESS>-Windows-x64-crossfade-empty-take-crash-7f8ec465.exe

Windows 32-bit

build/BuildUtils/SWS_Template.ReaperLangPack
build/BuildUtils/whatsnew.html
build/reaper_sws-x86.pdb
build/sws-<IP_ADDRESS>-Windows-x86-crossfade-empty-take-crash-7f8ec465.exe

macOS x86 64-bit

build/sws-<IP_ADDRESS>-Darwin-x86_64-crossfade-empty-take-crash-7f8ec465.dmg

macOS x86 32-bit

build/sws-<IP_ADDRESS>-Darwin-i386-crossfade-empty-take-crash-7f8ec465.dmg

macOS ARM 64-bit

build/sws-<IP_ADDRESS>-Darwin-arm64-crossfade-empty-take-crash-7f8ec465.dmg

Linux x86 64-bit

build/sws-<IP_ADDRESS>-Linux-x86_64-crossfade-empty-take-crash-7f8ec465.tar.xz

Linux x86 32-bit

build/sws-<IP_ADDRESS>-Linux-i686-crossfade-empty-take-crash-7f8ec465.tar.xz

Linux ARM 64-bit

build/sws-<IP_ADDRESS>-Linux-aarch64-crossfade-empty-take-crash-7f8ec465.tar.xz

Linux ARM 32-bit

build/sws-<IP_ADDRESS>-Linux-armv7l-crossfade-empty-take-crash-7f8ec465.tar.xz

Is AppVeyor over-motivated, building every flavour twice? :P (except Win 32 bit I think).

The Win32 job failed the first time (IP temporary banned from downloading php due to too many requests), and when I did "re-run incomplete" later it re-ran everything. Looks like it's a known issue: https://help.appveyor.com/discussions/questions/56301-re-run-incomplete-jobs-re-runs-all-jobs.


[Loan / Temporary Exchange] tracking

Sometimes we may not want to move a given card SKU from a container to a deck permanently, maybe this is a temporary move (replacing proxies in a deck with real cards for a sanctioned tournament and then swapping them back to proxies when done), or we may be loaning out cards to someone.
In this case, we want to be able to mark cards as being [exchanged / on loan] in some other deck and be able to track these temporary exchanges.

[x] New migration + data model to model a temporary loan
[x] New top-level loans tab
[x] Loan editor

[x] BUG: The "cards taken out of this deck" list is incorrect after saving when re-opening the editor
[ ] Deck list should exclude cards from "cards taken out of this deck" and include "cards loaned to this deck"

[ ] In deck details view, indicates cards which are on loan to this deck and hide cards which have been taken out of a given exchange
[ ] In container and card search view, indicate cards which are on loan to another deck
[ ] In card search view, add a new preset for cards which are on loan
[x] Add guards to prevent dismantling/deleting decks and containers that contains cards involved in an active loan exchange

Closing. Too much effort for something a simple collection note can cover.


Create MdxSanitizerPackage

Summary
Related #952
Create a [PRIVATE] "MdxSanitizer" package that exports a plugin that can be injected into the mdx parser, receive the AST information when called and look for the various unsupported code and errors and handling in the following way:

Replace Unknown Components with "UnknownComponent notification"
- (will need list of HTMLTags to ignore: https://github.com/carbon-design-system/carbon-platform/blob/b0fc88e7de39623d667819732008b3f122a0ed9a/packages/mdx-sanitizer/src/main/html-tags.mjs)
- will need to receive list of supported custom component keys
- Link out to storybook

Imports/Exports -> Replace entire tree with the "Unsupported Imported/Export Component notification"

If unable to parse stringified mdx source, show ""ParsingError" Component

The package will also export a "sanitizeStringMdxSource" function that will:

Remove HTML Comments
- we have to do this BEFORE parsing, otherwise it breaks

 // remove HTML comments  sanitizedUsageFileSource = usageFileSource.replace(/<!--(.|\n)*?-->/g, '')

Lastly, if for any reason the parsed MDX cannot be successfully rendered in the web app UI, this error shall be caught and replaced by a "FullPageError" component:

For FullPageError when parsed mdx can't be rendered due to an error, log a "warning" message in case we need to track special cases.

Package:

@carbon-platform/api/mdx-sanitizer
Exports:
- mdxSanitizerPlugin(customComponentsKeys): Function (mdxPlugin type)
- sanitizeStringMdxSource(string): string

Structure:

packages/api/mdx-sanitizer

/src/
-main/
-html-tags.js
-mdx-sanitizer-plugin.js
-index.js
-utils
-test/
-mdx-sanitizer-plugin.test.js
- test-files/*

-services/web-app/utils/mdx <- will be used to create a function that will generate the parser that injects and consumes the plugin (this logic needs to be taken out of github.js in the web-app)

Hey team! Please add your planning poker estimate with ZenHub @andreancardona @francinelucca


Create crypto submodules

This PR is code move only.
Create two new submodules in the crypto module, ecdsa and sighash.

Move error code to a separate submodule
Move sighash types to a separate submude

All patches are code moves only (the last patch re-orders the code). The changes here were originally done in #1989, I redid the whole thing to make sure there were no rebase mistakes. Put up as a separate PR to ease review and qualify for the "Refactor carve-out".

This PR can be merged two weeks after getting a single ACK under the "Refactor carve-out".

I'd prefer to get rid of crypto completely and put these things into the other modules. Especially after #2156 where the code organization looks weird.

I'm not exactly sure where we are up to with crate smashing but getting rid of crypto at this stage seems like going round in circles because we only just created it, supposedly as a step in crate smashing.

@Kixunil where would you propose we put these things? It does seem like we're going in circles here.
The crypto module was introduced in https://github.com/rust-bitcoin/rust-bitcoin/pull/1260 for reference.

In case it helps, I've put all crate smashing tasks on hold because its hard to get anywhere, the next piece of the puzzle is bitcoin-io.

At the very least move the contents of crypto::taproot into taproot. Consider flattening the rest. (Move the modules into src/)

I agree that we shouldn't have two modules named taproot. IIRC the crypto one has signature stuff only. We could rename it to bip340 which I think would be much clearer.
But maybe Kix is right that we should try flattening it. Or maybe we should just flatten the crypto module so it has no submodules. (We can keep the existing file structure, just make the submodules private and re-export all the types.)

With the whole "two taproot modules" thing, I tried to hide it from downstream by making the crypto one private, I didn't think it would be so confusing for us :(

@apoelstra while bip340 would be technically clear it wouldn't be that easy to follow for people who don't remember all the BIP numbers by heart. Even I only remember couple important/(in)famous ones (21, 32, 39, 70...) Also now I'm thinking maybe we should rename existing bip* modules to use names rather than numbers and put the number in the doc comment.
Also the code in taproot and crypto::taproot is strongly linked from what I've seen (but maybe I just got confused).

I wouldn't mind renaming the bip* modules where there's a common well-known name. I think all of them except 32 can be changed.
Having said that, I wonder if we need to back up and try to define the entire module structure of this crate before moving forward, since trying to make individual changes like this is starting to lead us in circles.

I wouldn't mind renaming the bip* modules where there's a common well-known name. I think all of them except 32 can be changed.
Having said that, I wonder if we need to back up and try to define the entire module structure of this crate before moving forward, since trying to make individual changes like this is starting to lead us in circles.

Having said that, I wonder if we need to back up and try to define the entire module structure of this crate before moving forward, since trying to make individual changes like this is starting to lead us in circles.

What if we come up with a prototypical set of applications/libraries that use rust-bitcoin. Allowing us to come up with concrete sets of things required by such users, then we have a clearer picture of what we are trying to achieve with the crate smashing. At some stage I rekon we need to get on a call (or plane) and nut this out.

That sounds good to me. I think rust-lightning, rust-miniscript, bdk and esplora are the big ones. But we also want to support script hackery like whatever @stevenroose is currently working on as well as ICBOC. (Though I suspect that supporting the big things will imply that we support the small things.)

I think hd_derivation would be an understandable name for BIP32. :) But yeah, that one is famous by number so I wouldn't be too worried about it.
@tcharding great idea! Among those mentioned by @apoelstra I would like to see a nice way of passing around primitive "interface" types (amount, address, txid...) without all complicated features so that different libraries can communicate them well without pulling in everything but a kitchen sink and blowing up the compilation time.

I think rust-lightning, rust-miniscript, bdk and esplora are the big ones.

You mean electrs, right? Any reason to use blockstream's version over Roman's version? Both would be leveraging rust-bitcoin in the same manner, right?
@dpc is it fair to say that Fedimint is not leveraging rust-bitcoin in any way not covered by bdk and rust-lightning?

Not sure how much they diverged but FWIW the Roman's version uses P2P as well, so that might cover more API surface.

Yeah, I didn't realize there was a difference. I meant electrs then.

I know you said you do not like the crypto module in general @Kixunil. If it is tolerable I'd like to merge this before then later going on to resolving what to really do with the crypto module. I have a tree of PRs that all build on top of this one.

Fuck, review time is more valuable than dev time. Closing.


Assignment (like $var = 123) is not recognized

It now has a rudimentary level of support, it no longer generates an exception.

Now supported


Fix issue 421 kafka receiver

Add initialPoll to wait for consumer group join
Link to Branch

Motivation and Context
In a kafka consume step, on the first poll, a consumer group join will be triggered.
This can take multiple seconds to complete. Currently we use will use our maxNoOfRetryPollsOrTimeouts in that time.
If the consumer group join has not finished we return without any result or meaningful message.
The proposed change will move the initial poll out of the loop.
Additionally if the initial poll fails an exception will be thrown.
Checklist:

[ X] Unit tests added

[ ] Integration tests added

[ X] Test names are meaningful

[ X] Feature manually tested

[ ] Branch build passed

[ X] No 'package.*' in the imports

[ ] Relevant Wiki page updated with clear instruction for the end user

[ ] Not applicable. This was only a refactor change, no functional or behaviour changes were introduced

[ ] Http test added to http-testing module(if applicable) ?

[X ] Not applicable. The changes did not affect HTTP automation flow

[ X] Kafka test added to kafka-testing module(if applicable) ?

[ ] Not applicable. The changes did not affect Kafka automation flow

The build is green.


References not saved/incompletely saved on MacOsX in both stencila and texture

This issue also posted on stencila desktop repository at https://github.com/stencila/desktop/issues/68 (however these problems appear to be originating from Texture)
References are saved erratically. Sometimes they are not saved at all (I have a manuscript being edited that I can send you for testing that replicates this).
With newly created empty files, references with only their title field filled out are saved but said title is missing when reopening the file. In one instance when reopening the file I got the following error:
Importing JATS
Parse XML
Validate JATS
 is incomplete. Schema: (inline-supplementary-material|related-article|related-object|hr|string-date|bold|fixed-case|italic|monospace|overline|overline-start|overline-end|roman|sans-serif|sc|strike|underline|underline-start|underline-end|ruby|alternatives|inline-graphic|private-char|chem-struct|inline-formula|label|tex-math|mml:math|abbrev|milestone-end|milestone-start|named-content|styled-content|annotation|article-title|chapter-title|collab|collab-alternatives|comment|conf-acronym|conf-date|conf-loc|conf-name|conf-sponsor|data-title|date|date-in-citation|day|edition|email|elocation-id|etal|ext-link|fpage|gov|institution|institution-wrap|isbn|issn|issn-l|issue|issue-id|issue-part|issue-title|lpage|month|name|name-alternatives|object-id|page-range|part-title|patent|person-group|pub-id|publisher-loc|publisher-name|role|season|series|size|source|std|string-name|supplement|trans-source|trans-title|uri|version|volume|volume-id|volume-series|year|fn|target|xref|sub|sup|x)+

Transform JATS -> TextureArticle
Validate Dar Article
Transform TextureArticle -> InternalArticle
Validate Texture Article
Essentially saving behavior is erratic. I deem this issue as blocking/high priority since it makes using stencila or texture on real manuscript drafting impossibile, even as a willing beta tester.

@lollopus we are aware of these issues, and as you say they are originating from Texture. We are working on getting all this stable until September, when we plan to release Texture 1.0, and also update Stencila.

Good to know. I'd like to help with beta testing but at this stage I'll wait for your September release. cheers, L


Better popups

@ginnyTheCat, the more compact JSON is looking nice, as are the est_width and segregated fixes

The Popup looks super good. I like it a lot 👍


Update admin dashboard

Update admin dashboard to make it easier to view usage per user.
I don't know how to upload to that "cloud.github" for hosting gifs so here is a link...
Dashboard Gif

@mattstauffer hopefully this is helpful ):

@RDelorier man. Lots of great work in this. Thank you! Looking forward to trying it out!

You're welcome, man I gotta say working on an app with decent test coverage makes stuff a lot easier. This is definitely helping me sharpen up some stuff so thanks for allowing contributions :+1:

@RDelorier :) glad to hear it!

haha, just figured out how to upload to the cloud.github.com, drag and drop zzz next time!


hyprpm update failed after upgrading to v0.41.0

Bug or Regression?
Bug
System Info and Version
 System/Version info
Hyprland, built from branch  at commit ea2501d4556f84d3de86a4ae2f4b22a474555b9f  (props: bump version to 0.41.0).
Date: Mon Jun 10 14:23:06 2024
Tag: v0.41.0, commits: 4794

flags: (if any)

System Information:
System name: Linux
Node name: nianyu-arch
Release: 6.9.4-arch1-1
Version: #1 SMP PREEMPT_DYNAMIC Wed, 12 Jun 2024 20:17:17 +0000

GPU information:
00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-P [Iris Xe Graphics] [8086:a7a0] (rev 04) (prog-if 00 [VGA controller])

os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

Description
➜  Hyprland git:(v0.41.0) ✗ hyprpm update -n -v
[v] version returned: Hyprland, built from branch  at commit ea2501d4556f84d3de86a4ae2f4b22a474555b9f  (props: bump version to 0.41.0).
Date: Mon Jun 10 14:23:06 2024
Tag: v0.41.0, commits: 4794

flags: (if any)

[v] parsed commit ea2501d4556f84d3de86a4ae2f4b22a474555b9f at branch  on Mon Jun 10 14:23:06 2024, commits 4794

! Cloning https://github.com/hyprwm/hyprland, this might take a moment.
[v] will shallow since: Mon Jun 03 14:23:06 2024

✔ cloned
[v] git returned (co): Your branch is up to date with 'origin/main'.

[v] git returned (rs): rm 'subprojects/tracy'
HEAD is now at ea2501d props: bump version to 0.41.0

✔ checked out to running ver
! configuring Hyprland
[v] setting PREFIX for cmake to /home/nianyu/.local/share/hyprpm/headersRoot
[v] cmake returned: CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:253 (message):
  Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
  target architecture is known.  Please enable at least one language before
  including GNUInstallDirs.
Call Stack (most recent call first):
  CMakeLists.txt:5 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.
Not searching for unused variables given on the command line.

-- The C compiler identification is GNU 14.1.1
-- The CXX compiler identification is GNU 14.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Gathering git info
-- Found Python3: /usr/bin/python3.12 (found version "3.12.3") found components: Interpreter
Building itab.c/itab.h...
-- Setting up wlroots
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.1.1")
-- Found WaylandScanner at /usr/bin/wayland-scanner
-- Found wayland-protocols at //usr/share/wayland-protocols
-- Configuring Hyprland in Release with CMake
-- Checking deps...
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found OpenGL: /usr/lib/libOpenGL.so  found components: GLES3
-- Checking for modules 'xkbcommon;uuid;wayland-server;wayland-client;wayland-cursor;wayland-protocols;cairo;pango;pangocairo;pixman-1;libdrm;libinput;hwdata;libseat;libdisplay-info;libliftoff;libudev;gbm;hyprlang>=0.3.2;hyprcursor>=0.1.7'
--   Found xkbcommon, version 1.7.0
--   Found uuid, version 2.40.1
--   Found wayland-server, version 1.23.0
--   Found wayland-client, version 1.23.0
--   Found wayland-cursor, version 1.23.0
--   Found wayland-protocols, version 1.36
--   Found cairo, version 1.18.0
--   Found pango, version 1.54.0
--   Found pangocairo, version 1.54.0
--   Found pixman-1, version 0.43.4
--   Found libdrm, version 2.4.121
--   Found libinput, version 1.26.0
--   Found hwdata, version 0.383
--   Found libseat, version 0.8.0
--   Found libdisplay-info, version 0.1.1
--   Found libliftoff, version 0.5.0
--   Found libudev, version 255
--   Found gbm, version 24.1.1-arch1.1
--   Found hyprlang, version 0.5.2
--   Found hyprcursor, version 0.1.9
CMake Error at CMakeLists.txt:119 (find_package):
  By not providing "Findhyprwayland-scanner.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "hyprwayland-scanner", but CMake did not find one.

  Could not find a package configuration file provided by
  "hyprwayland-scanner" (requested version 0.3.10) with any of the following
  names:

    hyprwayland-scannerConfig.cmake
    hyprwayland-scanner-config.cmake

  Add the installation prefix of "hyprwayland-scanner" to CMAKE_PREFIX_PATH
  or set "hyprwayland-scanner_DIR" to a directory containing one of the above
  files.  If "hyprwayland-scanner" provides a separate development package or
  SDK, be sure it has been installed.

-- Configuring incomplete, errors occurred!

[v] meson returned: The Meson build system
Version: 1.4.1
Source dir: /tmp/hyprpm/hyprland-nianyu/subprojects/wlroots-hyprland
Build dir: /tmp/hyprpm/hyprland-nianyu/subprojects/wlroots-hyprland/build
Build type: native build
WARNING: failed to process netrc file: ~/.netrc access too permissive: access permissions must restrict access to only the owner (None, line None).
Project name: wlroots
Project version: 0.18.0-dev
C compiler for the host machine: cc (gcc 14.1.1 "cc (GCC) 14.1.1 20240522")
C linker for the host machine: cc ld.bfd 2.42.0
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -Wundef: YES
Compiler for C supports arguments -Wlogical-op: YES
Compiler for C supports arguments -Wmissing-include-dirs: YES
Compiler for C supports arguments -Wold-style-definition: YES
Compiler for C supports arguments -Wpointer-arith: YES
Compiler for C supports arguments -Winit-self: YES
Compiler for C supports arguments -Wstrict-prototypes: YES
Compiler for C supports arguments -Wimplicit-fallthrough=2: YES
Compiler for C supports arguments -Wendif-labels: YES
Compiler for C supports arguments -Wstrict-aliasing=2: YES
Compiler for C supports arguments -Woverflow: YES
Compiler for C supports arguments -Wmissing-prototypes: YES
Compiler for C supports arguments -Walloca: YES
Compiler for C supports arguments -Wno-missing-braces: YES
Compiler for C supports arguments -Wno-missing-field-initializers: YES
Compiler for C supports arguments -Wno-unused-parameter: YES
Compiler for C supports arguments -fmacro-prefix-map=/prefix/to/hide=: YES
Found pkg-config: YES (/usr/bin/pkg-config) 2.1.1
Run-time dependency wayland-server found: YES 1.23.0
Run-time dependency libdrm found: YES 2.4.121
Run-time dependency xkbcommon found: YES 1.7.0
Run-time dependency pixman-1 found: YES 0.43.4
Library m found: YES
Library rt found: YES
Run-time dependency wayland-protocols found: YES 1.36
Build-time dependency wayland-scanner found: YES 1.23.0
Program /usr/bin/wayland-scanner found: YES (/usr/bin/wayland-scanner)
Has header "linux/dma-buf.h" : YES
Run-time dependency egl found: YES 1.5
Run-time dependency gbm found: YES 24.1.1-arch1.1
Run-time dependency glesv2 found: YES 3.2
Program ./embed.sh found: YES (/tmp/hyprpm/hyprland-nianyu/subprojects/wlroots-hyprland/render/gles2/shaders/./embed.sh)
Dependency pixman-1 found: YES 0.43.4 (cached)
Dependency gbm found: YES 24.1.1-arch1.1 (cached)
Checking for function "gbm_bo_get_fd_for_plane" with dependency gbm: YES
Run-time dependency libudev found: YES 255
Run-time dependency libseat found: YES 0.8.0
Build-time dependency hwdata found: YES 0.383
Run-time dependency libdisplay-info found: YES 0.1.1
Run-time dependency libliftoff found: YES 0.5.0
Run-time dependency libinput found: YES 1.26.0
Run-time dependency xcb found: YES 1.17.0
Run-time dependency xcb-dri3 found: YES 1.17.0
Run-time dependency xcb-present found: YES 1.17.0
Run-time dependency xcb-render found: YES 1.17.0
Run-time dependency xcb-renderutil found: YES 0.3.10
Run-time dependency xcb-shm found: YES 1.17.0
Run-time dependency xcb-xfixes found: YES 1.17.0
Run-time dependency xcb-xinput found: YES 1.17.0
Run-time dependency wayland-client found: YES 1.23.0
Run-time dependency xwayland found: YES 24.1.0
Dependency xcb found: YES 1.17.0 (cached)
Run-time dependency xcb-composite found: YES 1.17.0
Run-time dependency xcb-ewmh found: YES 0.4.2
Run-time dependency xcb-icccm found: YES 0.4.2
Dependency xcb-render found: YES 1.17.0 (cached)
Run-time dependency xcb-res found: YES 1.17.0
Dependency xcb-xfixes found: YES 1.17.0 (cached)
Run-time dependency xcb-errors found: YES 1.0.1
Checking for function "xcb_xfixes_set_client_disconnect_mode" with dependencies xcb, xcb-composite, xcb-ewmh, xcb-icccm, xcb-render, xcb-res, xcb-xfixes, xcb-errors: YES
Configuring config.h using configuration
Configuring version.h using configuration
Configuring config.h using configuration
Message: Patches found. Applying...
NEW: 'patches/backend-drm-add-support-for-libliftoff-v0.5.0.patch'
NEW: 'patches/nvidia-hardware-cursors.patch'
NEW: 'patches/surface-nondivisible-by-scale.patch'
Build targets in project: 136

wlroots 0.18.0-dev

    drm-backend     : YES
    x11-backend     : YES
    libinput-backend: YES
    xwayland        : YES
    gles2-renderer  : YES
    vulkan-renderer : NO
    gbm-allocator   : YES
    session         : YES
    xcb-errors      : YES
    egl             : YES
    libliftoff      : YES

  User defined options
    examples        : false
    renderers       : gles2

Found ninja-1.12.1 at /usr/bin/ninja

✔ configured Hyprland
[v] installation will run: sed -i -e "s#PREFIX = /usr/local#PREFIX = /home/nianyu/.local/share/hyprpm/headersRoot#" /tmp/hyprpm/hyprland-nianyu/Makefile && cd /tmp/hyprpm/hyprland-nianyu && make installheaders
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╍━━━━━━━━━  4 / 5  Installing sources[v] installer returned: # remove previous headers from hyprpm's dir
rm -fr /home/nianyu/.local/share/hyprpm/headersRoot/include/hyprland
mkdir -p /home/nianyu/.local/share/hyprpm/headersRoot/include/hyprland
mkdir -p /home/nianyu/.local/share/hyprpm/headersRoot/include/hyprland/protocols
mkdir -p /home/nianyu/.local/share/hyprpm/headersRoot/include/hyprland/wlr
mkdir -p /home/nianyu/.local/share/hyprpm/headersRoot/share/pkgconfig
cmake --build ./build --config Release --target generate-protocol-headers
ninja: error: loading 'build.ninja': No such file or directory
make: *** [Makefile:54: installheaders] Error 1

✖ failed to install headers with error code 3
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  5 / 5  Failed

✖ Headers corrupted. Please run hyprpm update to fix those.
sh: -c: line 1: unexpected EOF while looking for matching `''

hyprpm update -n -v failed. I have also tried to clone the repo and install headers but got same error.
➜  Hyprland git:(v0.41.0) sed -i -e "s#PREFIX = /usr/local#PREFIX = /home/nianyu/.local/share/hyprpm/headersRoot#" Makefile
➜  Hyprland git:(v0.41.0) ✗ make installheaders
# remove previous headers from hyprpm's dir
rm -fr /home/nianyu/.local/share/hyprpm/headersRoot/include/hyprland
mkdir -p /home/nianyu/.local/share/hyprpm/headersRoot/include/hyprland
mkdir -p /home/nianyu/.local/share/hyprpm/headersRoot/include/hyprland/protocols
mkdir -p /home/nianyu/.local/share/hyprpm/headersRoot/include/hyprland/wlr
mkdir -p /home/nianyu/.local/share/hyprpm/headersRoot/share/pkgconfig
cmake --build ./build --config Release --target generate-protocol-headers
ninja: error: loading 'build.ninja': No such file or directory
make: *** [Makefile:54: installheaders] Error 1

How to reproduce
hyprpm update -n -v

Crash reports, logs, images, videos
No response

Try doing a force update.
hyprpm --force --verbose

CMake Error at CMakeLists.txt:119 (find_package):
  By not providing "Findhyprwayland-scanner.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "hyprwayland-scanner", but CMake did not find one.

  Could not find a package configuration file provided by
  "hyprwayland-scanner" (requested version 0.3.10) with any of the following
  names:

    hyprwayland-scannerConfig.cmake
    hyprwayland-scanner-config.cmake

  Add the installation prefix of "hyprwayland-scanner" to CMAKE_PREFIX_PATH
  or set "hyprwayland-scanner_DIR" to a directory containing one of the above
  files.  If "hyprwayland-scanner" provides a separate development package or
  SDK, be sure it has been installed.

-- Configuring incomplete, errors occurred!

I had the same error. Worked for me after installing hyprlwayland-scanner package.
https://archlinux.org/packages/extra/x86_64/hyprwayland-scanner/

same :(


matio not found for Lua 5.3 5.2 5.1

$luarocks install matio
matio not found for Lua 5.2.
Checking if available for other Lua versions...
Checking for Lua 5.1...
Checking for Lua 5.3...
Checking for Lua 5.4...
Error: No results matching query were found for Lua 5.2.

same problem for lua 5.1


IncludePrerelease flag feature

Is there a way to specify "IncludePrerelease" flag when calling "satisfies" on a NPM semver type?
Original issue: https://github.com/vdurmont/semver4j/issues/58

I am also running into a need for this, but am wondering if the current behavior in v5.1.0 might possibly be a bug.
System.out.println(new Semver("1.0.1-PRERELEASE").isGreaterThan(new Semver("1.0.0")));
System.out.println(new Semver("1.0.1-PRERELEASE").satisfies(">=1.0.0"));

outputs:
true
false

This seems incorrect. I'm unclear on how 1.0.1-PRERELEASE could be greater than 1.0.0 but not satisfy >=1.0.0.

I'll do my best to implement this - soon.
If you want to contribute - fell free.

I have a PR up for this here: https://github.com/semver4j/semver4j/pull/299


mmap() fails on tmpfs (operation not permitted)

Version 17101. Took a bit to figure out where mmap() was going wrong here. Works on lxfs (/home), but not tmpfs (/run). Fine on Real Linux tmpfs (but we know that) [edit: don't assume things, Ken]. Code below is taken nearly verbatim from here.
Repro:
$ g++ mmap-fail.cpp -o mmap-fail
$ sudo ./mmap-fail
mmap() failed: : Operation not permitted

Test case:
// mmap-fail.cpp
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <stdio.h>

int main(int argc, const char* argv[])
{
    //const char* path = "./eightbytes.bin"; // okay on lxfs
    const char* path = "/run/eightbytes.bin";
    int fd = open(path,
        O_RDWR|O_CREAT|O_CLOEXEC|O_NOCTTY|O_NOFOLLOW, 0644);
    if (fd < 0) {
        perror("open() failed: ");
        return 1;
    }
    int r = posix_fallocate(fd, 0, sizeof(uint64_t));
    if (r < 0) {
        perror("posix_fallocate() failed: ");
        return 1;
    }
    uint64_t *p = (uint64_t*)mmap(NULL, sizeof(uint64_t), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
    if (p == MAP_FAILED) {
        perror("mmap() failed: ");
        return 1;
    }

    printf("Whee!\n");
    return 0;
}

And sudo strace -o mmap-fail.strace ./mmap-fail for pedantry:
execve("./mmap-fail", ["./mmap-fail"], [/* 15 vars */]) = 0
[...blah blah]
open("/run/eightbytes.bin", O_RDWR|O_CREAT|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC, 0644) = 3
fallocate(3, 0, 0, 8)                   = 0
mmap(NULL, 8, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = -1 EPERM (Operation not permitted)
dup(2)                                  = 4
fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
brk(NULL)                               = 0x1390000
brk(0x13b1000)                          = 0x13b1000
fstat(4, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
write(4, "mmap() failed: : Operation not p"..., 41) = 41

@therealkenc I believe your Linux configuration is different than what comes on a stock Ubuntu install. Take a look at your /proc/self/mountinfo file.  Is the /run tmpfs mount mounted with the noexec flag?
I suspect for you it's not, but for me it is:

Thanks for looking Ben and great analysis. Never say "fine on Real Linux natch", dammit. The real code is remounting /run (far away) and I need to look closer at why it is failing. Ugh. I'll post once/if I find an actual diverge. But your reply really helped, this is easier with two eyeballs.

@therealkenc - No problem, let me know if you' find anything that jumps out at you.

Nah. This is squarely linux-behavior.
What I saw was: works on Linux (because journald works obv), identical sequence works on lxfs, identical sequence doesn't work on WSL tmpfs, and stopped right there assuming broken mmap() on tmpfs. I didn't consider external factors on the mount. I am not sure precisely how/where in the code /run gets set up to make journald happy (because it looks noexec on Linux too), but everything is all namespacy so what you see isn't necessarily what a process gets. Sigh.

@therealkenc I believe your Linux configuration is different than what comes on a stock Ubuntu install.
Take a look at your /proc/self/mountinfo file. Is the /run tmpfs mount mounted with the noexec flag?

Dammit... No, /run is noexec on my Real Linux too, seems. Now it is going to haunt me whether really wasn't noexec back in February 2018, and I never really looked because the explanation was so plausible. Because not bothering to look sounds like something I would do.
Re-ran the OP test case on stock Ubuntu Bionic just now. Yeah, passes even with noexec, and, my previous supposition "the real code is remounting /run (far away) and I need to look closer at why it is failing" is almost certainly wrong. I never did "look closer" into why it was failing (my systemd experiment ran course). The OP snippet was from systemd-journald(8). Which probably still won't run and has resurfaced ref #3937.

WSL2 good enough for me. WSL1 LZ can be #3937.


RFC: Loading images from SPI flash

RFC: Loading images from SPI flash
I'm using tinybmp on a STM32 micro with limited RAM.  In my use case, I cannot afford to load an image into RAM and then copy it over onto a second RAM buffer, when draw() is invoked.
What would work (methinks) is if I could just read the flash memory from inside the raw pixels iterator, that is, replacing this get() call with a spi_memory::Read::read() call instead.  I believe this would cut the RAM requirements in half, which might be of interest to other users of tinybmp.
At first I attempted to create a wrapper struct around spi_memory::Flash that would present a non-mutable slice interface to tinybmp (SliceIndex).  The beauty of that is that I would not have to modify tinybmp nor add a new dependency (spi-memory) to it.  But I failed:  I could not find a way to invoke the flash read function from within the index() implementation.  index() is passed a non-mutable self, whereas spi_memory::read() takes a mutable self.
So I'll try and implement this by forking the project.  Before implementing this, I wanted to ask if this functionality is something you might be interesting in merging back into the project. If so, please let me know how would you like the API to be modified for it.  Currently I don't have a clean interface change in mind: I'll just try to make it work by any means necessary, and then worry about whether this is something worth sharing.
Thanks!

Sorry for not replying earlier, but tinybmp development has stalled at the moment.
Being able to draw a BMP file directly from an external source without having to buffer the entire image first would be a very useful feature. If you want to try to implement this you should base it on the code in PR #28, which changes the way the pixels in the BMP file are accessed.

@rfuest Thank you for the feedback and the pointer to that PR.  I'll review and report back.

@rfuest I've made good progress on this, but I'm stuck very close to the finish line...
I wrote a new BmpReader trait that provides a method to read() into a caller-provided buffer as well as a buffered_read() method to be used by a new BmpReaderIterator.  The read() call is used to load just the BMP header into a buffer.  This buffer must be kept around for the lifetime of the Bmp structs.  The buffered_read() and associated iterator were an attempt to generalize ChunksExact so it could work with things other than byte slices. The internal buffer would hold one row at a time, and implement an Iterator that could be easily (ha!) plugged into the RawColors iterator.
This approach requires RAM for (1) the BMP header and (2) a single BMP row.  The example image I'm working is 5730 bytes and only would require 130 + 27 bytes of RAM to load instead of the full slice of 5730 bytes.  (The RAM for the embedded_graphics display would still be needed, but that's a different battle).
(1) Is working well.  I implemented a from_reader() function that does the trick.  Passes the tests that just involve the BMP header.
(2) Is problematic.  I wrote an iterator that can load data one row at a time.  The problem is that I cannot feed this iterator into RawDataSlice() as the latter expects a &[u8] instead of the generic Ref<'_, u8> item that the iterator generates (a cell::Ref is required because the internal buffer is inside a RefCell).
I'd love some feedback on this approach and (ideally!) a solution to my problem with Ref lifetimes and the RawDataSlice().  Maybe you can suggest someone to look at the code?  I'm keeping my work in this branch of my tinybmp fork.
Cheers!

Great to hear that you made progress. Unfortunately I'll be away for the next two weeks and don't have time to look at the code until I'm back.
@jamwaffles: Perhaps you could take a look at this and finish the review of PR #28, which the new code is based on.

I finally found a workaround to reduce the RAM requirements:  I can read my images in smaller tiles from flash and calling draw() once for each tile.  This way the image is never stored entirely in memory.  So, I'll abandon this work.  The repo branch will stay up in case anyone is interested in picking up that effort.