Failure to detect heap

[chemicstry]

I'm using heap provided by alloc-cortex-m on STM32F429ZIT6, however probe-run fails to detect heap usage and still installs stack canary, which results in bogus warnings like:

(HOST) WARN  program has used at least 171.40/171.39 KiB (100.0%) of stack space
(HOST) WARN  data segments might be corrupted due to stack overflow

I have narrowed the problem to this heap check, which fails to detect any of the alloc symbols.

Output of cargo nm --release | grep alloc:

Finished release [optimized + debuginfo] target(s) in 0.36s
08000534 t usb_device::bus::UsbBusAllocator<B>::alloc::h0253d5b90b0dafb0
080005b6 t usb_device::bus::UsbBusAllocator<B>::alloc::hb0dd93daa92d3cae
080166c4 t <canadensis_data_types::uavcan::pnp::node_id_allocation_data_1_0::NodeIDAllocationData as canadensis_encoding::Serialize>::serialize::h7dcafc16784d9408
08003116 t fw_stm32_common::canadensis_ext::pnp::allocate_node_id::{{closure}}::{{closure}}::{{closure}}::h19839ac502d6ffa6
08003138 t fw_stm32_common::canadensis_ext::pnp::allocate_node_id::{{closure}}::{{closure}}::{{closure}}::h6564707757255913
08007850 t synopsys_usb_otg::bus::EndpointAllocator<USB>::alloc::hb03f407045e70c99
0801d0c4 t linked_list_allocator::hole::deallocate::hfcb012a409cd2d2a
0801d050 t linked_list_allocator::hole::HoleList::align_layout::h0f25c6e851bb429c
080089ea t core::ptr::drop_in_place<alloc::vec::Vec<canadensis_can::rx::subscription::Subscription<fw_stm32_common::time::uavcan::Instant>>>::he0560cd45be1a7a4
08008ab6 t core::ptr::drop_in_place<core::option::Option<alloc::boxed::Box<canadensis_can::rx::session::Session<fw_stm32_common::time::uavcan::Instant>>>>::h9671c183879172b2
0801ab50 t alloc::vec::Vec<T,A>::extend_from_slice::h1bac4d1657fad16b
080145b8 t alloc::alloc::handle_alloc_error::hfbc95268001d494f
080145c2 t alloc::alloc::handle_alloc_error::rt_error::h9661dda399c861db
0801aaf6 t alloc::raw_vec::finish_grow::he6913117c6d464a9
08014584 t alloc::raw_vec::capacity_overflow::h412ed752d5fca7cc
080091de t alloc::raw_vec::RawVec<T,A>::reserve_for_push::h7e349fab2aa2f3ed
08009246 t alloc::raw_vec::RawVec<T,A>::reserve_for_push::hf8fbe1010bbf92d1
0801aa98 t alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle::h574179f63b151501
08019f58 t <core::alloc::layout::LayoutError as core::fmt::Debug>::fmt::he9c098ce5fec097d
0801460c t <alloc_cortex_m::CortexMHeap as core::alloc::global::GlobalAlloc>::alloc::h05479245ca05c448
0801477e t <alloc_cortex_m::CortexMHeap as core::alloc::global::GlobalAlloc>::dealloc::hbfb5b6c4362a219d
080098aa t <synopsys_usb_otg::bus::UsbBus<USB> as usb_device::bus::UsbBus>::alloc_ep::h9f654e8fbc4f0ca2
0801457e t __rust_alloc_error_handler
08014546 t __rust_realloc

So it seems that rust compiler does not emit the __rust_alloc symbol, or it gets inlined? I'm not sure what would be the best way to fix this. Adding additional symbols to check like __rust_realloc might not be fail-proof if they can be inlined too.

[jonas-schievink]

cortex-m-rt exports an __sheap symbol here: https://github.com/rust-embedded/cortex-m/blob/master/cortex-m-rt/link.x.in#L180

Due to the PROVIDE it should only be defined when it is referenced, so maybe we can use that to detect the heap instead?

[jonas-schievink]

ah that was the original plan, it seems like that didn't work right: #31 (comment)

[chemicstry]

Ah I see.

I really liked the watermark idea from the linked issue since it would work with heap and could also report approximate stack usage. Any reasons for not doing that instead? I imagine chips with large memory could be slow, but is that an issue with anything that probe-rs supports?

[jonas-schievink]

That is what we implemented

[Urhengulas]

I really liked the watermark idea from the linked issue since it would work with heap and could also report approximate stack usage. Any reasons for not doing that instead? I imagine chips with large memory could be slow, but is that an issue with anything that probe-rs supports?

@chemicstry You can enable this feature with the --measure-stack option. Also since #302, #327 and #331 it got pretty fast.

[Urhengulas]

So it seems that rust compiler does not emit the __rust_alloc symbol, or it gets inlined? I'm not sure what would be the best way to fix this. Adding additional symbols to check like __rust_realloc might not be fail-proof if they can be inlined too.

It seems that this is the best we can do. But I personally don't know if the symbols __rust_alloc_error_handler and __rust_realloc are only present if there is some kind of heap, or if they are also present in other situations. Do you know about this?

[chemicstry]

It seems that --measure-stack option works, or at least doesn't give warnings. However, the stack measurement is still broken:

$ probe-run --chip STM32F429ZITx --measure-stack target/thumbv7em-none-eabihf/release/fw-power-switching 
(HOST) INFO  flashing program (119 pages / 119.00 KiB)
(HOST) INFO  success!
(HOST) INFO  painting 181.31 KiB of RAM for stack usage estimation
────────────────────────────────────────────────────────────────────────────────
...
────────────────────────────────────────────────────────────────────────────────
(HOST) INFO  reading 181.31 KiB of RAM for stack usage estimation
(HOST) INFO  program has used at least 181.31/181.31 KiB (100.0%) of stack space

It could be due to an issue with my code, though. I will update once I find more time to investigate this.

[Urhengulas]

Is this example with some kind of heap? Atm, we only handle single-ram chips well.