[481] Migrate visa sponsorships

Context

https://trello.com/c/v9bhJE9a/481-publish-ttapi-merge-migrate-visa-sponsorship

Changes proposed in this pull request

Migrate over visa sponsorships from publish

Guidance to review
Checklist

[x] Make sure all information from the Trello card is in here
[x] Attach to Trello card
[x] Rebased master
[x] Cleaned commit history
[x] Tested by running locally

Test in review app, LGTM. Couple of minor comments regarding file naming, otherwise this is good to go.


[TW#26739] No boot error with: memory_layout: SOC_RESERVE_MEMORY_REGION region range 0xfffffffc - 0x00000000 overlaps with 0xffffffff - 0xffffffff

Environment

Development Kit:      [ESP32-Wrover-Kit]
Kit version (for WroverKit/PicoKit/DevKitC): [?]
Core (if using chip or module): []
IDF version (git rev-parse --short HEAD to get the commit id.):
9ca30f6
Development Env:		[Make]
Operating System:		[MacOS]
Power Supply:         [USB]

Problem Description
Suddenly, my app does not boot anymore. I've reverted my changes and it still does not boot up.
I get this output:
I (186) boot: ESP-IDF v3.2-dev-915-g6f58208 2nd stage bootloader
I (187) boot: compile time 07:12:15
I (187) boot: Enabling RNG early entropy source...
I (207) boot: SPI Speed      : 40MHz
I (220) boot: SPI Mode       : DIO
I (233) boot: SPI Flash Size : 4MB
I (246) boot: Partition Table:
I (257) boot: ## Label            Usage          Type ST Offset   Length
I (279) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (303) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (326) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (349) boot:  3 factory          factory app      00 00 00010000 000f0000
I (372) boot:  4 ota_0            OTA app          00 10 00100000 00100000
I (396) boot:  5 ota_1            OTA app          00 11 00200000 00100000
I (419) boot:  6 storage          Unknown data     01 82 00300000 00100000
I (443) boot: End of partition table
I (456) boot: Defaulting to factory image
I (470) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x1fffc (131068) map
I (773) esp_image: segment 1: paddr=0x00030024 vaddr=0x3ffbdb60 size=0x031ac ( 12716) load
I (803) esp_image: segment 2: paddr=0x000331d8 vaddr=0x3ffc0d0c size=0x00000 (     0) load
I (805) esp_image: segment 3: paddr=0x000331e0 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

I (831) esp_image: segment 4: paddr=0x000335e8 vaddr=0x40080400 size=0x0ca28 ( 51752) load
I (981) esp_image: segment 5: paddr=0x00040018 vaddr=0x400d0018 size=0x82868 (534632) map
0x400d0018: _stext at ??:?

I (2103) esp_image: segment 6: paddr=0x000c2888 vaddr=0x4008ce28 size=0x02e00 ( 11776) load
0x4008ce28: vPortYield at /Users/cyril/esp/esp-idf/components/freertos/portasm.S:528

I (2133) esp_image: segment 7: paddr=0x000c5690 vaddr=0x400c0000 size=0x00000 (     0) load
I (2135) esp_image: segment 8: paddr=0x000c5698 vaddr=0x50000200 size=0x00000 (     0) load
I (2217) boot: Loaded app from partition at offset 0x10000
I (2217) boot: Disabling RNG early entropy source...
I (2221) cpu_start: Pro cpu up.
I (2230) cpu_start: Starting app cpu, entry point is 0x40081028
0x40081028: call_start_cpu1 at /Users/cyril/esp/esp-idf/components/esp32/cpu_start.c:228

I (1) cpu_start: App cpu up.
E (2263) memory_layout: SOC_RESERVE_MEMORY_REGION region range 0xfffffffc - 0x00000000 overlaps with 0xffffffff - 0xffffffff
abort() was called at PC 0x401157cb on core 0
0x401157cb: s_prepare_reserved_regions at /Users/cyril/esp/esp-idf/components/soc/src/memory_layout_utils.c:97
 (inlined by) soc_get_available_memory_regions at /Users/cyril/esp/esp-idf/components/soc/src/memory_layout_utils.c:114

Backtrace: 0x4008db47:0x3ffe3550 0x4008ddb9:0x3ffe3570 0x401157cb:0x3ffe3590 0x400d2b11:0x3ffe38e0 0x40081192:0x3ffe3c60 0x400790f5:0x3ffe3c80 0x400794c9:0x3ffe3cc0 0x400807e6:0x3ffe3df0 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20
0x4008db47: invoke_abort at /Users/cyril/esp/esp-idf/components/esp32/panic.c:660

0x4008ddb9: abort at /Users/cyril/esp/esp-idf/components/esp32/panic.c:660

0x401157cb: s_prepare_reserved_regions at /Users/cyril/esp/esp-idf/components/soc/src/memory_layout_utils.c:97
 (inlined by) soc_get_available_memory_regions at /Users/cyril/esp/esp-idf/components/soc/src/memory_layout_utils.c:114

0x400d2b11: heap_caps_init at /Users/cyril/esp/esp-idf/components/heap/heap_caps_init.c:65

0x40081192: call_start_cpu0 at /Users/cyril/esp/esp-idf/components/esp32/cpu_start.c:213

Looking at the code, I'm seeing this:
if (reserved[i].end > reserved[i+1].start) {
                ESP_EARLY_LOGE(TAG, "SOC_RESERVE_MEMORY_REGION region range " \
                               "0x%08x - 0x%08x overlaps with 0x%08x - 0x%08x",
                               reserved[i].start, reserved[i].end, reserved[i+1].start,
                               reserved[i+1].end);
                abort();
}

Since both reserved[i].end and start are int_ptr, the test above fails while end is 0 and (start is 0xFF.... thus negative).
The system does not boot.
Please notice that the application size fits the partition (partition is 900kB or so, while the app is 740kB), and make size returns:
Total sizes:
 DRAM .data size:   12716 bytes
 DRAM .bss  size:   94848 bytes
Used static DRAM:  107564 bytes (  17016 available, 86.3% used)
Used static IRAM:   64552 bytes (  66520 available, 49.2% used)
      Flash code:  534630 bytes
    Flash rodata:  131068 bytes
Total image size:~ 742966 bytes (.bin may be padded larger)

Expected Behavior
The application should start
Actual Behavior
It does not (the CPU 0 does not start)
Steps to repropduce
I've no idea why this appeared suddenly. I've reverted my changes, make clean and make, yet it's still there (while it worked perfectly before).
Other items if possible

sdkconfig.txt

Could you please set application log level to verbose (in menuconfig,
component config, log output), and attach the output you get?
On Sun, Oct 14, 2018, 17:30 X-Ryl669<EMAIL_ADDRESS>wrote:

Environment

Development Kit: [ESP32-Wrover-Kit]
Kit version (for WroverKit/PicoKit/DevKitC): [?]
Core (if using chip or module): []
IDF version (git rev-parse --short HEAD to get the commit id.):
9ca30f6
Development Env: [Make]
Operating System: [MacOS]
Power Supply: [USB]

Problem Description
Suddenly, my app does not boot anymore. I've reverted my changes and it
still does not boot up.
I get this output:
I (186) boot: ESP-IDF v3.2-dev-915-g6f58208 2nd stage bootloader
I (187) boot: compile time 07:12:15
I (187) boot: Enabling RNG early entropy source...
I (207) boot: SPI Speed      : 40MHz
I (220) boot: SPI Mode       : DIO
I (233) boot: SPI Flash Size : 4MB
I (246) boot: Partition Table:
I (257) boot: ## Label            Usage          Type ST Offset   Length
I (279) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (303) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (326) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (349) boot:  3 factory          factory app      00 00 00010000 000f0000
I (372) boot:  4 ota_0            OTA app          00 10 00100000 00100000
I (396) boot:  5 ota_1            OTA app          00 11 00200000 00100000
I (419) boot:  6 storage          Unknown data     01 82 00300000 00100000
I (443) boot: End of partition table
I (456) boot: Defaulting to factory image
I (470) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x1fffc (131068) map
I (773) esp_image: segment 1: paddr=0x00030024 vaddr=0x3ffbdb60 size=0x031ac ( 12716) load
I (803) esp_image: segment 2: paddr=0x000331d8 vaddr=0x3ffc0d0c size=0x00000 (     0) load
I (805) esp_image: segment 3: paddr=0x000331e0 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685
I (831) esp_image: segment 4: paddr=0x000335e8 vaddr=0x40080400 size=0x0ca28 ( 51752) load
I (981) esp_image: segment 5: paddr=0x00040018 vaddr=0x400d0018 size=0x82868 (534632) map
0x400d0018: _stext at ??:?
I (2103) esp_image: segment 6: paddr=0x000c2888 vaddr=0x4008ce28 size=0x02e00 ( 11776) load
0x4008ce28: vPortYield at /Users/cyril/esp/esp-idf/components/freertos/portasm.S:528
I (2133) esp_image: segment 7: paddr=0x000c5690 vaddr=0x400c0000 size=0x00000 (     0) load
I (2135) esp_image: segment 8: paddr=0x000c5698 vaddr=0x50000200 size=0x00000 (     0) load
I (2217) boot: Loaded app from partition at offset 0x10000
I (2217) boot: Disabling RNG early entropy source...
I (2221) cpu_start: Pro cpu up.
I (2230) cpu_start: Starting app cpu, entry point is 0x40081028
0x40081028: call_start_cpu1 at /Users/cyril/esp/esp-idf/components/esp32/cpu_start.c:228
I (1) cpu_start: App cpu up.
E (2263) memory_layout: SOC_RESERVE_MEMORY_REGION region range 0xfffffffc - 0x00000000 overlaps with 0xffffffff - 0xffffffff
abort() was called at PC 0x401157cb on core 0
0x401157cb: s_prepare_reserved_regions at /Users/cyril/esp/esp-idf/components/soc/src/memory_layout_utils.c:97
(inlined by) soc_get_available_memory_regions at /Users/cyril/esp/esp-idf/components/soc/src/memory_layout_utils.c:114
Backtrace: 0x4008db47:0x3ffe3550 0x4008ddb9:0x3ffe3570 0x401157cb:0x3ffe3590 0x400d2b11:0x3ffe38e0 0x40081192:0x3ffe3c60 0x400790f5:0x3ffe3c80 0x400794c9:0x3ffe3cc0 0x400807e6:0x3ffe3df0 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20
0x4008db47: invoke_abort at /Users/cyril/esp/esp-idf/components/esp32/panic.c:660
0x4008ddb9: abort at /Users/cyril/esp/esp-idf/components/esp32/panic.c:660
0x401157cb: s_prepare_reserved_regions at /Users/cyril/esp/esp-idf/components/soc/src/memory_layout_utils.c:97
(inlined by) soc_get_available_memory_regions at /Users/cyril/esp/esp-idf/components/soc/src/memory_layout_utils.c:114
0x400d2b11: heap_caps_init at /Users/cyril/esp/esp-idf/components/heap/heap_caps_init.c:65
0x40081192: call_start_cpu0 at /Users/cyril/esp/esp-idf/components/esp32/cpu_start.c:213
Looking at the code, I'm seeing this:
if (reserved[i].end > reserved[i+1].start) {
ESP_EARLY_LOGE(TAG, "SOC_RESERVE_MEMORY_REGION region range "
"0x%08x - 0x%08x overlaps with 0x%08x - 0x%08x",
reserved[i].start, reserved[i].end, reserved[i+1].start,
reserved[i+1].end);
abort();
}
Since both reserved[i].end and start are int_ptr, the test above fails
while end is 0 and (start is 0xFF.... thus negative).
The system does not boot.
Please notice that the application size fits the partition (partition is
900kB or so, while the app is 740kB), and make size returns:
Total sizes:
DRAM .data size:   12716 bytes
DRAM .bss  size:   94848 bytes
Used static DRAM:  107564 bytes (  17016 available, 86.3% used)
Used static IRAM:   64552 bytes (  66520 available, 49.2% used)
Flash code:  534630 bytes
Flash rodata:  131068 bytes
Total image size:~ 742966 bytes (.bin may be padded larger)
Expected Behavior
The application should start
Actual Behavior
It does not (the CPU 0 does not start)
Steps to repropduce
I've no idea why this appeared suddenly. I've reverted my changes, make
clean and make, yet it's still there (while it worked perfectly before).
Other items if possible

sdkconfig.txt
https://github.com/espressif/esp-idf/files/2476270/sdkconfig.txt

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/espressif/esp-idf/issues/2561, or mute the thread
https://github.com/notifications/unsubscribe-auth/AEJcesAtposWvveLFntkAD6b1Y-OaSUqks5ukxIzgaJpZM4XbD85
.

Very strange... With log set to verbose, the application boots
Anyway, here are the logs:
I (187) boot: ESP-IDF v3.2-dev-915-g6f58208 2nd stage bootloader
I (187) boot: compile time 07:12:15
I (188) boot: Enabling RNG early entropy source...
I (208) boot: SPI Speed      : 40MHz
I (221) boot: SPI Mode       : DIO
I (233) boot: SPI Flash Size : 4MB
I (247) boot: Partition Table:
I (257) boot: ## Label            Usage          Type ST Offset   Length
I (280) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (303) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (327) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (350) boot:  3 factory          factory app      00 00 00010000 000f0000
I (373) boot:  4 ota_0            OTA app          00 10 00100000 00100000
I (396) boot:  5 ota_1            OTA app          00 11 00200000 00100000
I (419) boot:  6 storage          Unknown data     01 82 00300000 00100000
I (443) boot: End of partition table
I (456) boot: Defaulting to factory image
I (470) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x25424 (152612) map
I (819) esp_image: segment 1: paddr=0x0003544c vaddr=0x3ffbdb60 size=0x031ac ( 12716) load
I (849) esp_image: segment 2: paddr=0x00038600 vaddr=0x3ffc0d0c size=0x00000 (     0) load
I (851) esp_image: segment 3: paddr=0x00038608 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

I (876) esp_image: segment 4: paddr=0x00038a10 vaddr=0x40080400 size=0x07600 ( 30208) load
I (975) esp_image: segment 5: paddr=0x00040018 vaddr=0x400d0018 size=0x85b38 (547640) map
0x400d0018: _stext at ??:?

I (2123) esp_image: segment 6: paddr=0x000c5b58 vaddr=0x40087a00 size=0x0824c ( 33356) load
0x40087a00: rcUpdateTxDoneAmpdu2 at ??:?

I (2206) esp_image: segment 7: paddr=0x000cddac vaddr=0x400c0000 size=0x00000 (     0) load
I (2208) esp_image: segment 8: paddr=0x000cddb4 vaddr=0x50000200 size=0x00000 (     0) load
I (2286) boot: Loaded app from partition at offset 0x10000
I (2286) boot: Disabling RNG early entropy source...
I (2290) cpu_start: Pro cpu up.
I (2299) cpu_start: Starting app cpu, entry point is 0x40081030
0x40081030: call_start_cpu1 at /Users/cyril/esp/esp-idf/components/esp32/cpu_start.c:228

I (1) cpu_start: App cpu up.
V (2331) memory_layout: reserved range is 0x3f42541c - 0x3f425444
D (2349) memory_layout: Checking 7 reserved memory ranges:
D (2366) memory_layout: Reserved memory range 0x3ffae000 - 0x3ffae6e0
D (2387) memory_layout: Reserved memory range 0x3ffbdb60 - 0x3ffd7fc8
D (2407) memory_layout: Reserved memory range 0x3ffe0000 - 0x3ffe0440
D (2427) memory_layout: Reserved memory range 0x3ffe4000 - 0x3ffe4350
D (2447) memory_layout: Reserved memory range 0x40070000 - 0x40078000
D (2467) memory_layout: Reserved memory range 0x40078000 - 0x40080000
0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

D (2487) memory_layout: Reserved memory range 0x40080000 - 0x4008fc4c
0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

D (2507) memory_layout: Building list of available memory regions:
V (2526) memory_layout: Examining memory region 0x3ffae000 - 0x3ffb0000
V (2547) memory_layout: Start of region 0x3ffae000 - 0x3ffb0000 overlaps reserved 0x3ffae000 - 0x3ffae6e0
D (2576) memory_layout: Available memory region 0x3ffae6e0 - 0x3ffb0000
V (2597) memory_layout: Examining memory region 0x3ffb0000 - 0x3ffb8000
D (2617) memory_layout: Available memory region 0x3ffb0000 - 0x3ffb8000
V (2638) memory_layout: Examining memory region 0x3ffb8000 - 0x3ffc0000
V (2658) memory_layout: End of region 0x3ffb8000 - 0x3ffc0000 overlaps reserved 0x3ffbdb60 - 0x3ffd7fc8
D (2687) memory_layout: Available memory region 0x3ffb8000 - 0x3ffbdb60
V (2708) memory_layout: Examining memory region 0x3ffc0000 - 0x3ffc2000
V (2729) memory_layout: Region 0x3ffc0000 - 0x3ffc2000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (2756) memory_layout: Examining memory region 0x3ffc2000 - 0x3ffc4000
V (2777) memory_layout: Region 0x3ffc2000 - 0x3ffc4000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (2804) memory_layout: Examining memory region 0x3ffc4000 - 0x3ffc6000
V (2825) memory_layout: Region 0x3ffc4000 - 0x3ffc6000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (2852) memory_layout: Examining memory region 0x3ffc6000 - 0x3ffc8000
V (2873) memory_layout: Region 0x3ffc6000 - 0x3ffc8000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (2900) memory_layout: Examining memory region 0x3ffc8000 - 0x3ffca000
V (2921) memory_layout: Region 0x3ffc8000 - 0x3ffca000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (2948) memory_layout: Examining memory region 0x3ffca000 - 0x3ffcc000
V (2969) memory_layout: Region 0x3ffca000 - 0x3ffcc000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (2996) memory_layout: Examining memory region 0x3ffcc000 - 0x3ffce000
V (3017) memory_layout: Region 0x3ffcc000 - 0x3ffce000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (3045) memory_layout: Examining memory region 0x3ffce000 - 0x3ffd0000
V (3065) memory_layout: Region 0x3ffce000 - 0x3ffd0000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (3093) memory_layout: Examining memory region 0x3ffd0000 - 0x3ffd2000
V (3113) memory_layout: Region 0x3ffd0000 - 0x3ffd2000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (3141) memory_layout: Examining memory region 0x3ffd2000 - 0x3ffd4000
V (3161) memory_layout: Region 0x3ffd2000 - 0x3ffd4000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (3189) memory_layout: Examining memory region 0x3ffd4000 - 0x3ffd6000
V (3209) memory_layout: Region 0x3ffd4000 - 0x3ffd6000 inside of reserved 0x3ffbdb60 - 0x3ffd7fc8
V (3237) memory_layout: Examining memory region 0x3ffd6000 - 0x3ffd8000
V (3257) memory_layout: Start of region 0x3ffd6000 - 0x3ffd8000 overlaps reserved 0x3ffbdb60 - 0x3ffd7fc8
D (3287) memory_layout: Available memory region 0x3ffd7fc8 - 0x3ffd8000
V (3308) memory_layout: Examining memory region 0x3ffd8000 - 0x3ffda000
D (3328) memory_layout: Available memory region 0x3ffd8000 - 0x3ffda000
V (3349) memory_layout: Examining memory region 0x3ffda000 - 0x3ffdc000
D (3369) memory_layout: Available memory region 0x3ffda000 - 0x3ffdc000
V (3390) memory_layout: Examining memory region 0x3ffdc000 - 0x3ffde000
D (3410) memory_layout: Available memory region 0x3ffdc000 - 0x3ffde000
V (3431) memory_layout: Examining memory region 0x3ffde000 - 0x3ffe0000
D (3452) memory_layout: Available memory region 0x3ffde000 - 0x3ffe0000
V (3472) memory_layout: Examining memory region 0x3ffe0000 - 0x3ffe4000
V (3493) memory_layout: Start of region 0x3ffe0000 - 0x3ffe4000 overlaps reserved 0x3ffe0000 - 0x3ffe0440
D (3522) memory_layout: Available memory region 0x3ffe0440 - 0x3ffe4000
V (3543) memory_layout: Examining memory region 0x3ffe4000 - 0x3ffe8000
V (3563) memory_layout: Start of region 0x3ffe4000 - 0x3ffe8000 overlaps reserved 0x3ffe4000 - 0x3ffe4350
D (3593) memory_layout: Available memory region 0x3ffe4350 - 0x3ffe8000
V (3614) memory_layout: Examining memory region 0x3ffe8000 - 0x3fff0000
D (3634) memory_layout: Available memory region 0x3ffe8000 - 0x3fff0000
V (3655) memory_layout: Examining memory region 0x3fff0000 - 0x3fff8000
D (3675) memory_layout: Available memory region 0x3fff0000 - 0x3fff8000
V (3696) memory_layout: Examining memory region 0x3fff8000 - 0x3fffc000
D (3716) memory_layout: Available memory region 0x3fff8000 - 0x3fffc000
V (3737) memory_layout: Examining memory region 0x3fffc000 - 0x40000000
D (3758) memory_layout: Available memory region 0x3fffc000 - 0x40000000
V (3778) memory_layout: Examining memory region 0x40070000 - 0x40078000
V (3799) memory_layout: Region 0x40070000 - 0x40078000 inside of reserved 0x40070000 - 0x40078000
V (3826) memory_layout: Examining memory region 0x40078000 - 0x40080000
0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

V (3847) memory_layout: Region 0x40078000 - 0x40080000 inside of reserved 0x40078000 - 0x40080000
0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

V (3874) memory_layout: Examining memory region 0x40080000 - 0x40082000
0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

0x40082000: esp_cpu_unstall at /Users/cyril/esp/esp-idf/components/soc/esp32/cpu_util.c:43

V (3895) memory_layout: Region 0x40080000 - 0x40082000 inside of reserved 0x40080000 - 0x4008fc4c
0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

0x40082000: esp_cpu_unstall at /Users/cyril/esp/esp-idf/components/soc/esp32/cpu_util.c:43

0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

V (3922) memory_layout: Examining memory region 0x40082000 - 0x40084000
0x40082000: esp_cpu_unstall at /Users/cyril/esp/esp-idf/components/soc/esp32/cpu_util.c:43

0x40084000: esp_reset_reason_get_hint at ??:?

V (3943) memory_layout: Region 0x40082000 - 0x40084000 inside of reserved 0x40080000 - 0x4008fc4c
0x40082000: esp_cpu_unstall at /Users/cyril/esp/esp-idf/components/soc/esp32/cpu_util.c:43

0x40084000: esp_reset_reason_get_hint at ??:?

0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

V (3970) memory_layout: Examining memory region 0x40084000 - 0x40086000
0x40084000: esp_reset_reason_get_hint at ??:?

0x40086000: ppCalTxAMPDULength at ??:?

V (3991) memory_layout: Region 0x40084000 - 0x40086000 inside of reserved 0x40080000 - 0x4008fc4c
0x40084000: esp_reset_reason_get_hint at ??:?

0x40086000: ppCalTxAMPDULength at ??:?

0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

V (4019) memory_layout: Examining memory region 0x40086000 - 0x40088000
0x40086000: ppCalTxAMPDULength at ??:?

0x40088000: wDev_ProcessTxop at ??:?

V (4039) memory_layout: Region 0x40086000 - 0x40088000 inside of reserved 0x40080000 - 0x4008fc4c
0x40086000: ppCalTxAMPDULength at ??:?

0x40088000: wDev_ProcessTxop at ??:?

0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

V (4067) memory_layout: Examining memory region 0x40088000 - 0x4008a000
0x40088000: wDev_ProcessTxop at ??:?

0x4008a000: set_chan_dig_gain at /home/cff/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7_cal.c:2458 (discriminator 1)

V (4087) memory_layout: Region 0x40088000 - 0x4008a000 inside of reserved 0x40080000 - 0x4008fc4c
0x40088000: wDev_ProcessTxop at ??:?

0x4008a000: set_chan_dig_gain at /home/cff/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7_cal.c:2458 (discriminator 1)

0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

V (4115) memory_layout: Examining memory region 0x4008a000 - 0x4008c000
0x4008a000: set_chan_dig_gain at /home/cff/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7_cal.c:2458 (discriminator 1)

0x4008c000: prvCheckTasksWaitingTermination at /Users/cyril/esp/esp-idf/components/freertos/tasks.c:3567
 (inlined by) prvIdleTask at /Users/cyril/esp/esp-idf/components/freertos/tasks.c:3391

V (4135) memory_layout: Region 0x4008a000 - 0x4008c000 inside of reserved 0x40080000 - 0x4008fc4c
0x4008a000: set_chan_dig_gain at /home/cff/gittree/chip7.1_phy/chip_7.1/board_code/app_test/pp/phy/phy_chip_v7_cal.c:2458 (discriminator 1)

0x4008c000: prvCheckTasksWaitingTermination at /Users/cyril/esp/esp-idf/components/freertos/tasks.c:3567
 (inlined by) prvIdleTask at /Users/cyril/esp/esp-idf/components/freertos/tasks.c:3391

0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

V (4163) memory_layout: Examining memory region 0x4008c000 - 0x4008e000
0x4008c000: prvCheckTasksWaitingTermination at /Users/cyril/esp/esp-idf/components/freertos/tasks.c:3567
 (inlined by) prvIdleTask at /Users/cyril/esp/esp-idf/components/freertos/tasks.c:3391

0x4008e000: setFirstBreakpoint at /Users/cyril/esp/esp-idf/components/esp32/panic.c:202

V (4183) memory_layout: Region 0x4008c000 - 0x4008e000 inside of reserved 0x40080000 - 0x4008fc4c
0x4008c000: prvCheckTasksWaitingTermination at /Users/cyril/esp/esp-idf/components/freertos/tasks.c:3567
 (inlined by) prvIdleTask at /Users/cyril/esp/esp-idf/components/freertos/tasks.c:3391

0x4008e000: setFirstBreakpoint at /Users/cyril/esp/esp-idf/components/esp32/panic.c:202

0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

V (4211) memory_layout: Examining memory region 0x4008e000 - 0x40090000
0x4008e000: setFirstBreakpoint at /Users/cyril/esp/esp-idf/components/esp32/panic.c:202

V (4231) memory_layout: Start of region 0x4008e000 - 0x40090000 overlaps reserved 0x40080000 - 0x4008fc4c
0x4008e000: setFirstBreakpoint at /Users/cyril/esp/esp-idf/components/esp32/panic.c:202

0x40080000: _WindowOverflow4 at /Users/cyril/esp/esp-idf/components/freertos/xtensa_vectors.S:1685

D (4261) memory_layout: Available memory region 0x4008fc4c - 0x40090000
V (4282) memory_layout: Examining memory region 0x40090000 - 0x40092000
D (4302) memory_layout: Available memory region 0x40090000 - 0x40092000
V (4323) memory_layout: Examining memory region 0x40092000 - 0x40094000
D (4343) memory_layout: Available memory region 0x40092000 - 0x40094000
V (4364) memory_layout: Examining memory region 0x40094000 - 0x40096000
D (4384) memory_layout: Available memory region 0x40094000 - 0x40096000
V (4405) memory_layout: Examining memory region 0x40096000 - 0x40098000
D (4426) memory_layout: Available memory region 0x40096000 - 0x40098000
V (4446) memory_layout: Examining memory region 0x40098000 - 0x4009a000
D (4467) memory_layout: Available memory region 0x40098000 - 0x4009a000
V (4487) memory_layout: Examining memory region 0x4009a000 - 0x4009c000
D (4508) memory_layout: Available memory region 0x4009a000 - 0x4009c000
V (4528) memory_layout: Examining memory region 0x4009c000 - 0x4009e000
D (4549) memory_layout: Available memory region 0x4009c000 - 0x4009e000
V (4569) memory_layout: Examining memory region 0x4009e000 - 0x400a0000
D (4590) memory_layout: Available memory region 0x4009e000 - 0x400a0000
I (4611) heap_init: Initializing. RAM available for dynamic allocation:
D (4633) heap_init: New heap initialised at 0x3ffae6e0
I (4649) heap_init: At 3FFAE6E0 len 0000F480 (61 KiB): DRAM
D (4668) heap_init: New heap initialised at 0x3ffd7fc8
I (4684) heap_init: At 3FFD7FC8 len 00008038 (32 KiB): DRAM
I (4704) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (4723) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
D (4743) heap_init: New heap initialised at 0x4008fc4c
I (4759) heap_init: At 4008FC4C len 000103B4 (64 KiB): IRAM
I (4779) cpu_start: Pro cpu start user code
D (4814) clk: RTC_SLOW_CLK calibration value: 3242880
V (232) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (232) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xE
D (237) intr_alloc: Connected src 46 to int 2 (cpu 0)
V (243) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (249) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xC0E
D (257) intr_alloc: Connected src 57 to int 3 (cpu 0)
V (262) esp_dbg_stubs: esp_dbg_stubs_init stubs 3ffc1534
D (267) stack_chk: Intialize random stack guard
V (272) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (278) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0x40E
D (286) intr_alloc: Connected src 24 to int 9 (cpu 0)
I (291) cpu_start: Starting scheduler on PRO CPU.
V (0) intr_alloc: esp_intr_alloc_intrstatus (cpu 1): checking args
V (0) intr_alloc: esp_intr_alloc_intrstatus (cpu 1): Args okay. Resulting flags 0x40E
D (10) intr_alloc: Connected src 25 to int 2 (cpu 1)
I (10) cpu_start: Starting scheduler on APP CPU.
D (341) heap_init: New heap initialised at 0x3ffe0440
D (341) heap_init: New heap initialised at 0x3ffe4350
V (351) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (351) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xE
D (351) intr_alloc: Connected src 16 to int 12 (cpu 0)
I (371) gpio: GPIO[2]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
D (381) nvs: nvs_flash_init_custom partition=nvs start=9 count=4
D (421) nvs: nvs_open_from_partition nvse 1
Opened NVS correctly 0x1
D (421) nvs: nvs_open_from_partition misc 1
D (421) nvs: nvs_get_str_or_blob log
I (421) wifi: wifi driver task: 3ffb7150, prio:23, stack:3072, core=0
I (431) wifi: wifi firmware version: ece97c4
I (431) wifi: config NVS flash: enabled
I (441) wifi: config nano formating: enabled
I (441) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (451) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
D (461) nvs: nvs_open_from_partition nvs.net80211 1
D (461) nvs: nvs_get opmode 1
D (471) nvs: nvs_get_str_or_blob sta.ssid
D (471) nvs: nvs_get_str_or_blob sta.mac
D (481) nvs: nvs_get sta.authmode 1
D (481) nvs: nvs_get_str_or_blob sta.pswd
D (481) nvs: nvs_get_str_or_blob sta.pmk
D (491) nvs: nvs_get sta.chan 1
D (491) nvs: nvs_get auto.conn 1
D (491) nvs: nvs_get bssid.set 1
D (501) nvs: nvs_get_str_or_blob sta.bssid
D (501) nvs: nvs_get sta.lis_intval 2
D (511) nvs: nvs_get sta.phym 1
D (511) nvs: nvs_get sta.phybw 1
D (511) nvs: nvs_get_str_or_blob sta.apsw
D (521) nvs: nvs_get_str_or_blob sta.apinfo
D (521) nvs: nvs_get sta.scan_method 1
D (521) nvs: nvs_get sta.sort_method 1
D (531) nvs: nvs_get sta.minrssi 1
D (531) nvs: nvs_get sta.minauth 1
D (531) nvs: nvs_get_str_or_blob ap.ssid
D (541) nvs: nvs_get_str_or_blob ap.mac
D (541) nvs: nvs_get_str_or_blob ap.passwd
D (551) nvs: nvs_get_str_or_blob ap.pmk
D (551) nvs: nvs_get ap.chan 1
D (551) nvs: nvs_get ap.authmode 1
D (561) nvs: nvs_get ap.hidden 1
D (561) nvs: nvs_get ap.max.conn 1
D (561) nvs: nvs_get bcn.interval 2
D (571) nvs: nvs_get ap.phym 1
D (571) nvs: nvs_get ap.phybw 1
D (571) nvs: nvs_get ap.sndchan 1
D (581) nvs: nvs_get lorate 1
D (581) nvs: nvs_set_blob sta.mac 6
D (591) nvs: nvs_set_blob ap.mac 6
I (591) wifi: Init dynamic tx buffer num: 32
I (591) wifi: Init data frame dynamic rx buffer num: 32
I (601) wifi: Init management frame dynamic rx buffer num: 32
I (601) wifi: Init static rx buffer size: 1600
I (611) wifi: Init static rx buffer num: 10
I (611) wifi: Init dynamic rx buffer num: 32
WIFI started!
I (621) gpio: GPIO[22]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
D (621) nvs: nvs_get_str_or_blob bssid
D (631) nvs: nvs_get asStation 4
D (631) RTC_MODULE: Wi-Fi takes adc2 lock.
D (641) phy_init: loading PHY init data from application binary
D (641) nvs: nvs_open_from_partition phy 0
D (651) nvs: nvs_get cal_version 4
V (651) phy_init: phy_get_rf_cal_version: 3960

D (651) nvs: nvs_get_str_or_blob cal_mac
D (661) nvs: nvs_get_str_or_blob cal_data
D (671) nvs: nvs_close 4
I (721) phy: phy_version: 3960, 5211945, Jul 18 2018, 10:40:07, 0, 0
I (721) wifi: mode : sta (30:ae:a4:13:7e:e4) + softAP (30:ae:a4:13:7e:e5)
D (721) event: SYSTEM_EVENT_STA_START
V (721) event: enter default callback
V (731) tcpip_adapter: check: local, if=0 fn=0x4011dc1c
0x4011dc1c: tcpip_adapter_start_api at /Users/cyril/esp/esp-idf/components/tcpip_adapter/tcpip_adapter_lwip.c:1082

Started AP with name NVSE

Reset the log to info works too. I'm not sure what happens.

0xfffffffc - 0x00000000 overlaps with 0xffffffff - 0xffffffff

Given the number of 0xffs in here (the first two values are aligned to previous & next 4 byte boundaries, so it's likely the initial values of all 4 numbers were 0xffffffff), I think maybe you got a bad flash or a bad .bin file somehow? (0xff is the value of unwritten flash).
The values printed here should all have been linked into a special region of flash via the SOC_RESERVE_MEMORY_REGION() macro, and the addresses passed to that macro are always hard-coded to memory addresses in the 0x3ffff* and 0x400* ranges.
Any chance that openocd was running when the errors occurred? If the JTAG debug port is active then verification of the app integrity on boot is skipped, to allow for software breakpoints to be inserted to flash.

For bad flash, I don't think so. I've tried to erase the flash and reflash it and it did not report any error.
About corrupted .bin, I've run a make clean; make twice. It's probably corrupted, but I can't figure out why. Notice that changing the sdkconfig did solve the issue, so you're probably right, but this means that some corrupted binary wasn't correctly cleaned and reused in the final bin, but the dependency on the sdkconfig was working correctly.
I'm not using OpenOCD (does not work great on a mac, at least last time I've checked). Only serial via USB was connected.
Since I don't understand much of this code area, I was wondering how I could understand better. Would a nm or objdump have helped show the (corrupted) sections address ?
Is it possible the linker script is the culprit (I haven't modified it BTW) ?
Is it dynamically generated ?
Also, the change that introduced the issue was the first usage of new in my code (everything before was using static allocation/bss and malloc when not possible).

Hi @X-Ryl669,
Thanks for the extra details. In this case, I don't have any explanation for the behaviour.
The build system is tested in our CI system for correct behaviour around things like clean builds, so I don't expect it would fail to recompile sources, and especially to regenerate the .elf and .bin files after a make clean.
Parts of the linker script are dynamically generated based on config, but the part involved in SOC_RESERVE_MEMORY_REGION is not.
If the problem has become unreproducible then I'm not sure there's anything more we can do to investigate this for now.
If the problem re-occurs, please reopen the issue. If it's possible at that point to zip up the entire build directory (including the .bin and .elf files and all other intermediate files) and send it to us privately, this may help pin down the root cause.

Ok, I'll let you know. Thanks!

We have the exact same problem within our product low.js for ESP32, with the exact same values:
I (524) cpu_start: Starting app cpu, entry point is 0x4008116c
0x4008116c: call_start_cpu1 at /Users/thomas/Documents/Beruflich/neonious/Development/neonious_one/esp-idf/components/esp32/cpu_start.c:252

I (516) cpu_start: App cpu up.
E (535) memory_layout: SOC_RESERVE_MEMORY_REGION region range 0xfffffffc - 0x00000000 overlaps with 0xffffffff - 0xffffffff
<restarts here>

The last commit we merged was 7efbe81 from Oct 29
For some reason some of the regions in the image are saved as 0xffffffff-0xffffffff. Seems like a linker or compiler bug. Most probably a linker bug, because it happens depending on how many string literals we have. Adding just one ESP_LOGE(TAG, "bla") => it works again.
Our work around:
    reserved[0].end = (intptr_t)&_bss_end;
    reserved[1].start = (intptr_t)&_iram_start; /* IRAM used by code */
    reserved[1].end = (intptr_t)&_iram_end;

+    // Hacking them inside here because of bug https://github.com/espressif/esp-idf/issues/2561
+    // Copied from soc_memory_layout
+    if(count != 8)
+    {
+        ESP_EARLY_LOGE(TAG, "not 8 mem regions!");
+        abort();
+    }
+    reserved[2].start = 0x40070000;
+    reserved[2].end = 0x40078000;
+    reserved[3].start = 0x40078000;
+    reserved[3].end = 0x40080000;
+    reserved[4].start = 0x3ffe0000;
+    reserved[4].end = 0x3ffe0440;
+    reserved[5].start = 0x3ffe4000;
+    reserved[5].end = 0x3ffe4350;
+    reserved[6].start = 0x3ffae000;
+    reserved[6].end = 0x3ffae6e0;
+    reserved[7].start = 0x3f800000;
+    reserved[7].end = 0x3fC00000;

    /* Sort by starting address */
    qsort(reserved, count, sizeof(soc_reserved_region_t), s_compare_reserved_regions);

    /* Validity checks */

Please reopen the issue.
Thomas

Hi @neoniousTR ,
Thanks for letting us know that you're seeing this again. If you can reliably reproduce this, are you able to please provide the .elf, .map & .bin files for a bad build (and - if it's not too much trouble - a "good" build without the workaround - as well.)
You can email to me - angus at espressif.com - if that's convenient.
Does low.js project make any linker script changes, or is it all the default ESP-IDF linker setup?

Sorry, I cannot give more than hints, as we do not have the capacity to debug further.
What I can say:

It is the vanilla linker script, no changes
The amount of reserved regions is correct (8)
Data is just binary ones

The object files will be OK, because they do not have to be recompiled to get this working again. It is enough to just add additional string literals.
BTW: We are also using Mac OS. So it could be an issue which only happens on Macs.

I think I have found the same problem using Arduino ESP32 1.0.1
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:10088
load:0x40080400,len:6380
entry 0x400806a4
Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x401552f5  PS      : 0x00060930  A0      : 0x801b30ee  A1      : 0x3ffe3470
A2      : 0x3f41954c  A3      : 0x00000059  A4      : 0x3f419680  A5      : 0x3f419528
A6      : 0x3ffe3530  A7      : 0x3ffe3520  A8      : 0x801552f5  A9      : 0x3ffe3450
A10     : 0x00000000  A11     : 0x3ffe3528  A12     : 0x00000000  A13     : 0x00000001
A14     : 0x3ffe34f0  A15     : 0x3ffe34f0  SAR     : 0x00000010  EXCCAUSE: 0x0000001c
EXCVADDR: 0x0000000c  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0x00000000
Backtrace: 0x401552f5:0x3ffe3470 0x401b30eb:0x3ffe34a0 0x401b31a5:0x3ffe34d0 0x40173ea5:0x3ffe3840 0x40083621:0x3ffe3c20 0x40078fb3:0x3ffe3c40 0x40079019:0x3ffe3c70 0x40079024:0x3ffe3ca0 0x400791c3:0x3ffe3cc0 0x400806d6:0x3ffe3df0 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20
Decoding stack results
0x401552f5: __assert_func at ../../../.././newlib/libc/stdlib/assert.c line 59
0x401b30eb: s_prepare_reserved_regions at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/soc/src/memory_layout_utils.c line 89
0x401b31a5: soc_get_available_memory_regions at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/soc/src/memory_layout_utils.c line 114
0x40173ea5: heap_caps_init at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/heap/heap_caps_init.c line 65
0x40083621: call_start_cpu0 at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/esp32/cpu_start.c line 250
If I compile using Core Debug Level Info or Verbose the Sketch run,
I also try to comment some Serial.print and the problem disappear.
Which files I have to change to solve this problem on Arduino
Thank You
Best regards
Marco

I'm seeing a very similar issue to this when bringing an application up to the current master (6fe853a2c).
Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:8752
ho 0 tail 12 room 4
load:0x40078000,len:11904
load:0x40080400,len:7064
entry 0x400807a4
D (75) bootloader_flash: mmu set block paddr=0x00000000 (was 0xffffffff)
I (37) boot: ESP-IDF v4.0-dev-1381-g6fe853a2c 2nd stage bootloader
I (37) boot: compile time 20:14:21
D (37) boot: Enabling RTCWDT(9000 ms)
I (42) boot: Enabling RNG early entropy source...
D (48) boot: magic e9
D (50) boot: segments 04
D (52) boot: spi_mode 02
D (55) boot: spi_speed 00
D (58) boot: spi_size 02
I (60) boot: SPI Speed      : 40MHz
I (65) boot: SPI Mode       : DIO
I (69) boot: SPI Flash Size : 4MB
D (73) bootloader_flash: mmu set paddr=00000000 count=1 size=c00 src_addr=8000 src_addr_aligned=0
D (81) boot: mapped partition table 0x8000 at 0x3f408000
D (87) flash_parts: partition table verified, 3 entries
I (92) boot: Partition Table:
I (96) boot: ## Label            Usage          Type ST Offset   Length
D (103) boot: load partition table entry 0x3f408000
D (108) boot: type=1 subtype=2
I (111) boot:  0 nvs              WiFi data        01 02 00009000 00006000
D (119) boot: load partition table entry 0x3f408020
D (124) boot: type=1 subtype=1
I (127) boot:  1 phy_init         RF data          01 01 0000f000 00001000
D (134) boot: load partition table entry 0x3f408040
D (139) boot: type=0 subtype=0
I (142) boot:  2 factory          factory app      00 00 00010000 00100000
I (150) boot: End of partition table
D (154) boot: Trying partition index -1 offs 0x10000 size 0x100000
D (160) esp_image: reading image header @ 0x10000
D (165) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)
D (172) esp_image: image header: 0xe9 0x06 0x02 0x02 40081048
I (178) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x09520 ( 38176) map
D (187) esp_image: free data page_count 0x00000032
D (192) bootloader_flash: mmu set paddr=00010000 count=1 size=9520 src_addr=10020 src_addr_aligned=10000
D (215) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)
I (215) esp_image: segment 1: paddr=0x00019548 vaddr=0x3ffb0000 size=0x02208 (  8712) load
D (220) esp_image: free data page_count 0x00000032
D (224) bootloader_flash: mmu set paddr=00010000 count=1 size=2208 src_addr=19548 src_addr_aligned=10000
D (238) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)
I (241) esp_image: segment 2: paddr=0x0001b758 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _WindowOverflow4 at /home/morgan/devel/esp-idf/components/freertos/xtensa_vectors.S:1778

D (250) esp_image: free data page_count 0x00000032
D (255) bootloader_flash: mmu set paddr=00010000 count=1 size=400 src_addr=1b758 src_addr_aligned=10000
D (265) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)
I (271) esp_image: segment 3: paddr=0x0001bb60 vaddr=0x40080400 size=0x044b0 ( 17584) load
D (280) esp_image: free data page_count 0x00000032
D (285) bootloader_flash: mmu set paddr=00010000 count=2 size=44b0 src_addr=1bb60 src_addr_aligned=10000
D (302) bootloader_flash: mmu set block paddr=0x00020000 (was 0xffffffff)
I (302) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x15480 ( 87168) map
0x400d0018: _flash_cache_start at ??:?

D (310) esp_image: free data page_count 0x00000032
D (315) bootloader_flash: mmu set paddr=00020000 count=2 size=15480 src_addr=20018 src_addr_aligned=20000
D (356) bootloader_flash: mmu set block paddr=0x00030000 (was 0xffffffff)
I (356) esp_image: segment 5: paddr=0x000354a0 vaddr=0x400848b0 size=0x051f8 ( 20984) load
0x400848b0: multi_heap_free_impl at /home/morgan/devel/esp-idf/components/heap/multi_heap.c:501

D (360) esp_image: free data page_count 0x00000032
D (365) bootloader_flash: mmu set paddr=00030000 count=1 size=51f8 src_addr=354a0 src_addr_aligned=30000
D (384) bootloader_flash: mmu set block paddr=0x00030000 (was 0xffffffff)
D (384) esp_image: Calculated hash: f1b30a0d85240b22a6caa2088a0286c8e901b61a6d94fdbab4a6dc700d80558a
D (391) bootloader_flash: mmu set paddr=00030000 count=1 size=20 src_addr=3a6a0 src_addr_aligned=30000
D (400) bootloader_flash: mmu set paddr=00030000 count=1 size=20 src_addr=3a6a0 src_addr_aligned=30000
I (415) boot: Loaded app from partition at offset 0x10000
I (416) boot: Disabling RNG early entropy source...
D (421) boot: Mapping segment 0 as DROM
D (425) boot: Mapping segment 4 as IROM
D (429) boot: calling set_cache_and_start_app
D (433) boot: configure drom and irom and start
D (438) boot: start: 0x40081048
0x40081048: call_start_cpu0 at /home/morgan/devel/esp-idf/components/esp32/cpu_start.c:121

I (441) cpu_start: Pro cpu up.
I (445) cpu_start: Application information:
I (450) cpu_start: Project name:     cacoffiny
I (455) cpu_start: App version:      8a45a5f-dirty
I (460) cpu_start: Compile time:     Aug  4 2019 20:14:28
I (466) cpu_start: ELF file SHA256:  f29943c5cdf03d4e...
I (472) cpu_start: ESP-IDF:          v4.0-dev-1381-g6fe853a2c
I (479) cpu_start: Starting app cpu, entry point is 0x40080ffc
0x40080ffc: call_start_cpu1 at /home/morgan/devel/esp-idf/components/esp32/cpu_start.c:281

I (467) cpu_start: App cpu up.
V (489) memory_layout: reserved range is 0x3f4094f8 - 0x3f409540
D (495) memory_layout: Checking 11 reserved memory ranges:
D (501) memory_layout: Reserved memory range 0x3ffae000 - 0x3ffae6e0
D (507) memory_layout: Reserved memory range 0x3ffae6e0 - 0x3ffaff10
D (514) memory_layout: Reserved memory range 0x3ffb0000 - 0x3ffb3238
Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x400d659a  PS      : 0x00060b30  A0      : 0x800d5ad4  A1      : 0x3ffe3440
0x400d659a: __assert_func at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:59

A2      : 0x3f4078dc  A3      : 0x0000005b  A4      : 0x3f407bd8  A5      : 0x3f407920
A6      : 0x00000000  A7      : 0xffffffff  A8      : 0x800d659a  A9      : 0x3ffe3420
A10     : 0x00000000  A11     : 0x3ffe33e8  A12     : 0x3ffe338f  A13     : 0x00000038
A14     : 0x00000000  A15     : 0x3ffe3399  SAR     : 0x00000005  EXCCAUSE: 0x0000001c
EXCVADDR: 0x0000000c  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0x00000000

ELF file SHA256: f29943c5cdf03d4eaf59b5726bf6ae1f837e345d82b419d8849d545505e007fc

Backtrace: 0x400d6597:0x3ffe3440 0x400d5ad1:0x3ffe3470 0x400d5b75:0x3ffe34a0 0x400d2356:0x3ffe3820 0x4008121e:0x3ffe3bf0 0x4007930e:0x3ffe3c30 |<-CORRUPTED
0x400d6597: __assert_func at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:59

0x400d5ad1: s_prepare_reserved_regions at /home/morgan/devel/esp-idf/components/soc/src/memory_layout_utils.c:91 (discriminator 1)

0x400d5b75: soc_get_available_memory_regions at /home/morgan/devel/esp-idf/components/soc/src/memory_layout_utils.c:114

0x400d2356: heap_caps_init at /home/morgan/devel/esp-idf/components/heap/heap_caps_init.c:67

0x4008121e: call_start_cpu0 at /home/morgan/devel/esp-idf/components/esp32/cpu_start.c:266

Hi @igrr, it seems like the problem still exists on esp-idf v5.0.1. I just encountered it, with the following error message:
memory_layout: SOC_RESERVE_MEMORY_REGION region range 0x14440014 - 0x1d040014 overlaps with 0x1c040054 - 0x5c040054
Changing log level or adding random extra log solved the issue, but it is very confusing to me. Where does this come from?

@igrr I unfortunately added logs everywhere in my project and can't remember the configuration that failed (yes, I should have saved somewhere but I was too happy to find that adding log made it worked again 😨 )
Though, I randomly get this issue with the project I am working on, so I soon as I get the error, I'll send you the the files
Note that I use ESP32-S3 with 8MB of PSRAM enabled

I actually managed to reproduce it:

@igrr I sent you the .elf and .bin file on your email

@igrr I think this issue is because the psram vaddr overlaps with instruction address:
V (176) mmu: found laddr is 0x70000
V (177) esp_psram: 8bit-aligned-range: 0x800000 B, starting from: 0x3c070000
V (203) memory_layout: reserved range is 0x3c078a30 - 0x3c078a50

This can be reproduced when size of .flash.text is exactly 1~31 bytes under MMU_PAGE_SIZE boudary:
.flash.text     0x0000000042000020    0x4fff7
                0x0000000042000020                _instruction_reserved_start = ABSOLUTE (.)
                0x0000000042050017                _instruction_reserved_end = ABSOLUTE (.)
                0x000000003c060020                _rodata_reserved_start = .
                0x000000003c078a30                soc_reserved_memory_region_start = ABSOLUTE (.)
                0x000000003c078a50                soc_reserved_memory_region_end = ABSOLUTE (.)
                0x000000003c078a60                _rodata_reserved_end = ABSOLUTE (.)

I solved this with below patch (and similar works for all chips):
--- a/components/esp_system/ld/esp32s3/sections.ld.in
+++ b/components/esp_system/ld/esp32s3/sections.ld.in
@@ -261,6 +261,7 @@ SECTIONS
       * dummy bytes to ensure this
       */
     . += _esp_flash_mmap_prefetch_pad_size;
+    . += 0x20;

     _text_end = ABSOLUTE(.);
     _instruction_reserved_end = ABSOLUTE(.);  /* This is a symbol marking the flash.text end, this can be used for mmu driver to maintain virtual address */

@puyoulu  Thank you for your help. All you explained is a bit confusing to me, but a quick question : did I do something wrong in my configuration? I'd rather correct my code/project than modifying files I don't really understand...

@puyoulu Thank you for your help. All you explained is a bit confusing to me, but a quick question : did I do something wrong in my configuration? I'd rather correct my code/project than modifying files I don't really understand...

I don't think so. It is because the mmu management code does not calculate code size correctly.

Alright, then I will try your solution. Thank you!

I'm using idf v5.0.2, and I checked master branch, backporting commit 98892a3 should also fix this.
But seems there are other codes rely _instruction_reserved_start/_instruction_reserved_end to calculate irom size (eg. components/esp_system/port/cpu_start.c), and maybe this commit need also be applied there?

@puyoulu Thanks for helping pointing this out. The commit you mentioned does need to be backported to v5.0.x release. We will do this soon.
WRT this question:

But seems there are other codes rely _instruction_reserved_start/_instruction_reserved_end to calculate irom size (eg. components/esp_system/port/cpu_start.c), and maybe this commit need also be applied there?

May I know if you're referring to the calculations about this function?

Thanks for reporting, feel free to reopen.


Link to install XCode from the App Store has been added.

Please bundle doc changes into a single PR next time. Each test run cost us $10...


GEODE-2552: Remove NanoTimer

Please focus on commits e541e31 ... daf4234, others are artifacts of unpulled requests.

Would adding const to variables like spentWorking and sleepDuration help the compiler generate more efficient code?

I doubt the compilers would care since it will know the scope is limited to the block and there are no other assignment operations. It does however provide more readable and safe coding style. I could make adjustments.

@PivotalSarge

Why the switch to ACE_OS::localtime() from localtime()?

localtime AKA POSIX localtime is not thread safe. ACE_OS::localtime wraps the platform specific localtime_r or localtime_s functions that are thread safe. Ultimately we want to replace these something like boost::locale until something is adopted into the std.

@PivotalSarge

Nice fix of the broken window of catching exceptions by value.

If you enable clang-tidy you will see plenty of them. I am cleaning up lots of these bad things along the way.


Bug: Crash when select all and delete with only table in the editor

Copy-pasting/ Inserting a table into the editor and deleting it by selecting all crashes the editor.
Lexical version: v0.17.1
Steps To Reproduce

By copy/paste

Copy a table
Ctrl + A in the lexical editor
Paste
Ctrl + A
Press Del key

By Inserting

Insert table
Remove everything before and after the table node
Ctrl + A
Press Del

The current behavior
Can see crashes
The expected behavior
To not crash and delete the table

I've tried both ways, but I'm not able to reproduce those crashes, tried with both - the current playground and a few commits ago locally.

Interesting - I can consistently reproduce the crash in the playground. After you inserted the table, did you remove the nodes before the table node?

The repro instructions for case 2 don't work for me, but it does work if there is nothing before and an empty paragraph after.

Clear editor
Insert table
Press up to move cursor to paragraph before table
Press delete to remove paragraph before table
Press Ctrl-A to select all
Press delete to crash

Appears to be a crash in RangeSelection.getNodes in isBefore. Could possibly be related to #6568 but the root cause is that by the time the DELETE_CHARACTER_COMMAND runs the table is already not connected (not sure yet what code is doing this) but since the DOM for it still exists it ends up getting selected along the way.

$deleteCellHandler is removing the table before the code runs. I think the root cause of the bug is really that table.remove() doesn't properly update the selection so it's likely the best fix is in $removeNode (perhaps $maybeMoveChildrenSelectionToParent)?

After doing a deeper dive it seems that the problem is that the implementation of deleteCharacter ends up applying the DOM selection to the current selection (via applyDOMRange in modify) after the node is already removed and chaos ensues because it ends up creating a selection where the anchor is not attached to the root anymore. It's a weird thing to do because at the point you call applyDOMRange the DOM and its selection might have no overlap at all with the document since reconciliation hasn't happened yet. Not exactly clear what the best fix would be, maybe @zurfyx has some insight because he has worked on some of this code (e.g. #3279).
In an ideal world I don't think we would want to call applyDOMRange in this flow at all, at least with the character granularity?

This is the playground URL I was using to repro the issue:

localhost
playground

It doesn't preserve selection so you have to make the selection and then press delete but it makes setting it up a little quicker


introduce incremental builds

This introduces incremental builds, meaning only rebuilding images where the upstream repo has changed from what's in dist-git.

@adammhaile @tbielawa now that doozer release auto-increment works, this is running great over at https://buildvm.openshift.eng.bos.redhat.com:8443/job/Experimental/job/lmeyer/job/build%252Fscan-sources/  (last time it failed only because it was trying to build 4.0 signed... which i fixed)
So, ready for review.

@adammhaile you want to hold this open to look at it, or just wing it in there and try it out? It's net new so not much risk...

@sosiouxme PUSH IT :) Looks good


Add support for time field type

Example query results

Results
Add example SQL query results here (please include the input queries as well)

Steampipe SDK column type timestamp is not applicable for Salesforce time type.


Allow modification to default composer installed extensions

Move composer installed extensions to volumed in composer.local.json file.
Add support for specifying an alternative composer.local.json file at create/import time.
Optionally extends CanastaWiki/Canasta#270 and CanastaWiki/Canasta-DockerCompose#47
Should only be merged if the other two pull requests are merged first.

We've already discussed this patch a little elsewhere, but we should talk about it here. I know this flag is analogous to the existing "override" flag (which places a file at docker-compose.override.yml, just like this one places a file at composer.local.json), but the "override" command seems more useful than this one. There is no existing file at docker-compose.override.yml, which means that anyone who wants to do an override can indeed simply create a new file and put it there. On the other hand, composer.local.json already exists - and it's populated with all the Canasta-recommended stuff - so it seems less likely that someone will want to wipe out that file and put in their own file - much more likely, I would think, is that someone would want to keep the existing file but just want to add one or two lines, change a version number, etc. But I look forward to hearing other opinions.
(If this flag does get added, by the way, I think it would be better named "composerFile" than "composer", but that's a more minor issue. (Arguably the same is true for "override".))

I can think of two admittedly edge cases where one might want to provide the composer file.
You might want to create a wiki using an older version of one of the extensions that has an incompatible database schema. Since most extensions do not support downgrading a database schema, you would want to create the database with the earlier schema initially.
In the case of importing an existing wiki from an instance running an older version of the extensions, you might want to import with the existing versions followed by upgrading to the newer versions, rather than having these happen in a single step.
Neither of those cases are particularly strong, but I would ask why you would want to prevent them? One argument could be that you want to limit the number of command line options.

Okay, I think I understand these two cases you're describing.... but are they correct? That is, all the extensions and skins in the "Jeroen bundle" will get loaded by default, via Composer. But they will not be enabled by default, I don't think - which means that update.php will not apply to them, until a wfLoad...() call is added manually. Or am I missing something?
You do make a reasonable point that, regardless of the benefits, there's no harm in adding another flag. Yes, all things being equal, I do think it makes sense to keep the set of options smaller. Of course, if there's a good reason to add an option, it should be added.

Okay, I think I understand these two cases you're describing.... but are they correct? That is, all the extensions and skins in the "Jeroen bundle" will get loaded by default, via Composer. But they will not be enabled by default, I don't think - which means that update.php will not apply to them, until a wfLoad...() call is added manually. Or am I missing something?

In the case of import, it is possible that the LocalSettings.php file provided enables the extensions
You are absolutely correct in the case of creation of a new wiki. Since the extensions are not enabled, they will not affect the database schema in that case.
So, maybe this is only really helpful in the case of import, and we'd want to discourage running with out of date extensions for newly created wikis by not providing the option on create. The only exception to that is if you wanted to create an empty wiki and do the database import manually rather than letting CLI do it for you, maybe if the wiki is large? It is a tradeoff between hiding the complexity behind CLI commands and letting the user have more flexibility.

Okay, that makes sense. But that same problem (unwanted automatic updating of DB tables when importing a wiki) holds for all the non-Composer extensions also, no? Hopefully there's a way to get around it for those, like commenting out all the wfLoadExtension() calls first - if so, I don't see a need to have a 2nd option for just the Composer extensions. (Though you could argue that SMW is a special case, due to its importance.)

Maybe I'm mistaken, but I had thought that putting different versions of the non-composer extensions in the volumed in extensions directory prior to running import would result in them being used rather than the built-in versions. Wouldn't they be symbolically linked from extensions to user-extensions rather than the ones in canasta-extensions?

Oh yes, that's true... there is a second way, for the non-Composer extensions, to defer a DB upgrade: install the previous version of the extension in the user-extensions/ directory, and keep it there until you want to do the upgrade. I hadn't thought about that.
But is this even a reasonable approach, for either group of extensions? There's no guarantee that an older version of any extension will work when doing a big MediaWiki version upgrade - whether the wiki is populated or empty. Can't we just tell users to "bite the bullet"?

If you have an existing wiki that you want to migrate to Canasta that is running a couple of older extensions, it seems not unreasonable to do the migration, make sure things work under Canasta, then upgrade the extensions (by removing the older versions from the volumed in extension directory and restarting the container) as a second step. You already know that the older extensions work together, because you're migrating an existing wiki that is working with those extension versions. You're just trying to be able to isolate any issues that come from the Canasta migration from any issues that might come from the extension upgrades. Besides, unless you are proposing a way to prevent users from putting older versions of an extension in the volumed in extensions directory, this is indeed possible (if not advisable or supported) behavior.

Okay, everything you're saying makes sense, unfortunately. :) Still, this whole issue of making all sorts of preparations before calling "canasta import" in order to avoid extension DB updates - overriding composer.json, installing one's own version of the non-Composer extensions - seems like a real hassle: you basically have to "get all your ducks in a row" before doing the import, or else it's too late. (Actually, the handling for the non-Composer extensions seems even more extreme.) Maybe it would be better to add a "no-update" flag to "canasta import", so that admins can call update.php later, when they're ready to do it? Or would that introduce its own complications?

I can't think of any complications aside from folks forgetting to run the update later. I don't have a strong opinion either way.

Okay, it's good to know that this might be feasible. A "no-update" flag for "canasta import" seems like a much more straightfoward solution than requiring the admin to try to make sure everything is set up perfectly, as far as the "old" version of extensions, before they do the import.


[SPARK-31256][SQL] DataFrameNaFunctions.drop should work for nested columns

What changes were proposed in this pull request?

#26700 removed the ability to drop a row whose nested column value is null.
For example, for the following df:
val schema = new StructType()
  .add("c1", new StructType()
    .add("c1-1", StringType)
    .add("c1-2", StringType))
val data = Seq(Row(Row(null, "a2")), Row(Row("b1", "b2")), Row(null))
val df = spark.createDataFrame(spark.sparkContext.parallelize(data), schema)
df.show
+--------+
|      c1|
+--------+
|  [, a2]|
|[b1, b2]|
|    null|
+--------+

In Spark 2.4.4,
df.na.drop("any", Seq("c1.c1-1")).show
+--------+
|      c1|
+--------+
|[b1, b2]|
+--------+

In Spark 2.4.5 or Spark 3.0.0-preview2, if nested columns are specified, they are ignored.
df.na.drop("any", Seq("c1.c1-1")).show
+--------+
|      c1|
+--------+
|  [, a2]|
|[b1, b2]|
|    null|
+--------+

Why are the changes needed?

This seems like a regression.
Does this PR introduce any user-facing change?

Now, the nested column can be specified:
df.na.drop("any", Seq("c1.c1-1")).show
+--------+
|      c1|
+--------+
|[b1, b2]|
+--------+

Also, if * is specified as a column, it will throw an AnalysisException that * cannot be resolved, which was the behavior in 2.4.4. Currently, in master, it has no effect.
How was this patch tested?

Updated existing tests.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/26174/
Test PASSed.

@cloud-fan Please let me know if this PR (going back to 2.4.4 behavior) makes sense. Thanks!

Test build #121490 has started for PR 28266 at commit 283fee1.

nice,duplicate columns is same as struct alias which not works at toAttributes method in DataFrameNaFunctions.

Test build #121490 has finished for PR 28266 at commit 283fee1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/121490/
Test PASSed.

merging to master/3.0/2.4

So, SPARK-31256 made a regression at 2.4.5 and this recovers it?

@dongjoon-hyun yes

Thank you for confirmation~


undefined method `ok?' for #<Cucumber::Core::Test::Result::Unknown

Summary
When running cucumber using my default profile in --dry-run one of my features fails with the error message  undefined method 'ok?' for #<Cucumber::Core::Test::Result::Unknown
I am not very familiar with the cucumber source code, but it looks like Result::Unknown objects are not supposed to be created in --dry-run.
Default profile
--tags ~@known-failure --format pretty --format rerun --out last_run_failures
Backtrace
undefined method `ok?' for #<Cucumber::Core::Test::Result::Unknown:0x007ffbfdcba768> (NoMethodError)
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/lib/cucumber/formatter/rerun.rb:15:in `after_test_case'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/lib/cucumber/formatter/ignore_missing_messages.rb:10:in `method_missing'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/lib/cucumber/formatter/legacy_api/adapter.rb:45:in `after_test_case'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/lib/cucumber/formatter/fanout.rb:16:in `block in method_missing'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/lib/cucumber/formatter/fanout.rb:15:in `each'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/lib/cucumber/formatter/fanout.rb:15:in `method_missing'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/test/runner.rb:19:in `test_case'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/test/case.rb:23:in `describe_to'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/lib/cucumber/filters/activate_steps.rb:11:in `test_case'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/test/case.rb:23:in `describe_to'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/lib/cucumber/filters/quit.rb:11:in `test_case'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/test/case.rb:23:in `describe_to'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/test/filters/locations_filter.rb:17:in `block in done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/test/filters/locations_filter.rb:16:in `each'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/test/filters/locations_filter.rb:16:in `done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/filter.rb:61:in `done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/test/filters/tag_filter.rb:18:in `done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/compiler.rb:23:in `done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core/gherkin/parser.rb:35:in `done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core.rb:29:in `parse'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-1.5.0/lib/cucumber/core.rb:18:in `compile'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/lib/cucumber/runtime.rb:67:in `run!'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/lib/cucumber/cli/main.rb:32:in `execute!'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-2.4.0/bin/cucumber:8:in `<top (required)>'
/Users/jake/.rvm/gems/ruby-2.3.1/bin/cucumber:23:in `load'
/Users/jake/.rvm/gems/ruby-2.3.1/bin/cucumber:23:in `<main>'
/Users/jake/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `eval'
/Users/jake/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `<main>'

Expected Behavior

Current Behavior

Possible Solution
As a workaround I monkey patched #ok? on Cucumber::Core::Test::Result::Unknown.

Steps to Reproduce (for bugs)
To be honest, I am not sure how to reproduce. I'd be happy to pair with somebody to figure it out.

Context & Motivation

I use --dry-run to take inventory of scenarios and steps.
Your Environment

Version used: 2.4.0
Operating System and version: macOS 10.12
Link to your project:

This is already fixed by cucumber/cucumber-ruby#967, the cucumber gem v3.0.0.pre.2 (and v3.0.0.pre.1) contains the fix.

@brasmusson I installed v3.0.0.pre.2 and the bug still exists.

@JakeKaad can you please supply the backtrace you get with v3.0.0.pre.2?

undefined method `ok?' for #<Cucumber::Core::Test::Result::Unknown:0x007fcd48990698> (NoMethodError)
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-3.0.0.pre.2/lib/cucumber/formatter/console_issues.rb:15:in `block in initialize'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/event_bus.rb:34:in `block in broadcast'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/event_bus.rb:34:in `each'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/event_bus.rb:34:in `broadcast'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/event_bus.rb:40:in `method_missing'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/test/runner.rb:20:in `test_case'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/test/case.rb:25:in `describe_to'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-3.0.0.pre.2/lib/cucumber/filters/activate_steps.rb:12:in `test_case'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/test/case.rb:25:in `describe_to'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/test/filters/locations_filter.rb:18:in `block in done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/test/filters/locations_filter.rb:17:in `each'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/test/filters/locations_filter.rb:17:in `done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/filter.rb:62:in `done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/test/filters/tag_filter.rb:18:in `done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/compiler.rb:24:in `done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core/gherkin/parser.rb:37:in `done'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core.rb:32:in `parse'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-core-3.0.0.pre.2/lib/cucumber/core.rb:21:in `compile'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-3.0.0.pre.2/lib/cucumber/runtime.rb:74:in `run!'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-3.0.0.pre.2/lib/cucumber/cli/main.rb:33:in `execute!'
/Users/jake/.rvm/gems/ruby-2.3.1/gems/cucumber-3.0.0.pre.2/bin/cucumber:8:in `<top (required)>'
/Users/jake/.rvm/gems/ruby-2.3.1/bin/cucumber:23:in `load'
/Users/jake/.rvm/gems/ruby-2.3.1/bin/cucumber:23:in `<main>'
/Users/jake/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `eval'
/Users/jake/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `<main>'

Yep, --dry-run with features containing empty scenarios give this exception. I think the solution is to modify the Cucumber-Ruby compiler to not create Test Cases for empty Scenarios - which is consistent with the Gherkin compiler which does not create Pickles for empty Scenarios. See cucumber/cucumber-ruby-core#144.


Fix a couple things in #11336

@timabbott FYI, you'll want to squash these into the original commits from #11336.

Squashed the last two commits and merged, thanks @showell!


Project structure, globals

Usually Go applications use cmd directory in a bit different way. It should probably be cmd/packet-cli or just cmd/packet to get a good executable name.
Also, since everything is mashed together in a single directory, there's already a problem defining any new variables due to globals like https://github.com/packethost/packet-cli/blob/master/cmd/create_device.go#L31-L51.
It might make sense to remove those globals and those init functions https://github.com/packethost/packet-cli/blob/master/cmd/create_device.go#L128-L154

This is duplicate of #33 so we can move the conversation there.


Update emulator/simulator profile/release mode restriction to use arch restriction

Instead of attempting to gate release mode on the target device being a simulator/emulator, use a restriction based on supported AOT architectures. This would allow the tool to run release mode on x86_64 emulators today, and on iOS simulators if we decide to upload release artifacts for iOS x86_64
fyi @zanderso

Just found this change because I saw the message "Release mode is not supported by iPhone SE (2nd generation)." and was confused about whether I needed to do additional setup steps to be able to run release mode on an iOS device.
It makes sense to be more specific about the device, but can we still give users a hint that their device may be unsupported because it's an emulator?

I could update the messaging to include the device ABI info, and if we think it might be a simulator. In the Android case we can't definitely know something is an emulator, but if we've already failed to run including the output couldn't hurt

Yes that would be great!


Failed to build for Quicklisp dist

Building with SBCL <IP_ADDRESS>-442f54894 / ASDF 3.3.1 for quicklisp dist creation.
Commit id 4d9d28230315e05553d5575353a26271a278e9c9
cl-protobufs fails to build with the following error:
; caught COMMON-LISP:ERROR:
;   COMMON-LISP:READ error during COMMON-LISP:COMPILE-FILE: Package COM.GOOGLE.BASE does not exist. Line: 12, Column: 48, File-Position: 343 Stream: #<SB-INT:FORM-TRACKING-STREAM for "file /home/quicklisp/.cache/common-lisp/sbcl-<IP_ADDRESS>-442f54894-linux-x64/home/quicklisp/quicklisp-controller/dist/build-cache/cl-protobufs/aa82216c6f9a999fdc71ede466c4eb6f42917ef0/cl-protobufs-20201006-git/any.lisp" {10072473C3}>
...
Unhandled UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1001A50103}>: COMPILE-FILE-ERROR while compiling #<PROTOBUF-SOURCE-FILE "cl-protobufs" "well-known-types" "any">

cl-protobufs/tests fails to build because of a failure in  cl-protobufs.
Full log here

How did you get this failure?
Could you tell me the reproduction steps?

My mistake - this is due to a different version of protoc-gen-lisp installed.
But this raises a new issue. https://github.com/brown/protobuf/ also wants protoc-gen-lisp for its version of the library. They both can't be installed with the same name.
ALso, getting Unhandled CL-PROTOBUFS:PROTOBUF-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1000A30083}>: Could not find file "type.proto" imported by #<CL-PROTOBUFS:FILE-DESCRIPTOR API (package google.protobuf) {1007196CA3}> when trying to build with the matching protoc-gen-lisp for the qitab cl-protobufs project.

Yea, we borrowed a lot from browns protoc code, we should probably change then name,
I'll do that shortly (tomorrow?)

As for the second comment:
Interesting, I've never seen that failure and all of the tests are passing CI.
The type.proto is here: It's here: https://github.com/qitab/cl-protobufs/blob/master/google/protobuf/type.proto .
I can't see a reference in the file-descriptor code to type.proto so I'm even more clueless...

I see the same Could not find file "type.proto" error when trying to load cl-protobufs in a fresh REPL.  But if I choose restart 0 (TRY-RECOMPILING) it succeeds.
Full log: https://gist.github.com/49f025f777fa2c0da3e3bf97f18abdb7

Hoy a fix #266

we should probably change then name, I'll do that shortly (tomorrow?)

Did this ever happen?

Did not, theres a hook I'm missing somewhere...

I think it deserves it's own issue though: https://github.com/qitab/cl-protobufs/issues/276


Table with useExpanded and useGlobalFilter not working properly

Describe the bug (required)
I am trying to create a table with sub rows and filtering (global) functionality. When the filtration is applied the expand functionality breaks and we no longer see the expand buttons. Notice I am doing a very simple filtration, just on the root level and not on the sub rows.
Provide an example via Codesandbox! (required)
https://codesandbox.io/s/busy-stallman-1tcx5?file=/src/App.js
Steps To Reproduce (required)
Steps to reproduce the behavior:

Go to the search field
Type some characters to filter
See the expand buttons are no longer available

Expected behavior (Recommended)
The table should still expand.
Screenshots

Desktop (please complete the following information):

OS: MacOS 12.1
Browser: chrome
Version: Version 97.0.4692.71 (Official Build) (x86_64)

Did you manage to fix it or find a work-around ?
It's the same issue I mentionned here but I think this is the behavior they're expecting since the line "instance" in that case does not have SubRows anyway.
However I don't understand why clearing the filter does not return the old state of "instance" ?
Maybe I have to implement a custom filter function or something ? I didn't find a way yet to display the SubRows of an unfiltred/displayed Parent.

See this

It looks like there is a bug with the same plugins
Take a look here, an example was provided there
It seems that this part in useGlobalFilter need an intialSubRows state better than changing the subRows. So we execute the filter on the intialSubRows instead.

See this

This example didn't work for me.. defaultGlobalFilter has error:
const defaultGlobalFilter: (rows: any, columnIds: any, filterValue: any, options: any) => any
Expected 4 arguments, but got 3.ts(2554)
defaultGlobalFilter.tsx(7, 5): An argument for 'options' was not provided.

@GulinaTayier you're using TS clearly and you need to make the last argument as an optional argument
export type FilterOptions = {
    filteredIds: string[];
};

// Better to use Generics for rows == Row<T> https://www.typescriptlang.org/docs/handbook/2/generics.html
// options is optional
const defaultGlobalFilter = (rows: Row<any>, columnIds: string[], filterValue: any, options?: FilterOptions ) => {

With that being said, this example is just a work around for v7 and I suggest to try first v8.