[Android] Support new file chooser

Use new XWalkFileChooser.
Request dangerous persmisions dynamically for Marshmallow and above.

BUG=XWALK-7281

@fujunwei @xzhan96 Please help to review

This feature is for Crosswalk-23. If this commit is merged, the plugin will not be compatible with the build prior to Crosswalk-23.

This feature is for Crosswalk-23. If this commit is merged, the plugin will not be compatible with the build prior to Crosswalk-23.

Does this info need to be added into commit log?

Ok, it will be announced at release notes.

Can you explain the source of the incompatibility?

@rakuco XWalkFileChooser is a new class starting with Crosswalk-23.

@fujunwei Updated. The change for app tools is in another patch of crosswalk repo.

It's better to hold those codes in a function, and please confirm the feature of choosing file is work finely with App-tools.

The Chromium SelectFileDialog requests the 6.0 permissions there.
https://github.com/crosswalk-project/chromium-crosswalk/blob/master/ui/android/java/src/org/chromium/ui/base/SelectFileDialog.java#L120
Should this change go in the XWalkFileChooser instead?  With the current pull request, the Crosswalk plugin is going to spam the user for camera permissions and external storage when they might not ever even use the file chooser.

 We are going to change the timing of requesting dangerous permissions to trigger it only when the file chooser is to be launched. Though this pull request is not supposed to be merged soon.

Updated. Requests permissions only when the file chooser is going to be launched.

@fujunwei Please remember to merge this pull request when the dependent crosswalk's version is 23.

This doesn't seem to open the file picker for the correct acceptType. If my HTML is <input type=file accept="image/*"> it only offers Camera and Documents, not the Photos app.

Yes,  capture="true" attribute need to be added if you want only capture image with camera.

Yeah, I've confirmed my issue is unrelated to this PR's code, and I've filed XWALK-7451 to track it separately.

Is there a timeline for merging this? I'm having issues with the old file chooser (photos from the camera are deleted before they can be read), and would rather not spend ages tracking down the problem if this fixes it.

This patch has to wait for Crosswalk-23, but the release date of it is uncertain.

@fujunwei Updated. Please help to review


Is llama2 a group query attention or multi head attention?

I remember llama2 uses group query attention. In the llama.c, I found there are kv_heads, kv_dim.

In run.c, I find something like this.
 // qkv matmuls for this position         matmul(s->q, s->xb, w->wq + l*dim*dim, dim, dim);         matmul(s->k, s->xb, w->wk + l*dim*kv_dim, dim, kv_dim);         matmul(s->v, s->xb, w->wv + l*dim*kv_dim, dim, kv_dim);

Thanks for you question. I found this issue in the original llama repo quite interesting  . Probably need to revise & adapt our implementation.
@magician-blue did you implement similar approach in you recent PR?

#24


Add BLENDED model

The BLENDED model allows for simultaneous calibration of model parameters and model structure (see Mai et al. (2020)).

Both tests (TestBLENDED and TestBLENDED_OST) pass.
Test test_blended.py should be merged into test_emulators.py. Just did not work on my system due to missing GDAL and @Zeitsperre made test to skip in that case.
Created branch off raven_gis_ports.

Things to discuss/ implement:

[x] parameter avg basin slope [deg] SLOPE (RVH) should be templated (similar to, for example, elevation)
[x] parameter forest cover [frac] FOREST_COV (RVP) should be templated (similar to, for example, elevation)
[x] RVT file should contain two parameters :RainCorrection and :SnowCorrection. Can be default at 1.0 but might be given as parameter (here par_x33 and par_x34, respectively)

Hi @julemai
Please take a look at the modifications I made to template the remaining parameters. In the last commit, the rain and snow correction values are taken from the parameter list, but this changes the model output and breaks the asserts.
Otherwise, I think this is good to go. I think it will be useful to include for each emulator some documentation and references. Will open a PR for this (maintenance).

Ignore what I said... It's para_x33 and para_x34. Test 1 is passing now and that means that I am VERY sure that the second one should also be correct. Just double-checking. One second....

The Ostrich test fails and this is because :RainCorrection and :SnowCorrection get filled in all the time with 1 (default). But they should be filled with par_x33 and par_x34 such that Ostrich knows where to fill in values during calibration. I just don't know how and where to adjust this. @huard could you have a look?

Tests are both passing on my end. I confirmed that it is the same as 8f31afd when x33 and x34 are fixed during calibration.

Great !
Yes. Don't do anything fancy for now, maybe just one line about what is special about the model and the reference to your paper.
Also, is "BLENDED" the official name of your model ? If there is no official name, I would suggest finding a more memorable name.

@julemai it looks like in the Gauge command, I can leave the lat, lon, elev to None and all tests pass. But if remove the Commands altogether, then the model complains and fail.
Given it does not seem to make any difference, I would revisit this issue later and not hold up this PR.

Yes, let's leave them to None then. The commands can not be removed; they should be set to the elevation etc you use at other parts too. But let's go ahead.

I suggest we wait for the 0.3 release before merging into master.
Note that we'll need to update HISTORY to reflect this new, very cool addition.

Please use: https://github.com/CSHS-CWRA/RavenPy/pull/76


in_app_purchase sample code error: unable to connect to the payments processor

Is there an existing issue for this?

[X] I have searched the existing package issues
[X] I have read the guide to filing a bug

What package does this bug report belong to?
in_app_purchase
What target platforms are you seeing this bug on?
Android
Have you already upgraded your packages?
Yes
Dependency versions
pubspec.lock
[Paste file content here]

name: flutter_in_app_purchase_demo
description: A new Flutter project.
publish_to: 'none' # Remove this line if you wish to publish to pub.dev
version: 1.0.0+1
environment:
sdk: '>=3.0.3 <4.0.0'
dependencies:
flutter:
sdk: flutter
cupertino_icons: ^1.0.2
in_app_purchase: ^3.1.8
shared_preferences: ^2.2.0
dev_dependencies:
flutter_test:
sdk: flutter
flutter_lints: ^2.0.0
flutter:
uses-material-design: true

Steps to reproduce

Create new flutter projects, install in_app_purchase package, and copy the sample code for main.dart and consumable_store.dart
Run the app using Android Emulator(In my case, this is Pixel XL 33)
Issue: The Android Emulator will show error on startup.

Expected results
No error should occur
Actual results

Code sample
The sample code for main.dart:
https://github.com/flutter/packages/blob/main/packages/in_app_purchase/in_app_purchase/example/lib/main.dart
The sample code for consumable_store.dart:
https://github.com/flutter/packages/blob/main/packages/in_app_purchase/in_app_purchase/example/lib/consumable_store.dart
Screenshots or Videos

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[Paste your output here]

flutter doctor -v
[√] Flutter (Channel stable, 3.13.2, on Microsoft Windows [Version 10.0.22621.2283], locale en-US)
• Flutter version 3.13.2 on channel stable at C:\Flutter\flutter_windows_3.0.1-stable\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision ff5b5b5fa6 (5 weeks ago), 2023-08-24 08:12:28 -0500
• Engine revision b20183e040
• Dart version 3.1.0
• DevTools version 2.25.0
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
• Android SDK at C:\Users\Home\AppData\Local\Android\sdk
• Platform android-33, build-tools 33.0.0
• Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
• Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-10027231)
• All Android licenses accepted.
[√] Chrome - develop for the web
• Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.7.3)
• Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
• Visual Studio Community 2022 version 17.7.34024.191
• Windows 10 SDK version 10.0.22621.0
[√] Android Studio (version 2022.3)
• Android Studio at C:\Program Files\Android\Android Studio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-10027231)
[√] IntelliJ IDEA Community Edition (version 2021.2)
• IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2021.2.3
• Flutter plugin version 70.0.2
• Dart plugin version 212.5744
[√] VS Code (version 1.82.2)
• VS Code at C:\Users\Home\AppData\Local\Programs\Microsoft VS Code
• Flutter extension version 3.72.0
[√] Connected device (4 available)
• sdk gphone x86 64 (mobile) • emulator-5554 • android-x64    • Android 13 (API 33) (emulator)
• Windows (desktop)          • windows       • windows-x64    • Microsoft Windows [Version 10.0.22621.2283]
• Chrome (web)               • chrome        • web-javascript • Google Chrome 114.0.5735.199
• Edge (web)                 • edge          • web-javascript • Microsoft Edge 117.0.2045.43
[√] Network resources
• All expected network resources are available.
• No issues found!

Have you configured correctly with Google Play?

Hi @DktPhl2019, in addition to https://github.com/flutter/flutter/issues/135635#issuecomment-1738256338 does the emulator you are using have google play support? If it does not, you cannot access the play store.

I rerun the demo code on the Emulator using Google Play, and I see the same error. I am not sure what I need to configure with Google Play and especially correctly. Do I need to use a very specific emulator? Could you please provide more information. I thought I would run the sample code, and it should work. Thank You

Hi @DktPhl2019, in_app_purchase is a different case. You need to set up your app on the Google Play Store/Apple Store. See the Getting Started guide in the plugin readme https://pub.dev/packages/in_app_purchase#getting-started. You'll need to follow the instructions to set up your app on the respective stores that you want to have purchases for. You can also follow the instructions in the plugin example readme https://github.com/flutter/packages/blob/main/packages/in_app_purchase/in_app_purchase/example/README.md


add mongo workflow

Checklist

[ ] run npm run test and npm run benchmark
[ ] tests and/or benchmarks are included
[ ] documentation is changed or added
[ ] commit message and code follows the Developer's Certification of Origin
and the Code of conduct

Should we use mongo 6? Should we add parameters?

Should we use mongo 6? Should we add parameters?

I would check both version.
But from my experience, server version shouldn't makes different since we check the connection only in @fastify/mongodb.

There is no official mongo:6.0.0 docker image it seems like.


Errors while using C and GHC preprocessors

I'm on ghc 8.0.1 (stackage nightly-2016-07-07) and i'm trying to use derive for Arbitrary, Uniplate and Biplate. I tried both preprocessors, the error message does not give me enough information to figure out why they don't work.
With cpp https://github.com/ndmitchell/derive#using-cpp
» stack build --ghc-options '-rtsopts -fprof-auto -fprof-auto-calls -fprof-cafs' --executable-profiling
vhdl-<IP_ADDRESS>: build
Preprocessing executable 'vhdl' for vhdl-<IP_ADDRESS>...

/home/flip111/haskell/vhdl/src/Main.hs:14:0: error:
     fatal error: file.h: No such file or directory
     #include "file.h"
     ^
compilation terminated.
`gcc' failed in phase `C pre-processor'. (Exit code: 1)

--  While building package vhdl-<IP_ADDRESS> using:
      /home/flip111/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-<IP_ADDRESS>-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-<IP_ADDRESS> build exe:vhdl --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

with ghc preprocessor https://github.com/ndmitchell/derive#as-a-ghc-preprocessor
» stack build --ghc-options '-rtsopts -fprof-auto -fprof-auto-calls -fprof-cafs' --executable-profiling
vhdl-<IP_ADDRESS>: configure
Configuring vhdl-<IP_ADDRESS>...
vhdl-<IP_ADDRESS>: build
Preprocessing executable 'vhdl' for vhdl-<IP_ADDRESS>...
derive: Don't know how to derive type class: Generic
CallStack (from HasCallStack):

  error, called at src/Derive/Derivation.hs:75:0: error:
    59 in derive-2.5.26-D3fLjLIsNAEmHqh8OJSQ3:Derive.Derivation
`derive' failed in phase `Haskell pre-processor'. (Exit code: 1)

--  While building package vhdl-<IP_ADDRESS> using:
      /home/flip111/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-<IP_ADDRESS>-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-<IP_ADDRESS> build exe:vhdl --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

Sorry for the delay in replying - this totally slipped through the cracks. As per #6 I'm seeking to pass maintainership on to someone else, so they might be able to help better.
Generally, for Uniplate, I recommend Uniplate.Data. I'd only consider moving away from that if benchmarking showed it to be a huge problem.
For Arbitrary, the derive version isn't super-great, see #10.
With all that said, try the latest version - a lot of bugs around GHC 8 and some template haskell syntax got fixed. It may just work now.


Use env_logger for debugging instead of println!

This PR addresses [issue #75] https://github.com/succinctlabs/succinctx/issues/75
Changes made:
-changed all println! statements to use env_logging info!() to be used.
-small refactor on env_logger initialization
This is my first time doing open source contribution.
I would like feedback on these changes. Thank you!

Looks good so far!
Could you please use utils::setup_logger(); instead of setup_logger directly?
and also, please go through the repo and look for all instantiations of env_logger::init and replace it with utils::setup_logger()

Also, inside tests, debug! is more appropriate than info!.

Also, you shouldn't call setup_logger in places besides entrypoints. That means calling it in random functions is inappropriate.

Thanks for the prompt feedback. I have now:
changed all instances of setup_logger() with utils::setup_logger(), including instances I did not originally introduce (example \succinctx\plonky2x\src\backend\wrapper\wrap.rs had setup_logger() before any of my changes)
Looked for instances of env_logger::init to remove.
I see in plonky2x\src\frontend\hash\poseidon\poseidon256.rs there is a setup_logger(); within test_poseidon() that was already in place before. It does not have any log macros used (no debug!(), info!(), etc.). I did not remove it but updated to utils::setup_logger() in case there were plans to introduce log calls in the future.
changed all info!() macros within tests into debug!()
Some questions:
Found some test methods (ex. test_sha512_large_msg_variable in plonky2x\src\frontend\hash\sha\sha512.rs) had dbg!() call. should this also be changed to debug?
Regarding setup_logger usage: I am not entirely sure where setup_logger() is called on runtime and originally decided to include it in all methods that used the log macros. In my most current check-in I removed all instances of utils::setup_logger() in methods that were not tests that I introduced. Please let me know if I am wrong in doing that, but that's the message I got out of comments to take setup_logger() out of methods like plonky2x/src/frontend/eth/rlp/builder.rs
in files such as succinctx\plonky2x\src\backend\wrapper\wrap.rs prove() method I saw existing code where some non #[test] methods have debug!() instead of info!(). should all log calls be debug!() then or was there different rationale for this?

@meekteek This is good progress. I think we could just merge this, any more work seems to me very marginal.


Fix readme and solution for building custom immage [WIP]

Incase @ifilonenko wants to take over while I'm off dealing with lasers and other "fun" things.

So, there's no reference to the env variable GOOGLE_CLOUD_PROJECT so I'm sticking with the one that we used before. changing it doesn't give us anything I can see?

oh wait as per discussions: that isn't set if the person hasn't set the project in the WebUI so we don't want to depend on that.


Correction for raw affiliation National Advanced School of Engineering, University of Yaoundé I, PoBox 8390, Cameroon; UMR Amap, University of Montpellier, CIRAD, CNRS, INRA, IRD, F-34398 Monrtpellier, France

Correction needed for raw affiliation National Advanced School of Engineering, University of Yaoundé I, PoBox 8390, Cameroon; UMR Amap, University of Montpellier, CIRAD, CNRS, INRA, IRD, F-34398 Monrtpellier, France
raw_affiliation_name: National Advanced School of Engineering, University of Yaoundé I, PoBox 8390, Cameroon; UMR Amap, University of Montpellier, CIRAD, CNRS, INRA, IRD, F-34398 Monrtpellier, France
new_rors: 051escj72;022zbs961;05kpkpg04;05q3vnk25;02feahw73;020nks034
previous_rors: 051escj72;022zbs961;05kpkpg04;05q3vnk25;02feahw73
works_examples: W4402900939
contact: 841ce4509e689d367dc8fae35100cfe8:188894afa2de71e3a09f106922a1d58a8f26 @ inrae.fr

This issue was accepted and ingested by the OpenAlex team on 2024-11-18. The new affiliations should be visible within the next 7 days.


Error messages from GetPodInfo of unscheduled pods causes confusion

pod_cache.go:UpdateAllContainers passes CurrentState.Host directly to updatePodInfo, which immediately calls GetPodInfo:
err := p.updatePodInfo(pod.CurrentState.Host, pod.ID)

This results in obscure log messages like:
pod_cache.go: pod_cache.go:83] Error synchronizing container: Get http://:10250/podInfo?podID=apache: dial tcp :10250: connection refused
Note lack of host name.
This could be a symptom of a problem, such as the scheduler not running. Or, it's possible the pod just hadn't been scheduled yet. A clearer error message, such as "pod apache not yet scheduled" would make troubleshooting faster (or possibly unnecessary).
Example IRC discussion: https://botbot.me/freenode/google-containers/2014-09-11/?msg=21477410&page=8

@bgrant0607 , is this still an open issue ? The code that computes PodStatus checks whether Host is empty and returns PodPending in this case without obscure error (https://github.com/GoogleCloudPlatform/kubernetes/blob/2ac6bbb7eba7e69eac71bd9acd192cda97e67641/pkg/master/pod_cache.go#L160)

Probably not. Thanks.


add avdl interface retrieveMessages

r? @mmaxim @maxtaco

Also one general comment, I think you should try to rebase master into your branch to reduce the number of merge commits in the PR. It just makes it easier to follow, you can just push with --force to any branch other than master.

@mmaxim Thanks Mike! I normally merge from master right before merging, and use "squash and merge" on GitHub. This way it's just one commit on top of master HEAD, while still allowing preserving PR history. Does this approach also sounds alright?


Create 599.is-cool.dev.json

I have read the CLA Document and I hereby sign the CLA

Requirements

[x] You have completed your website.
[x] The website is reachable.
[x] You have put a full stop (.) at the end of each of the CNAME, MX and NS records.
[x] The CNAME record doesn't contain https:// or /.
[x] There is sufficient information at the owner field.

Description    Amateur radio and networking related applications to test and learn, thanks for approving my application!

Link to Website   For example, the NTP server related tests, etc., are temporary dynamic, so in order not to deceive me I can not give an accurate connection!

I have read the CLA Document and I hereby sign the CLA


avoid calling cluster related functions while instantiating views on …

…a db server
Please note that for legal reasons we require you to sign the
Contributor Agreement
before we can accept your pull requests.

http://jenkins01.arangodb.biz:8080/view/PR/job/arangodb-matrix-pr/2282/


Missing the word "pyproject.toml" in Quickstart.

In the sentence "If you are experimenting with configuration using, or have version of..."

Summary of changes

Closes
Pull Request Checklist

[ ] Changes have tests
[ ] News fragment added in changelog.d/.
(See documentation for details)

Thank you very much @mloyd


Features/login

The login has been updated, the changes are:

The application icon changed from angular icon to solid icon.
Add Solid logo in index.html
Title of index.html has been modified.
Selection of ID provider improved.

I like it, if everyone agrees let's merge this into develop

Okay.

If anyone wants to custom it with a representative pic for our chat. (Just create a simple icon like whatsapp one) or don't now for me it's ok to merge into develop.

Let's leave the PR open until Monday just in case, but we can add the logo at any time, there's more important stuff to think about rn


Fork example produces syntax error

Hi there,
Thanks so much for your work on this project! It's proven very useful so far. However, I'm having an issue using a fork in an activity diagram. The following code produces a test diagram within Pintora's docs:
activityDiagram
  start
  if (multiprocessor?) then
    fork
      :Action 1;
    forkagain
      :Action 2;
    endfork
    else (monoproc)
      :Action 1;
      :Action 2;
    endif
  end

If I pop that same code into VSCode, I get the following:
Syntax error at line 4 col 11:

      fork
            ^
Unexpected NL token: "\n". Instead, I was expecting to see one of the following:

A WS token based on:
    forkSentence$ebnf$2$subexpression$1 →  ● %WS statement
    forkSentence$ebnf$2 →  ● forkSentence$ebnf$2$subexpression$1
    forkSentence → "fork" forkSentence$ebnf$1 %NL ● forkSentence$ebnf$2 forkSentence$ebnf$3 _ forkSentence$subexpression$1 %NL
    statement →  ● forkSentence
    line → line$ebnf$1 ● statement
    conditionSentence$ebnf$2 → conditionSentence$ebnf$2 ● line
    conditionSentence → "if" wordsInParens "then" conditionSentence$ebnf$1 %NL ● conditionSentence$ebnf$2 conditionSentence$ebnf$3 _ "endif" _ %NL
    statement →  ● conditionSentence
    line → line$ebnf$1 ● statement
    document → document ● line
    start → %ACTIVITY_DIAGRAM ● document

I'd love to be able to use the fork keyword! Thanks again!
Cheers,
Tim

I'm so glad that you find my work useful.
I've tried the code above with the latest pintora-vscode 0.5.0 and it works well.
Could you try upgrading the extension and see if it's also OK for you ?

@timfitzzz Sorry to bother you, but did your issue fixed?


Lattice makes world transparent under them! (FIXED: MoreCulling mod by FX was a reason)

Thing for flowers vines on the wall makes it x-rayed far away, I shutted my resourcepacks and shaders, maybe mods is a problem
If you suggest that they are, please don't be annoyed, I will exclude some parts to find mod that makes that problem and will know what to do

For future, the problem was caused by More Culling (https://modrinth.com/mod/moreculling), when you use agressive BlockState culling it makes wall with your Lattice become transparent. Without Block state culling the problem will not appear, but now Leaves Culling function is not able, well let it be so


Use a large top app bar in the settings

This PR adds a navigation icon to leave the settings screen as well as a top bar, that collapses automatically on scroll.
This seems to be fitting well here as the app currently doesn't have a lot of settings available in the settings screen and therefore it looks quite well.

Hey, sorry it took a while for me to get a look at this! I really like it, thanks!

No worries, thanks for giving it a try!


I would like more mentors

We have 8 requests for mentoring, we have 4 mentors.
We could ask other members/key contributors such as:

[ ] @dinever
[ ] @blkperl
[ ] @JPZ13
[ ] @tczhao

@alexec What all is involved in mentoring? I'm interested but strained for time this week. I could start in March

This is for general mentoring since we got an increasing number of mentoring requests: https://github.com/argoproj/argo-workflows/issues?q=is%3Aopen+is%3Aissue+label%3Amentoring
We should assume that the people who requested mentors are for general mentoring (see the first question in the issue template)

@alexec I can help out minus the Typescript/React/UI part.

Sounds good, happy to be a mentor.

@dinever only for general mentoring.

Next actions (if you're happy to help mentoring):

Please review the linked PR and approve it.
Take a look at the mentoring requests and see if theres someone you think you could help.
Comment on the issue offering your help. Perhaps add any useful getting started pointers. E.g. guides.
If they accept your offer, then assign the issue to yourself and remove the "triage" label.

@alexec Perhaps also update the mentoring guide regarding the process as part of https://github.com/argoproj/argo-workflows/pull/7889?

Yes. We are feeling our way a bit.


Upgrade LLVM to version 13.0.1

This PR upgrades LLVM to version 13.0.1, it seems like upstream finally fixed our codegen issues and everything builds fine for me. I did have to do a few small changes to the patches, so someone should double check them before merging.

Apart from the cleanup, this doesn't seem to break weston, kmscon or a few handful of applications I tested. However, the mmap tests of posix-tests fail for me, but I'm not sure whether that's due to LLVM 13 to begin with (vs. for example, some local change I have applied).
Overall, I guess I give this a cautious thumbs-up then. Having CI build this and everyone being able to pull feels worthwhile, given that building this PR took me over 4.5 hours.

Turns out the mmap failures were due to local changes, so this PR gets a :+1: from me.

exa -l breakage seems unrelated (rtdl issue)


Empty rooms if no content on pages

As a user, I want to see some suggestions and info about the page if it doesn't have any content.

main page
my posts
my favorites

like in this example

Main page should always have some content, right? It can now be blank when we are testing, but when it goes live, should we consider a case when the main page has no content?


Markdown Preview - No automatic hyperlink for python filenames with underscore

Issue Type: Bug
Reproduction:

Create a new markdown file
Create content:

file_name.py - this has no hyperlink
file-name.py - this has a hyperlink

Open preview

Expected behaviour: Both python files should have a hyperlink
Actual behaviour: The filename with the underscore does not have a hyperlink
Possibly _ is not part of the filename recognition algorith.
Please see screenshot for an example.
VS Code version: Code 1.56.1 (e713fe9b05fc24facbec8f34fb1017133858842b, 2021-05-06T10:08:24.325Z)
OS version: Darwin x64 19.6.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz (12 x 2600)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 2

Memory (System)
16.00GB (0.32GB free)

Process Argv
--disable-extensions

Screen Reader
no

VM
0%

Extensions disabled

This the default markdown-it linkifier behavior: https://markdown-it.github.io/#md3={"source"%3A"file_name.py - this has no hyperlink\n\nfile-name.py - this has a hyperlink"%2C"defaults"%3A{"html"%3Afalse%2C"xhtmlOut"%3Afalse%2C"breaks"%3Afalse%2C"langPrefix"%3A"language-"%2C"linkify"%3Atrue%2C"typographer"%3Atrue%2C"_highlight"%3Atrue%2C"_strict"%3Afalse%2C"_view"%3A"html"}}
You can set "markdown.preview.linkify": false to disable automatic link creation


Feature Request

Is your feature request related to a problem? Please describe.

NO, Just bored <3

Sigma Sigma

Describe the solution you'd like

On the wall

Describe alternatives you've considered

Whos the skibidi'st

Additional context

Of them all!

(PS: ITS YOU)

FEATURE REQUEST 115!?!?!?!?


hostname seems not to be in holod configuration

When using remote holi-cli on several nodes, the hostname is always set to holo.

I agree. The current "hostname" command feels more like a gimmick than anything useful.
I believe the best course of action is to implement the 'ietf-system' module, which would provide us with the 'system hostname STRING' command. Then, the CLI should use the hostname from the running configuration in the prompt.


Im unable to drink and eat

https://bytebin.lucko.me/H4mYNlAplw

Run server, join try eat and drink

Only occuring in Multiplayer

No idea, 714 mods is a lot

I solved it. Not your mod. Sorry.


Updating actions/checkout to version v2.4.0.

Updating actions/checkout to version v2.4.0.
@AnandChowdhary - I am not sure if this needs to be updated in other places; I do not claim to be a JS expert at all, so I might be missing some steps (I saw some references to v2.3.3 in the dist/ directory? Not sure if that is produced as a side effect of some CI build?)

I have read the CLA Document and I hereby sign the CLA

recheck

recheckcla


[Burning Wheel] Readme macro typo fix

Changes / Comments

Fixed Readme macro version number display error

Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[x] Does the pull request title have the sheet name(s)? Include each sheet name.
[x] Is this a bug fix?
[ ] Does this add functional enhancements (new features or extending existing features) ?
[ ] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.

Character Sheet Info Roll20 Internal Use only.


Incorrect Content-Type: application/json;

Lately we've been getting a lot exception for this error. Probably an error on recaptcha's server that was returned, instead of valid json.
It's not handled in reCAPTCHA.AspNetCore.RecaptchaService+<Validate>
Would be great if there was a retry, or if we could pass in an HttpClient (typed to CaptchaService maybe?).
Is this project still active? Accepting PRs?

We traced it down to this file/class, at line 104.
https://github.com/dotnet/aspnetcore/blob/main/src/Http/Http/src/Features/FormFeature.cs
The post was altered by a bot/hacker to have an incorrect content type.
I think this lib should capture this and maybe return as invalid response.

Project was not active at the time of request. Closing for now and will work to address additional concerns in future net8 version.


Add wyoming-openwakeword addon for homeassistant-core container

Hi @dusty-nv 👋
Just small a WIP status update from my side – I am currently working on below jetson-containers:

homeassistant-base-image - jetson-containers compatible base container for Home Assistant & HA Addon containers with S6 & rootfs (autodiscovery WIP)
homeassistant-core - Improved Dockerfile, uses homeassistant-base-image in depends
wyoming-openwakeword - uses homeassistant-base-image in depends, installs & run the openWakeWord

So far I have working:

Home Assistant Core container
openWakeWord container
openWakeWord Addon connected to HA instance running on Jetson using Wyoming protocol manually (auto-discovery still fails for some reason?)

@dusty-nv I don't want to block dev branch, so you can go with current, merged version which still works. This one I plan to finish in 1-2 days, before my bday trip to AMS.
Here I hope to get ha-core working with example add-on over wyoming and native auto-discovery in HA. Later I can describe it in docs, there are some caveats which we could discuss with HA Team.

OK, will do!  I also ordered some z-wave stuff today to try it with.  Hope you have fun on your birthday trip, perhaps the orin we sent will make an aptly time bday present! 😄

OK it built!, these images are now up:
dustynv/homeassistant-core:latest-r36.2.0
dustynv/homeassistant-core:latest-r35.4.1

dustynv/homeassistant-core:2024.4.2-r36.2.0
dustynv/homeassistant-core:2024.4.2-r35.4.1

Definitely @dusty-nv! 🙌 I saw the delivery receipt and the whole thing makes me happy ;) TY!
you know how it is - no man could ever say NO to more compute 😂🤓

Ok @dusty-nv it seems that everything is done here. Please treat that wyoming-openwakeword as example how to add other HA add-ons here as a compatible Jetson containers. I started with this one, because I'm using it in my Assist Pipeline configuration in Home Assistant.

Here's the output from the add-on after pairing with Home Assistant Instance:
wyoming-openwakeword console output

s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service openwakeword: starting
s6-rc: info: service openwakeword successfully started
s6-rc: info: service discovery: starting
DEBUG:root:Namespace(uri='tcp://<IP_ADDRESS>:10400', models_dir=PosixPath('/usr/local/lib/python3.11/dist-packages/wyoming_openwakeword/models'), custom_model_dir=['/share/openwakeword'], preload_model=['ok_nabu'], threshold=0.5, trigger_level=1, output_dir=None, debug=True, log_format='%(levelname)s:%(name)s:%(message)s', debug_probability=False, version=False, model=[])
DEBUG:root:Loading ok_nabu_v0.1 from /usr/local/lib/python3.11/dist-packages/wyoming_openwakeword/models/ok_nabu_v0.1.tflite
DEBUG:wyoming_openwakeword.handler:Started thread for ok_nabu_v0.1
DEBUG:root:Loading /usr/local/lib/python3.11/dist-packages/wyoming_openwakeword/models/melspectrogram.tflite
DEBUG:root:Loading /usr/local/lib/python3.11/dist-packages/wyoming_openwakeword/models/embedding_model.tflite
INFO:root:Ready
DEBUG:wyoming_openwakeword.handler:Client connected:<PHONE_NUMBER>132616
DEBUG:wyoming_openwakeword.handler:Client disconnected:<PHONE_NUMBER>132616
s6-rc: info: service discovery successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
DEBUG:wyoming_openwakeword.handler:Client connected:<PHONE_NUMBER>735951
DEBUG:wyoming_openwakeword.handler:Sent info to client:<PHONE_NUMBER>735951
DEBUG:wyoming_openwakeword.handler:Client disconnected:<PHONE_NUMBER>735951
DEBUG:wyoming_openwakeword.handler:Client connected:<PHONE_NUMBER>755228
DEBUG:wyoming_openwakeword.handler:Sent info to client:<PHONE_NUMBER>755228
DEBUG:wyoming_openwakeword.handler:Client disconnected:<PHONE_NUMBER>755228
DEBUG:wyoming_openwakeword.handler:Client connected:<PHONE_NUMBER>147158
DEBUG:wyoming_openwakeword.handler:Sent info to client:<PHONE_NUMBER>147158
DEBUG:wyoming_openwakeword.handler:Client disconnected:<PHONE_NUMBER>147158

Later, probably after our second Jetson AI Research Group online meeting I plan to add more add-on's to connect everything in a working Assist Pipeline:

homeassistant-core
wyoming-openwakeword
wyoming-whisper
etc...

Have fun everyone!

Awesome stuff @ms1design, I appreciate the level of detail required that you did here and got us started off in a good direction on this project 👍
dustynv/wyoming-openwakeword:r36.2.0 and dustynv/wyoming-openwakeword:r35.4.1 are now up, and dustynv/homeassistant-core was updated.  I made some minor tweaks but mostly kept everything the same as possible out of fear of breaking things 🤣

Thanks @dusty-nv, for update to keep this PR with the new approach:)
I noticed that you are linking:
RUN ln -s /data/homeassistant /config and also added a new command to jetson containers. Is that something like adding a volume using —build-arg?

@ms1design basically that sets the default config to be mounted under jetson-containers/data/homeassistant  (the /data dir is mounted by default by jetson-containers run aka run.sh)    this is consistent with all the other jetson-containers caching their data by default under there, then each user doesn't need to know the specifics.
However you can still override this of course by specifying --volume /my/homeassistant/config:/config when you start homeassistant-core (or like in your docker-compose)
And if user doesn't use jetson-containers run and doesn't manually specify the /config mount, then it will fall back to just creating the config inside the container.

Sounds reasonable, thanks for explanation @dusty-nv!


Modify validations behaviour

See ticket for changes need, they do a good job of explaining the issues this PR attempts to solve. There is also a list of form questions this is relevant to (basically they are date, financial info, personal details and previous award wins).
📝 A short description of the changes

If form starts off empty, then we don't add validation errors for all the inputs the user has not yet touched.
however, if we go back and delete an input, then it should show the validation error for that input.
If the user navigates between different steps of the form (using save or the navigation menu on the left) then all validation errors should show, as before. However, now the behaviour has changed to only remove validation errors for the inputs that the user has touched, not clearing them wholesale like before.

There are two main modes to understand when reviewing the code - @validate_only_touched_inputs will be false when navigating around the different form steps (because we want to validate everything) and will be true once they start to interact with the inputs on a form (since we only care about validating what they touch).
🔗 Link to the relevant story (or stories)

https://app.asana.com/0/1200504523179345/1207272963176223/f

:shipit: Deployment implications

Very little, this is just JS changes

✅ Checklist

[ ] Features that cannot go live are behind a feature flag/env var or specify deploy date and open PR as draft
[ ] I have checked that commit messages make sense and explain the reasoning for each change
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have squashed any unnecessary or part-finished commits

🖼 Screenshots (if appropriate - no PII/Prod data):

I like the fact that this is a JS change only, which means there should be little knock-on effects on updating the form in later workflow steps.


[ESP-WIFI-MESH] memory leak on IDF>=5.1.4 (IDFGH-12810)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
MESH:
1 fixed root and 2 nodes.
code doesn't do anything, it just starts the mesh
if I compile code on IDF 5.1.2 - there are no problems and no memory leaks!
if I compile code on IDF 5.1.4, 5.2 or 5.2.1 - a problem appears, on nodes a memory leak occurs approximately every 9 seconds:
on node 1(ESP32) - 124 bytes
on node 2(ESP32S3) - 128 bytes
1 sec timer for debug log:
void mem_print_heap(TimerHandle_t t)
{
	uint32_t heap_size;
	uint32_t min_heap_size;
	static int cnt = 0;

#ifndef CONFIG_ESP32S3_SPIRAM_SUPPORT
	heap_size = esp_get_free_heap_size();
	min_heap_size = esp_get_minimum_free_heap_size();
	MDF_LOGW("Free heap, curr: %lu, min: %lu", heap_size, min_heap_size);
#else
	heap_size = heap_caps_get_free_size(MALLOC_CAP_8BIT | MALLOC_CAP_INTERNAL);
	min_heap_size = heap_caps_get_minimum_free_size(MALLOC_CAP_8BIT | MALLOC_CAP_INTERNAL);
	MDF_LOGW("Free heap, curr: %lu, min: %lu, total curr: %lu, min: %lu", heap_size, min_heap_size, esp_get_free_heap_size(), esp_get_minimum_free_heap_size());
#endif /**< CONFIG_SPIRAM_SUPPORT */
	cnt++;
	if (cnt > 4) {
		esp_wifi_statis_dump(0xffff);
		cnt = 0;
	}
}

log for node 1:
log32-1.txt
after some time the memory returned (line 68) and the leak started again:
log32-2.txt
log without dump for node 2:
(S3 with SPIRAM), after a while I get the error:
W (1097142) wifi:m f null
logS3-1.txt
if at any time you turn off/on the power on the root(nodes are disconnected), then all memory returns on the all nodes:
logS3-2.txt
and the leakage process starts all over again.
sdkconfig32.txt
sdkconfigS3.txt

@habablaxe
Can this issue be reproduced using the IDF mesh example? Can you provide the log on IDF v5.1.2?

@zhangyanjiaoesp

Can this issue be reproduced using the IDF mesh example?

I haven’t tested it on a mesh example ((

Can you provide the log on IDF v5.1.2?

log32_5.1.2.txt
I'm using MDF(components mwifi and mupgrade only) and my code works with IDF 4.4.5, 5.0.3, 5.1, 5.1.1, 5.1.2. with uptime of more than several months
As a new release of the IDF version, I switch to it.
 We are exclusively using ESP32-S3 devices in our project, no mix.
In our case, we observe the following:

The mesh works for some time, then suddenly starts to leak memory in pieces of 128 bytes (the actual allocation seems to be 124 bytes however). I did not find out what the trigger is that causes the start of the memory leak.
Allocation seems to happen in ~10 seconds intervals.
We only observe this on non-root devices.
After some point, we observe W (2662884) wifi:m f null which I assume is a side-effect because the wifi cannot allocate memory anymore.

I tried to locate where the allocation is done using esp_backtrace_print, here is the stack trace:
W (113924) alloc: 0x3fcc7438 allocated 124 bytes

Backtrace: 0x403780AB:0x3FCD9680 0x40376A85:0x3FCD96A0 0x40376AE4:0x3FCD96C0 0x40377F95:0x3FCD96E0 0x421878D1:0x3FCD9700 0x40391E39:0x3FCD9730 0x400398B5:0x3FCD9760 0x421329F1:0x3FCD9780 0x4212F131:0x3FCD97A0 |<-CONTINUES
0x403780ab: esp_heap_trace_alloc_hook at .../firmware/main/main.c:367
0x40376a85: heap_caps_malloc_base at .../esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376ae4: heap_caps_malloc at .../esp-idf/components/heap/heap_caps.c:202
0x40377f95: esp_coex_common_malloc_internal_wrapper at .../esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x421878d1: esf_buf_alloc_dynamic at ??:?
0x40391e39: esf_buf_alloc at ??:?
0x400398b5: ic_ebuf_alloc in ROM
0x421329f1: ieee80211_getmgtframe at ??:?
0x4212f131: ieee80211_encap_null_data at ??:?

I (08:15:18.446) heap: free_internal_heap: 47191 bytes, delta: -128 bytes

FYI @KonssnoK

@zhangyanjiaoesp could you tell us when does the log wifi m f null is generated?

I'm currently using the esp-mesh ip_internal_network example and I actually have observed this same behaviour at the non root nodes from the mesh.  I'm monitoring the heap memory and using wifi_statis_dump(0xffff) as well, the nodes oftenly leaks memory, don't know exactly why. It seems that from time to time this leaked memory, is recovered, until it is not recovered anymore, then it keeps dropping until this warning "wifi: m f null" appears without signaling wifi disconnection, which is very strange, especially because it kept publishing on MQTT for a while after that (about 1 hour or even more) and after this warning the heap memory kept very constant without recoverying or dropping.

@zhangyanjiaoesp could you tell us when the log wifi m f null is generated?

When the null frame malloc fail, it will return m f null. Its possible causes are: slow packet sending; memory leak. I will check it.

I also tried to reproduce with the ip_internal_network example on a ESP32-S3 devkit, and this

It seems that from time to time this leaked memory, is recovered, until it is not recovered anymore, then it keeps dropping until this warning "wifi: m f null" appears without signaling wifi disconnection

exactly describes what I also observed.
Based on the logs, my assumption would be that the allocation is somehow related to the moment where this log
mesh: 5170<active>parent layer:1(node), channel:11, rssi:-8, assoc:1(cnx rssi threshold:-120)my_assoc:0 is printed.
In the below log we also see multiple allocations of 128 bytes that seem to get released after some time all together, however, sometimes this releasing mechanism seems not to work (and then we end up seeing the wifi: m f null log.
I (1135659) mesh: 5130<assoc>parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>
I (1182749) heap: free_internal_heap: 218063 bytes, delta: 0 bytes
I (1212829) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:10790ms, retries:1<>
I (1223879) mesh: 5170<active>parent layer:1(node), channel:11, rssi:-8, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (1223879) alloc: 0x3fcc9258 allocated 124 bytes

Backtrace: 0x40377097:0x3FCB3B80 0x403760E2:0x3FCB3BA0 0x40376109:0x3FCB3BD0 0x40378ECC:0x3FCB3BF0 0x420AF655:0x3FCB3C10 0x40385929:0x3FCB3C40 |<-CONTINUES
0x40377097: esp_heap_trace_alloc_hook at C:/repos/v3-5.2/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:469
0x403760e2: heap_caps_malloc_base at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376109: heap_caps_malloc at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:202
0x40378ecc: esp_coex_common_malloc_internal_wrapper at C:/repos/v3-5.2/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af655: esf_buf_alloc_dynamic at ??:?
0x40385929: esf_buf_alloc at ??:?

I (1224749) heap: free_internal_heap: 217935 bytes, delta: -128 bytes
W (1225399) alloc: 0x3fcc92d8 allocated 124 bytes

Backtrace: 0x40377097:0x3FCB3B30 0x403760E2:0x3FCB3B50 0x40376109:0x3FCB3B80 0x40378ECC:0x3FCB3BA0 0x420AF655:0x3FCB3BC0 0x40385929:0x3FCB3BF0 |<-CONTINUES
0x40377097: esp_heap_trace_alloc_hook at C:/repos/v3-5.2/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:469
0x403760e2: heap_caps_malloc_base at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376109: heap_caps_malloc at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:202
0x40378ecc: esp_coex_common_malloc_internal_wrapper at C:/repos/v3-5.2/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af655: esf_buf_alloc_dynamic at ??:?
0x40385929: esf_buf_alloc at ??:?

I (1225409) mesh: 5969<scan>parent layer:1, rssi:-6, assoc:1(cnx rssi threshold:-120)
I (1225419) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][ae:8b:a9:39:4e:83]<weak>
I (1225429) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (1225439) mesh: 716[monitor]no change, parent:7c:df:a1:e1:c9:e1, rssi:-6
I (1225439) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:7445ms, retries:2<>
I (1225749) heap: free_internal_heap: 217807 bytes, delta: -128 bytes
I (1233079) mesh: 5170<active>parent layer:1(node), channel:11, rssi:-8, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (1233079) alloc: 0x3fcc9358 allocated 124 bytes

Backtrace: 0x40377097:0x3FCB3B80 0x403760E2:0x3FCB3BA0 0x40376109:0x3FCB3BD0 0x40378ECC:0x3FCB3BF0 0x420AF655:0x3FCB3C10 0x40385929:0x3FCB3C40 |<-CONTINUES
0x40377097: esp_heap_trace_alloc_hook at C:/repos/v3-5.2/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:469
0x403760e2: heap_caps_malloc_base at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376109: heap_caps_malloc at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:202
0x40378ecc: esp_coex_common_malloc_internal_wrapper at C:/repos/v3-5.2/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af655: esf_buf_alloc_dynamic at ??:?
0x40385929: esf_buf_alloc at ??:?

I (1233749) heap: free_internal_heap: 217679 bytes, delta: -128 bytes
W (1234599) alloc: 0x3fcc93d8 allocated 124 bytes

Backtrace: 0x40377097:0x3FCB3B30 0x403760E2:0x3FCB3B50 0x40376109:0x3FCB3B80 0x40378ECC:0x3FCB3BA0 0x420AF655:0x3FCB3BC0 0x40385929:0x3FCB3BF0 |<-CONTINUES
0x40377097: esp_heap_trace_alloc_hook at C:/repos/v3-5.2/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:469
0x403760e2: heap_caps_malloc_base at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376109: heap_caps_malloc at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:202
0x40378ecc: esp_coex_common_malloc_internal_wrapper at C:/repos/v3-5.2/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af655: esf_buf_alloc_dynamic at ??:?
0x40385929: esf_buf_alloc at ??:?

I (1234609) mesh: 5969<scan>parent layer:1, rssi:-6, assoc:1(cnx rssi threshold:-120)
I (1234609) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][ae:8b:a9:39:4e:83]<weak>
I (1234619) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (1234629) mesh: 716[monitor]no change, parent:7c:df:a1:e1:c9:e1, rssi:-6
I (1234639) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:9006ms, retries:3<>
I (1234749) heap: free_internal_heap: 217551 bytes, delta: -128 bytes
I (1243869) mesh: 5170<active>parent layer:1(node), channel:11, rssi:-8, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (1243869) alloc: 0x3fcc9458 allocated 124 bytes

Backtrace: 0x40377097:0x3FCB3B80 0x403760E2:0x3FCB3BA0 0x40376109:0x3FCB3BD0 0x40378ECC:0x3FCB3BF0 0x420AF655:0x3FCB3C10 0x40385929:0x3FCB3C40 |<-CONTINUES
0x40377097: esp_heap_trace_alloc_hook at C:/repos/v3-5.2/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:469
0x403760e2: heap_caps_malloc_base at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376109: heap_caps_malloc at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:202
0x40378ecc: esp_coex_common_malloc_internal_wrapper at C:/repos/v3-5.2/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af655: esf_buf_alloc_dynamic at ??:?
0x40385929: esf_buf_alloc at ??:?

I (1244749) heap: free_internal_heap: 217423 bytes, delta: -128 bytes
W (1245389) alloc: 0x3fcc94d8 allocated 124 bytes

Backtrace: 0x40377097:0x3FCB3B30 0x403760E2:0x3FCB3B50 0x40376109:0x3FCB3B80 0x40378ECC:0x3FCB3BA0 0x420AF655:0x3FCB3BC0 0x40385929:0x3FCB3BF0 |<-CONTINUES
0x40377097: esp_heap_trace_alloc_hook at C:/repos/v3-5.2/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:469
0x403760e2: heap_caps_malloc_base at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376109: heap_caps_malloc at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:202
0x40378ecc: esp_coex_common_malloc_internal_wrapper at C:/repos/v3-5.2/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af655: esf_buf_alloc_dynamic at ??:?
0x40385929: esf_buf_alloc at ??:?

I (1245399) mesh: 5969<scan>parent layer:1, rssi:-6, assoc:1(cnx rssi threshold:-120)
I (1245409) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][ae:8b:a9:39:4e:83]<weak>
I (1245419) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (1245429) mesh: 716[monitor]no change, parent:7c:df:a1:e1:c9:e1, rssi:-6
I (1245429) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:409888ms, retries:3<>
I (1245749) heap: free_internal_heap: 218191 bytes, delta: 768 bytes
I (1260589) mesh: 5130<assoc>parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>

@zhangyanjiaoesp could you tell us when the log wifi m f null is generated?

When the null frame malloc fail, it will return m f null. Its possible causes are: slow packet sending; memory leak. I will check it.

thanks, we wait for updates then :)

@cbaechler @KonssnoK @habablaxe
When the device connects to mesh network, the non-root node will passively scan the current channel from time to time, and then select a better parent (if there is). In this process, the node will malloc memory to store AP information. After the parent node switch process is complete (continue with the current parent, or switch to a better one), the memory is released. I have checked the related code, it seems no problem. I think the m f null issue is not related to this.
I have tested with the ip_internal_network mesh example, and I didn't reproduce the m f null issue. Can you provide a demo for me to reproduce this issue?

Thanks for your comment.

the non-root node will passively scan the current channel from time to time

Does the timing match with what is reported in this ticket? Does the scanning happen every 9-10 seconds?

After the parent node switch process is complete (continue with the current parent, or switch to a better one), the memory is released.

I understand deallocation happens after some time based when the switch process is complete. For sure this works in all nominal cases. Still, do you see any possible chance that the free would not happen?

I have tested with the ip_internal_network mesh example, and I didn't reproduce the m f null issue. Can you provide a demo for me to reproduce this issue?

I think the m f null log might only be a side effect of what is happening, since basically it tells that the allocation failed. What I observed previously is the non-root device doing multiple allocations of 124 bytes (or 128 bytes) up to a point where the m f null appears due to exhausted heap memory.
I did not yet reproduce m f null in the ip_internal_network (but I did so with our own code, which uses more heap memory), however I did observe the multiple allocations behavior. I am still trying to reproduce it, one hope that have is to reproduce it by reducing the heap memory before even starting the mesh.
However, it seems @Cirobar has seen the m f null log in the ip_internal_network example (see https://github.com/espressif/esp-idf/issues/13786#issuecomment-2111025037). Maybe you can give more insights from your experience?

Does the timing match with what is reported in this ticket? Does the scanning happen every 9-10 seconds?

@cbaechler The scan interval has a short timer and a long timer, the short timer is random between 4.5s - 12.9s, and the long timer is random between 5min ~8min. Every three short intervals is followed by a long interval.

@zhangyanjiaoesp would have a way to do a diff between mesh implementation in 5.1.2 and 5.1.4 ?
The initial comment tells us that this issue was introduced at a specific point, so it would be quite easy to see if something related to memory management was changed for mesh libraries.

However, it seems @Cirobar has seen the m f null log in the ip_internal_network example (see #13786 (comment)). Maybe you can give more insights from your experience?

Well, I've managed to retrieve a captured log, but unfortunately at the time I wasn't using wifi_statis_dump() or heap tracing. Moreover, there is additional tasks running besides the ip_internal_network example tasks, none of them causes any kind of leak for sure. A cut of this log is attached below, since it is very extense. Anyway, the leakage can be seen as the tasks are printing the current heap memory. Also, as I've said before, the "wifi: m f null" warning happens often (not on every run of the app) and sometimes when it does actually happens, the application is not interrupted. One thing I've noticed is that when there is a very stable router or maybe the components are closer to the router, not sure yet of each one, the "wifi: m f null" may not happen at all.
esp32_nonroot_log.txt

@KonssnoK I will check the difference between 5.1.2 and 5.1.4.
@cbaechler Can you show me your test code for the following log？I know you used ip_internal_network example, but please tell me what changes you added. Thanks.

I (1135659) mesh: 5130parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>
I (1182749) heap: free_internal_heap: 218063 bytes, delta: 0 bytes
I (1212829) mesh: 2012parent monitor, my layer:2(cap:6)(node), interval:10790ms, retries:1<>
I (1223879) mesh: 5170parent layer:1(node), channel:11, rssi:-8, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (1223879) alloc: 0x3fcc9258 allocated 124 bytes
Backtrace: 0x40377097:0x3FCB3B80 0x403760E2:0x3FCB3BA0 0x40376109:0x3FCB3BD0 0x40378ECC:0x3FCB3BF0 0x420AF655:0x3FCB3C10 0x40385929:0x3FCB3C40 |<-CONTINUES
0x40377097: esp_heap_trace_alloc_hook at C:/repos/v3-5.2/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:469
0x403760e2: heap_caps_malloc_base at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376109: heap_caps_malloc at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:202
0x40378ecc: esp_coex_common_malloc_internal_wrapper at C:/repos/v3-5.2/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af655: esf_buf_alloc_dynamic at ??:?
0x40385929: esf_buf_alloc at ??:?
I (1224749) heap: free_internal_heap: 217935 bytes, delta: -128 bytes
W (1225399) alloc: 0x3fcc92d8 allocated 124 bytes
Backtrace: 0x40377097:0x3FCB3B30 0x403760E2:0x3FCB3B50 0x40376109:0x3FCB3B80 0x40378ECC:0x3FCB3BA0 0x420AF655:0x3FCB3BC0 0x40385929:0x3FCB3BF0 |<-CONTINUES
0x40377097: esp_heap_trace_alloc_hook at C:/repos/v3-5.2/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:469
0x403760e2: heap_caps_malloc_base at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376109: heap_caps_malloc at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:202
0x40378ecc: esp_coex_common_malloc_internal_wrapper at C:/repos/v3-5.2/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af655: esf_buf_alloc_dynamic at ??:?
0x40385929: esf_buf_alloc at ??:?
I (1225409) mesh: 5969parent layer:1, rssi:-6, assoc:1(cnx rssi threshold:-120)
I (1225419) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][ae:8b:a9:39:4e:83]
I (1225429) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (1225439) mesh: 716[monitor]no change, parent:7c:df:a1:e1:c9:e1, rssi:-6
I (1225439) mesh: 2012parent monitor, my layer:2(cap:6)(node), interval:7445ms, retries:2<>
I (1225749) heap: free_internal_heap: 217807 bytes, delta: -128 bytes
I (1233079) mesh: 5170parent layer:1(node), channel:11, rssi:-8, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (1233079) alloc: 0x3fcc9358 allocated 124 bytes
Backtrace: 0x40377097:0x3FCB3B80 0x403760E2:0x3FCB3BA0 0x40376109:0x3FCB3BD0 0x40378ECC:0x3FCB3BF0 0x420AF655:0x3FCB3C10 0x40385929:0x3FCB3C40 |<-CONTINUES
0x40377097: esp_heap_trace_alloc_hook at C:/repos/v3-5.2/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:469
0x403760e2: heap_caps_malloc_base at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376109: heap_caps_malloc at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:202
0x40378ecc: esp_coex_common_malloc_internal_wrapper at C:/repos/v3-5.2/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af655: esf_buf_alloc_dynamic at ??:?
0x40385929: esf_buf_alloc at ??:?
I (1233749) heap: free_internal_heap: 217679 bytes, delta: -128 bytes
W (1234599) alloc: 0x3fcc93d8 allocated 124 bytes
Backtrace: 0x40377097:0x3FCB3B30 0x403760E2:0x3FCB3B50 0x40376109:0x3FCB3B80 0x40378ECC:0x3FCB3BA0 0x420AF655:0x3FCB3BC0 0x40385929:0x3FCB3BF0 |<-CONTINUES
0x40377097: esp_heap_trace_alloc_hook at C:/repos/v3-5.2/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:469
0x403760e2: heap_caps_malloc_base at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376109: heap_caps_malloc at C:/repos/v3-5.2/esp-idf/components/heap/heap_caps.c:202
0x40378ecc: esp_coex_common_malloc_internal_wrapper at C:/repos/v3-5.2/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af655: esf_buf_alloc_dynamic at ??:?
0x40385929: esf_buf_alloc at ??:?

Hi @zhangyanjiaoesp,
these are the changes I applied to examples/mesh/ip_internal_network/main/mesh_main.c:
diff --git a/examples/mesh/ip_internal_network/main/mesh_main.c b/examples/mesh/ip_internal_network/main/mesh_main.c
index efa4f185a8..bee1873031 100644
--- a/examples/mesh/ip_internal_network/main/mesh_main.c
+++ b/examples/mesh/ip_internal_network/main/mesh_main.c
@@ -17,6 +17,8 @@
 #include "mesh_netif.h"
 #include "driver/gpio.h"
 #include "freertos/semphr.h"
+#include "esp_timer.h"
+#include "esp_debug_helpers.h"

 /*******************************************************
  *                Macros
@@ -33,7 +35,7 @@
  *                Constants
  *******************************************************/
 static const char *MESH_TAG = "mesh_main";
-static const uint8_t MESH_ID[6] = { 0x77, 0x77, 0x77, 0x77, 0x77, 0x76};
+static const uint8_t MESH_ID[6] = { 0xCB, 0xCB, 0xCB, 0xCB, 0xCB, 0x75};

 /*******************************************************
  *                Variable Definitions
@@ -46,6 +48,8 @@ static mesh_addr_t s_route_table[CONFIG_MESH_ROUTE_TABLE_SIZE];
 static int s_route_table_size = 0;
 static SemaphoreHandle_t s_route_table_lock = NULL;
 static uint8_t s_mesh_tx_payload[CONFIG_MESH_ROUTE_TABLE_SIZE*6+1];
+static bool enable_hook = false;
+static esp_timer_handle_t periodic_timer;

 /*******************************************************
@@ -148,6 +152,9 @@ void esp_mesh_mqtt_task(void *arg)
     mesh_data_t data;
     esp_err_t err;
     mqtt_app_start();
+
+    enable_hook = true;
+
     while (is_running) {
         asprintf(&print, "layer:%d IP:" IPSTR, esp_mesh_get_layer(), IP2STR(&s_current_ip));
         ESP_LOGV(MESH_TAG, "Tried to publish %s", print);
@@ -381,6 +388,21 @@ void ip_event_handler(void *arg, esp_event_base_t event_base,
     esp_mesh_comm_mqtt_task_start();
 }

+// called 1x per second
+static void on_timer(void* arg)
+{
+    static int count_heap_log = 0;
+    static int last_free_internal_heap = 0;
+    int free_internal_heap = esp_get_free_internal_heap_size();
+
+    if ((last_free_internal_heap != free_internal_heap) || (count_heap_log > 50)) {
+        ESP_LOGI("heap", "free_internal_heap: %d bytes, delta: %d bytes", free_internal_heap, free_internal_heap - last_free_internal_heap);
+        last_free_internal_heap = free_internal_heap;
+        count_heap_log = 0;
+    } else {
+        count_heap_log++;
+    }
+}

 void app_main(void)
 {
@@ -425,4 +447,36 @@ void app_main(void)
     ESP_ERROR_CHECK(esp_mesh_start());
     ESP_LOGI(MESH_TAG, "mesh starts successfully, heap:%" PRId32 ", %s",  esp_get_free_heap_size(),
              esp_mesh_is_root_fixed() ? "root fixed" : "root not fixed");
+
+    ESP_LOGI("heap", "free_internal_heap: %ld bytes before drain loop", esp_get_free_internal_heap_size());
+    while (esp_get_free_internal_heap_size() > 70000) {
+        void* mem = heap_caps_malloc(2048, MALLOC_CAP_INTERNAL);
+        if (!mem) {
+            ESP_LOGE(MESH_TAG, "Failed to alloc heap");
+            break;
+        }
+    }
+    ESP_LOGI("heap", "free_internal_heap: %ld bytes after drain loop", esp_get_free_internal_heap_size());
+
+    /* create timer to track heap */
+    const esp_timer_create_args_t periodic_timer_args = {
+        .callback = &on_timer,
+        .name = "periodic",
+    };
+
+    ESP_ERROR_CHECK(esp_timer_create(&periodic_timer_args, &periodic_timer));
+    ESP_ERROR_CHECK(esp_timer_start_periodic(periodic_timer, 1000000));
+}
+
+void esp_heap_trace_alloc_hook(void* ptr, size_t size, uint32_t caps)
+{
+    if (enable_hook) {
+        if ((caps & MALLOC_CAP_INTERNAL) != 0) {
+            if ((size == 124) || (size == 128)) {
+                ESP_EARLY_LOGW("alloc", "0x%08x allocated %d bytes", ptr, size);
+                // ESP_LOGW("alloc", "0x%08x allocated %d bytes", ptr, size);
+                esp_backtrace_print(5);
+            }
+        }
+    }
 }

Changes in sdkconfig are as follows, I enabled SPIRAM and configured allocations for wifi and mbedtls to happen on the external RAM in order to reduce allocations in the internal RAM:
CONFIG_PARTITION_TABLE_CUSTOM=y
CONFIG_COMPILER_OPTIMIZATION_SIZE=y
CONFIG_SPIRAM=y
CONFIG_SPIRAM_MODE_OCT=y
CONFIG_SPIRAM_SPEED_80M=y
CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL=2048
CONFIG_SPIRAM_TRY_ALLOCATE_WIFI_LWIP=y
CONFIG_ESP_WIFI_STATIC_RX_BUFFER_NUM=10
CONFIG_ESP_WIFI_RX_BA_WIN=6
CONFIG_FREERTOS_ENABLE_BACKWARD_COMPATIBILITY=y
CONFIG_HEAP_USE_HOOKS=y
CONFIG_LWIP_L2_TO_L3_COPY=y
CONFIG_LWIP_IP_FORWARD=y
CONFIG_LWIP_IPV4_NAPT=y
CONFIG_LWIP_TCP_MSS=624
CONFIG_LWIP_TCP_OOSEQ_MAX_PBUFS=4
CONFIG_MBEDTLS_EXTERNAL_MEM_ALLOC=y

Thank you!

@cbaechler @KonssnoK @Cirobar @habablaxe
Have test with the mesh example again, I can confirm that the 124 bytes is for the NULL data. The NULL data will be sent before scan start and after scan stop, and the scanning time is 1500ms. And the heap will be freed after the NULL data is sent out.
See the following logs:
The log I (19448) mesh: 5157<active>parent layer:1(node), channel:5, rssi:-8, assoc:0(cnx rssi threshold:-120)my_assoc:0 shows the scan will start, then the NULL data alloc 124 bytes, the pointer is 0x3fceca50, see log W (19478) alloc: 0x3fceca50 allocated 124 bytes. After it is sent out, the pointer is freed, see log W (19658) free: 0x3fceca50 free.
The log I (21038) mesh: 5948<scan>parent layer:1, rssi:-8, assoc:1(cnx rssi threshold:-120) shows the scan is stop, before it, the NULL data alloc 124 bytes, the pointer is still 0x3fceca50, after it is sent out, the pointer is freed.
The scanning time is 21038-19478 = 1560ms.
Because the number of memory can be applied for NULL data is limited, and the length of TX queue is limited, if there are too many  packets to be sent in the TX queue, and the surrounding environment is poor ,it's difficult to send packets, the applied memory can't be freed in time, then m f null will occur.  That's why @Cirobar  say  One thing I've noticed is that when there is a very stable router or maybe the components are closer to the router, not sure yet of each one, the "wifi: m f null" may not happen at all. in https://github.com/espressif/esp-idf/issues/13786#issuecomment-2123311395.
And there is no different between 5.1.2 and 5.1.4 in handling this.
I (18338) mesh_main: Received Routing table [0] 84:f7:03:80:01:88
I (18338) mesh_main: Received Routing table [1] 84:f7:03:80:01:40
I (18508) mesh_main: Tried to publish layer:2 IP:<IP_ADDRESS>
I (18518) mesh_mqtt: sent publish returned msg_id=26502
I (18798) mesh_mqtt: MQTT_EVENT_PUBLISHED, msg_id=26502
I (19448) mesh: 5157<active>parent layer:1(node), channel:5, rssi:-8, assoc:0(cnx rssi threshold:-120)my_assoc:0
>>>pm_off_channel,1317
>>>pm_send_nullfunc,997
>>>ieee80211_pm_tx_null_process,5444
>>>ieee80211_encap_null_data,5373
>>>esf_buf_alloc,274, type = 3, len = 24
>>>esf_buf_alloc_dynamic,134, type = 3, all = 124(96+24+0+4)
W (19478) alloc: 0x3fceca50 allocated 124 bytes

Backtrace: 0x403787D7:0x3FCB4F50 0x40376545:0x3FCB4F70 0x403765A5:0x3FCB4F90 0x40377295:0x3FCB4FB0 0x403773A9:0x3FCB5040 0x4037A201:0x3FCB5060 0x420BF316:0x3FCB5080 0x40385D0A:0x3FCB50C0 0x400398B5:0x3FCB50F0 |<-CORRUPTED
0x403787d7: esp_heap_trace_alloc_hook at /home/zhangyanjiao/work/code/idf1/examples/mesh/ip_internal_network/main/mesh_main.c:480 (discriminator 3)
0x40376545: heap_caps_malloc_base at /home/zhangyanjiao/work/code/idf1/components/heap/heap_caps.c:178 (discriminator 1)
0x403765a5: heap_caps_malloc at /home/zhangyanjiao/work/code/idf1/components/heap/heap_caps.c:197
0x40377295: trace_malloc at /home/zhangyanjiao/work/code/idf1/components/heap/include/heap_trace.inc:95
0x403773a9: __wrap_heap_caps_malloc at /home/zhangyanjiao/work/code/idf1/components/heap/include/heap_trace.inc:184
0x4037a201: esp_coex_common_malloc_internal_wrapper at /home/zhangyanjiao/work/code/idf1/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420bf316: esf_buf_alloc_dynamic at ??:?
0x40385d0a: esf_buf_alloc at ??:?
0x400398b5: ic_ebuf_alloc in ROM

W (19658) free: 0x3fceca50 free

Backtrace: 0x40378819:0x3FCB51D0 0x40376792:0x3FCB51F0 0x403772DB:0x3FCB5210 0x4037735D:0x3FCB5260 0x40385739:0x3FCB5280 0x420BFB61:0x3FCB52A0 0x40385381:0x3FCB52C0 0x403808D5:0x3FCB52F0
0x40378819: esp_heap_trace_free_hook at /home/zhangyanjiao/work/code/idf1/examples/mesh/ip_internal_network/main/mesh_main.c:492 (discriminator 3)
0x40376792: heap_caps_free at /home/zhangyanjiao/work/code/idf1/components/heap/heap_caps.c:390 (discriminator 1)
0x403772db: trace_free at /home/zhangyanjiao/work/code/idf1/components/heap/include/heap_trace.inc:119
0x4037735d: __wrap_free at /home/zhangyanjiao/work/code/idf1/components/heap/include/heap_trace.inc:164
0x40385739: esf_buf_recycle at ??:?
0x420bfb61: ppProcTxDone at ??:?
0x40385381: ppTask at ??:?
0x403808d5: vPortTaskWrapper at /home/zhangyanjiao/work/code/idf1/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162

I (19978) heap: free_internal_heap: 42411 bytes, delta: -36 bytes
I (20518) mesh_main: Tried to publish layer:2 IP:<IP_ADDRESS>
I (20518) mesh_main: Received Routing table [0] 84:f7:03:80:01:88
I (20518) mesh_main: Received Routing table [1] 84:f7:03:80:01:40
I (20518) mesh_mqtt: sent publish returned msg_id=2430
I (20788) mesh_mqtt: MQTT_EVENT_PUBLISHED, msg_id=2430
>>>pm_send_nullfunc,997
>>>ieee80211_pm_tx_null_process,5444
>>>ieee80211_encap_null_data,5373
>>>esf_buf_alloc,274, type = 3, len = 24
>>>esf_buf_alloc_dynamic,134, type = 3, all = 124(96+24+0+4)
W (21008) alloc: 0x3fceca50 allocated 124 bytes

Backtrace: 0x403787D7:0x3FCB4F30 0x40376545:0x3FCB4F50 0x403765A5:0x3FCB4F70 0x40377295:0x3FCB4F90 0x403773A9:0x3FCB5020 0x4037A201:0x3FCB5040 0x420BF316:0x3FCB5060 0x40385D0A:0x3FCB50A0 0x400398B5:0x3FCB50D0 |<-CORRUPTED
0x403787d7: esp_heap_trace_alloc_hook at /home/zhangyanjiao/work/code/idf1/examples/mesh/ip_internal_network/main/mesh_main.c:480 (discriminator 3)
0x40376545: heap_caps_malloc_base at /home/zhangyanjiao/work/code/idf1/components/heap/heap_caps.c:178 (discriminator 1)
0x403765a5: heap_caps_malloc at /home/zhangyanjiao/work/code/idf1/components/heap/heap_caps.c:197
0x40377295: trace_malloc at /home/zhangyanjiao/work/code/idf1/components/heap/include/heap_trace.inc:95
0x403773a9: __wrap_heap_caps_malloc at /home/zhangyanjiao/work/code/idf1/components/heap/include/heap_trace.inc:184
0x4037a201: esp_coex_common_malloc_internal_wrapper at /home/zhangyanjiao/work/code/idf1/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420bf316: esf_buf_alloc_dynamic at ??:?
0x40385d0a: esf_buf_alloc at ??:?
0x400398b5: ic_ebuf_alloc in ROM

I (21038) mesh: 5948<scan>parent layer:1, rssi:-8, assoc:1(cnx rssi threshold:-120)

W (21038) free: 0x3fceca50 free

Backtrace: 0x40378819:0x3FCB51D0 0x40376792:0x3FCB51F0 0x403772DB:0x3FCB5210 0x4037735D:0x3FCB5260 0x40385739:0x3FCB5280 0x420BFB61:0x3FCB52A0 0x40385381:0x3FCB52C0 0x403808D5:0x3FCB52F0
0x40378819: esp_heap_trace_free_hook at /home/zhangyanjiao/work/code/idf1/examples/mesh/ip_internal_network/main/mesh_main.c:492 (discriminator 3)
0x40376792: heap_caps_free at /home/zhangyanjiao/work/code/idf1/components/heap/heap_caps.c:390 (discriminator 1)
0x403772db: trace_free at /home/zhangyanjiao/work/code/idf1/components/heap/include/heap_trace.inc:119
0x4037735d: __wrap_free at /home/zhangyanjiao/work/code/idf1/components/heap/include/heap_trace.inc:164
0x40385739: esf_buf_recycle at ??:?
0x420bfb61: ppProcTxDone at ??:?
0x40385381: ppTask at ??:?
0x403808d5: vPortTaskWrapper at /home/zhangyanjiao/work/code/idf1/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:162

I (21068) mesh: [SCAN][ch:5]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][ac:84:c6:7e:31:2b]<weak>
I (21078) mesh: 7370[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (21088) mesh: 716[monitor]no change, parent:84:f7:03:80:01:89, rssi:-8
I (21088) mesh: 2004<arm>parent monitor, my layer:2(cap:6)(node), interval:7359ms, retries:2<>
I (22528) mesh_main: Tried to publish layer:2 IP:<IP_ADDRESS>
I (22548) mesh_main: Received Routing table [0] 84:f7:03:80:01:88
I (22548) mesh_main: Received Routing table [1] 84:f7:03:80:01:40
I (22578) mesh_mqtt: sent publish returned msg_id=16618
I (22848) mesh_mqtt: MQTT_EVENT_PUBLISHED, msg_id=16618
I (24568) mesh_main: Received Routing table [0] 84:f7:03:80:01:88
I (24568) mesh_main: Received Routing table [1] 84:f7:03:80:01:40
I (24578) mesh_main: Tried to publish layer:2 IP:<IP_ADDRESS>
I (24588) mesh_mqtt: sent publish returned msg_id=56594

hello @zhangyanjiaoesp , thanks for the answer.
The issue we see dries up the whole heap without releasing, we'll try to stress out the example more to replicate

@zhangyanjiaoesp i'm using the same code that @cbaechler gave.
you said that such allocations should be freed as soon as the packet is sent the second time, but in my logs i do not see such thing.
am i missing something?

I (1191289) mesh: 5969<scan>parent layer:1, rssi:-6, assoc:1(cnx rssi threshold:-120)
I (1191289) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][d2:0f:7d:8a:8b:29]<weak>
I (1191299) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (1191309) mesh: 716[monitor]no change, parent:7c:df:a1:e2:a3:05, rssi:-6
I (1191319) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:317426ms, retries:3<>
I (1191539) heap: free_internal_heap: 47023 bytes, delta: -128 bytes
I (1243539) heap: free_internal_heap: 47023 bytes, delta: 0 bytes
I (1257479) mesh: 5130<assoc>parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>
I (1295539) heap: free_internal_heap: 47023 bytes, delta: 0 bytes
I (1347539) heap: free_internal_heap: 47023 bytes, delta: 0 bytes
I (1382399) mesh: 5130<assoc>parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>
I (1399539) heap: free_internal_heap: 47023 bytes, delta: 0 bytes
I (1451539) heap: free_internal_heap: 47023 bytes, delta: 0 bytes
I (1503539) heap: free_internal_heap: 47023 bytes, delta: 0 bytes
I (1506299) mesh: 5130<assoc>parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>
I (1516369) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:6082ms, retries:1<>
I (1522599) mesh: 5170<active>parent layer:1(node), channel:11, rssi:-7, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (1522599) alloc: 0x3fcaa530 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB3010 0x40375FEE:0x3FCB3030 0x40376015:0x3FCB3060 0x40378D88:0x3FCB3080 0x420AF6A1:0x3FCB30A0 0x40384EF1:0x3FCB30D0 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (1523539) heap: free_internal_heap: 46895 bytes, delta: -128 bytes
W (1524119) alloc: 0x3fcaa5b0 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB2FC0 0x40375FEE:0x3FCB2FE0 0x40376015:0x3FCB3010 0x40378D88:0x3FCB3030 0x420AF6A1:0x3FCB3050 0x40384EF1:0x3FCB3080 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (1524129) mesh: 5969<scan>parent layer:1, rssi:-8, assoc:1(cnx rssi threshold:-120)
I (1524139) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][d2:0f:7d:8a:8b:29]<weak>
I (1524149) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (1524159) mesh: 716[monitor]no change, parent:7c:df:a1:e2:a3:05, rssi:-8
I (1524159) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:11346ms, retries:2<>
I (1524539) heap: free_internal_heap: 46767 bytes, delta: -128 bytes
I (1535789) mesh: 5170<active>parent layer:1(node), channel:11, rssi:-7, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (1535789) alloc: 0x3fcaa630 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB3010 0x40375FEE:0x3FCB3030 0x40376015:0x3FCB3060 0x40378D88:0x3FCB3080 0x420AF6A1:0x3FCB30A0 0x40384EF1:0x3FCB30D0 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (1536539) heap: free_internal_heap: 46639 bytes, delta: -128 bytes
W (1537309) alloc: 0x3fcaa6b0 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB2FC0 0x40375FEE:0x3FCB2FE0 0x40376015:0x3FCB3010 0x40378D88:0x3FCB3030 0x420AF6A1:0x3FCB3050 0x40384EF1:0x3FCB3080 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (1537319) mesh: 5969<scan>parent layer:1, rssi:-8, assoc:1(cnx rssi threshold:-120)
I (1537329) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][d2:0f:7d:8a:8b:29]<weak>
I (1537339) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (1537349) mesh: 716[monitor]no change, parent:7c:df:a1:e2:a3:05, rssi:-8
I (1537349) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:6840ms, retries:3<>
I (1537539) heap: free_internal_heap: 46511 bytes, delta: -128 bytes
I (1544369) mesh: 5170<active>parent layer:1(node), channel:11, rssi:-7, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (1544369) alloc: 0x3fcaa730 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB3010 0x40375FEE:0x3FCB3030 0x40376015:0x3FCB3060 0x40378D88:0x3FCB3080 0x420AF6A1:0x3FCB30A0 0x40384EF1:0x3FCB30D0 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (1544539) heap: free_internal_heap: 46383 bytes, delta: -128 bytes
W (1545889) alloc: 0x3fcaa7b0 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB2FC0 0x40375FEE:0x3FCB2FE0 0x40376015:0x3FCB3010 0x40378D88:0x3FCB3030 0x420AF6A1:0x3FCB3050 0x40384EF1:0x3FCB3080 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (1545899) mesh: 5969<scan>parent layer:1, rssi:-8, assoc:1(cnx rssi threshold:-120)
I (1545899) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][d2:0f:7d:8a:8b:29]<weak>
I (1545919) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (1545919) mesh: 716[monitor]no change, parent:7c:df:a1:e2:a3:05, rssi:-8
I (1545929) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:418063ms, retries:3<>
I (1546539) heap: free_internal_heap: 46255 bytes, delta: -128 bytes
I (1598539) heap: free_internal_heap: 46255 bytes, delta: 0 bytes
I (1631219) mesh: 5130<assoc>parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>
I (1650539) heap: free_internal_heap: 46255 bytes, delta: 0 bytes
I (1687539) heap: free_internal_heap: 46191 bytes, delta: -64 bytes
I (1688539) heap: free_internal_heap: 46255 bytes, delta: 64 bytes
I (1740539) heap: free_internal_heap: 46255 bytes, delta: 0 bytes
I (1756149) mesh: 5130<assoc>parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>
I (1792539) heap: free_internal_heap: 46255 bytes, delta: 0 bytes
I (1844539) heap: free_internal_heap: 46255 bytes, delta: 0 bytes
I (1881069) mesh: 5130<assoc>parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>
I (1896539) heap: free_internal_heap: 46255 bytes, delta: 0 bytes
I (1948539) heap: free_internal_heap: 46255 bytes, delta: 0 bytes
I (1974039) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:11011ms, retries:1<>
I (1985309) mesh: 5170<active>parent layer:1(node), channel:11, rssi:-7, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (1985309) alloc: 0x3fcaa830 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB3010 0x40375FEE:0x3FCB3030 0x40376015:0x3FCB3060 0x40378D88:0x3FCB3080 0x420AF6A1:0x3FCB30A0 0x40384EF1:0x3FCB30D0 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (1985539) heap: free_internal_heap: 46127 bytes, delta: -128 bytes
W (1986829) alloc: 0x3fcaa8b0 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB2FC0 0x40375FEE:0x3FCB2FE0 0x40376015:0x3FCB3010 0x40378D88:0x3FCB3030 0x420AF6A1:0x3FCB3050 0x40384EF1:0x3FCB3080 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (1986839) mesh: 5969<scan>parent layer:1, rssi:-8, assoc:1(cnx rssi threshold:-120)
I (1986849) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][d2:0f:7d:8a:8b:29]<weak>
I (1986859) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (1986869) mesh: 716[monitor]no change, parent:7c:df:a1:e2:a3:05, rssi:-8
I (1986869) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:6182ms, retries:2<>
I (1987539) heap: free_internal_heap: 45999 bytes, delta: -128 bytes
I (1993209) mesh: 5170<active>parent layer:1(node), channel:11, rssi:-7, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (1993219) alloc: 0x3fcaa930 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB3010 0x40375FEE:0x3FCB3030 0x40376015:0x3FCB3060 0x40378D88:0x3FCB3080 0x420AF6A1:0x3FCB30A0 0x40384EF1:0x3FCB30D0 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (1993539) heap: free_internal_heap: 45871 bytes, delta: -128 bytes
W (1994729) alloc: 0x3fcaa9b0 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB2FC0 0x40375FEE:0x3FCB2FE0 0x40376015:0x3FCB3010 0x40378D88:0x3FCB3030 0x420AF6A1:0x3FCB3050 0x40384EF1:0x3FCB3080 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (1994739) mesh: 5969<scan>parent layer:1, rssi:-8, assoc:1(cnx rssi threshold:-120)
I (1994749) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][d2:0f:7d:8a:8b:29]<weak>
I (1994759) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (1994769) mesh: 716[monitor]no change, parent:7c:df:a1:e2:a3:05, rssi:-8
I (1994779) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:8874ms, retries:3<>
I (1995539) heap: free_internal_heap: 45743 bytes, delta: -128 bytes
I (2003869) mesh: 5170<active>parent layer:1(node), channel:11, rssi:-7, assoc:1(cnx rssi threshold:-120)my_assoc:0
W (2003869) alloc: 0x3fcaaa30 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB3010 0x40375FEE:0x3FCB3030 0x40376015:0x3FCB3060 0x40378D88:0x3FCB3080 0x420AF6A1:0x3FCB30A0 0x40384EF1:0x3FCB30D0 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (2004539) heap: free_internal_heap: 45615 bytes, delta: -128 bytes
W (2005389) alloc: 0x3fcaaab0 allocated 124 bytes

Backtrace: 0x40376FA3:0x3FCB2FC0 0x40375FEE:0x3FCB2FE0 0x40376015:0x3FCB3010 0x40378D88:0x3FCB3030 0x420AF6A1:0x3FCB3050 0x40384EF1:0x3FCB3080 |<-CONTINUES
0x40376fa3: esp_heap_trace_alloc_hook at C:/src/esp-idf/examples/mesh/ip_internal_network/main/mesh_main.c:478
0x40375fee: heap_caps_malloc_base at C:/src/esp-idf/components/heap/heap_caps.c:183 (discriminator 1)
0x40376015: heap_caps_malloc at C:/src/esp-idf/components/heap/heap_caps.c:202
0x40378d88: esp_coex_common_malloc_internal_wrapper at C:/src/esp-idf/components/esp_coex/esp32s3/esp_coex_adapter.c:128
0x420af6a1: esf_buf_alloc_dynamic at ??:?
0x40384ef1: esf_buf_alloc at ??:?

I (2005399) mesh: 5969<scan>parent layer:1, rssi:-8, assoc:1(cnx rssi threshold:-120)
I (2005409) mesh: [SCAN][ch:11]AP:1, other(ID:0, RD:0), MAP:1, idle:0, candidate:1, root:1, topMAP:0[c:2,i:2][d2:0f:7d:8a:8b:29]<weak>
I (2005419) mesh: 7391[weak]try rssi_threshold:-120, backoff times:0, max:5<-78,-82,-85>
I (2005429) mesh: 716[monitor]no change, parent:7c:df:a1:e2:a3:05, rssi:-8
I (2005429) mesh: 2012<arm>parent monitor, my layer:2(cap:6)(node), interval:301974ms, retries:3<>
I (2005539) heap: free_internal_heap: 45487 bytes, delta: -128 bytes
I (2005989) mesh: 5130<assoc>parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>
I (2057539) heap: free_internal_heap: 45487 bytes, delta: 0 bytes
I (2109539) heap: free_internal_heap: 45487 bytes, delta: 0 bytes
I (2129899) mesh: 5130<assoc>parent layer:1, channel:11, rssi:-5, assoc:1, rssi threshold<-78,-82,-85>
I (2161539) heap: free_internal_heap: 45487 bytes, delta: 0 bytes

@KonssnoK you need to add a esp_heap_trace_free_hook() function to show the free trace. Here is my code, just for test.
static uint32_t *alloc_ptr = NULL;
void esp_heap_trace_alloc_hook(void* ptr, size_t size, uint32_t caps)
{
    if (enable_hook) {
        if ((caps & MALLOC_CAP_INTERNAL) != 0) {
            if ((size == 124) || (size == 128)) {
                ESP_EARLY_LOGW("alloc", "0x%08x allocated %d bytes", ptr, size);
                // ESP_LOGW("alloc", "0x%08x allocated %d bytes", ptr, size);
                alloc_ptr = ptr;
                esp_backtrace_print(15);
            }
        }
    }
}

void esp_heap_trace_free_hook(void* ptr)
{
    if (enable_hook) {
        if (alloc_ptr == ptr) {
            ESP_EARLY_LOGW("free", "0x%08x free", ptr);
            alloc_ptr = NULL;
            esp_backtrace_print(15);
        }
    }
}

@zhangyanjiaoesp i do have the free hook, it's just not called.
Or better, it is called after a very long time for all the previous allocations, which is strange.
the log above starts from 49+ kB of free memory, then the 128B start consuming the memory, until at 42kB of heap 6k are released

I (1987539) heap: free_internal_heap: 45999 bytes, delta: -128 bytes

I (3778539) heap: free_internal_heap: 42159 bytes, delta: -128 bytes

the thing is you have at least 3785539 - 1987539 = 180000 ms between them
I (3785539) heap: free_internal_heap: 49071 bytes, delta: 6912 bytes
W (3786519) alloc: 0x3fca9d30 allocated 124 bytes

@KonssnoK I didn't see so long delay on my side, it may related to the test environment, do you have many WiFi packets in your testing environment？And it may related to the busy state of the wifi task (When the data is sent out, hardware will post event to wifi task, wifi task also need to handle TX/RX event). You can capture packets to see if the NULL data has been sent out.

Current tests are based on commit f8319f08cca75236c29eecfce01886a671f4fc17.
Today I tried to change the test environment, but I can still reproduce. I used the phone as a WIFI hotspot with only those two devkits connected to it. Also, we are able to reproduce the behavior in two geographically different locations, for this reason I think it is unrelated to the environment.

I let the system run for ~2 hours to collect some data. The following plot shows the memory consumption over time:

We can observe the following:

Big junk of allocations happen every 5-8 minutes, which seems to be in-line with the scan interval long timer (see https://github.com/espressif/esp-idf/issues/13786#issuecomment-2122465641)
Around t=1300 sec, the system manages to release some previously allocated memory
After this, it continues to allocate, but it does not release until t=7200 sec, where it releases all the memory at once
Finally, after this big release it did not start to drain again

For reference, I also attach the raw monitor output:
240529_GH_13786_log.txt
Also here, the setup is built with 2x ESP32-S3 DevKit-C connected to the phone hotspot (no other devices connected to the same access point).

@cbaechler @KonssnoK please test using the following wifi lib.
wifi_lib_esp32s3_5.2.zip
wifi firmware version: 770b98c

@cbaechler @KonssnoK please test using the following wifi lib.
wifi_lib_esp32s3_5.2.zip wifi firmware version: 770b98c

Hi @zhangyanjiaoesp , i think we'll be able to test tomorrow. We'll update asap.

@zhangyanjiaoesp thanks for the wifi lib. I gave it a quick try and was not able to reproduce the issue up to now.
Actually, I do no longer see any of the 124 bytes allocations, thus I assume you are allocating this memory statically? Can you describe in more detail what the changes in the lib are?
Thank you!

@cbaechler We cancelled the sending of the null data.

@cbaechler We cancelled the sending of the null data.

so we can confirm that the temporary memory consumption issue is created by that data 🤔
how do we proceed?

@KonssnoK I think the debug log in https://github.com/espressif/esp-idf/issues/13786#issuecomment-2126383430 has confirm the 124 bytes allocation is the NULL data. And after modifying the wifi code, the 124 bytes allocation on longer be seen (https://github.com/espressif/esp-idf/issues/13786#issuecomment-2141401082). Is this evidence not sufficient enough?

@KonssnoK I think the debug log in #13786 (comment) has confirm the 124 bytes allocation is the NULL data. And after modifying the wifi code, the 124 bytes allocation on longer be seen (#13786 (comment)). Is this evidence not sufficient enough?

yes sure it's enough to know that is the allocation. My question was more about : what do we do next? :)
What is this NULL data used for? Is it necessary?
If yes, does it need to be reintroduced and changed so that the free is called in a timely manner 🤔 ?
If not, will it be removed from the main branch?
Thanks!

@KonssnoK The NULL data is not necessary for mesh, and we will remove it from the main branch and other release branches.

@zhangyanjiaoesp ok thanks!

@KonssnoK The NULL data is not necessary for mesh, and we will remove it from the main branch and other release branches.

will this already be fixed in release 5.2.2?

@habablaxe The fix will be merged in release/v5.2, the stable version should be v5.2.3.

@cbaechler We cancelled the sending of the null data.

@zhangyanjiaoesp
Since v5.1.2 was fine, there must be some reason to add sending the null data in newer esp-idf versions.
I'm curious what's the purpose of sending the null data?

@AxelLin The v5.1.2 also will send the null data, it's not a recent addition.

@AxelLin The v5.1.2 also will send the null data, it's not a recent addition.

I don't get it.
Form you description, stop sending NULL data fixed the issue.
Then why it was working fine in v5.1.2?

@AxelLin @habablaxe
In my test, there is no difference in v5.1.2 and v5.1.4, and the alloc buffer can be freed in time. ( https://github.com/espressif/esp-idf/issues/13786#issuecomment-2126383430). You can provide a demo for me to test.

@AxelLin @habablaxe In my test, there is no difference in v5.1.2 and v5.1.4, and the alloc buffer can be freed in time. ( #13786 (comment)). You can provide a demo for me to test.

So you just confirmed the memory is allocated by sending NULL data but still don't know why the memory is not freed in time in https://github.com/espressif/esp-idf/issues/13786#issuecomment-2137635396.
And your fix is stop sending NULL data ?

@zhangyanjiaoesp

no difference in v5.1.2 and v5.1.4,

this was the reason why I opened this issue.
on versions <=5.1.2 everything is fine,
on versions >=5.1.3 there is a memory leak

@AxelLin @habablaxe In my test, there is no difference in v5.1.2 and v5.1.4, and the alloc buffer can be freed in time. ( #13786 (comment)). You can provide a demo for me to test.

So you just confirmed the memory is allocated by sending NULL data but still don't know why the memory is not freed in time in #13786 (comment). And your fix is stop sending NULL data ?
(It's probably ok if null data is not necessary for MESH. But I feel you didn't figure out the root cause for free memory in time.)

When the scan starts, if the device switches to another channel, it will send NULL data to the AP. But in this mesh case, the device only scan on the current channel, so NULL data is not necessary. So my fix is to stop sending NULL data. It can be seen as a workaround.
If you can provide a demo for me to reproduce the memory leak issue, I will continue to debugging on it.


Bug in pre commit hook

If there is nothing to stash, the pre commit hook will unstash existing stash.
This is usually not the case since there is usually pending changes to be committed, but can happen during a commit amend.

Stash in pre-commit hook has been removed in 57a4d905bc4251569b7f5590e20db234166654cc.


Kind column on package listing page

A UX review of Flutter plugins (https://flutter.io/platform-plugins/) found that it was difficult from the packages listing page (https://pub.dartlang.org/packages) to tell if they were Dart packages or Flutter plugins.
It would be helpful to add a 'kind' column that indicated this to the LHS of each row, probably with either the Dart or Flutter logo.

cc @mit-mit

There is now a https://pub.dartlang.org/flutter/plugins page.
@isoos Though I think we could for all package lists show the detectedType icon on the left side of the name (i.e. on /packages, /, ...). wdyt?

Yes, this would be a great addition for those cases where developers click away from the /flutter/plugins page and up on the regular packages pages.

@kevmoo would be even greater if we could detect 'web only' packages (maybe those that depend on dart:html?), and show a web icon for those?

@mkustermann I was thinking similarly, left side sounds good.
I think there is no need for a column header, because if there are no icons, we want that column to be thin/disappear.

@isoos The icons vary in size on different pages thanks to the img{max-width: 100%} rule. See:
https://pub.dartlang.org/flutter/plugins?page=1
https://pub.dartlang.org/flutter/plugins?page=2
Easy fix: Add .tablecol-icons-img { max-width: unset }.


Cannot use positional argument after named argument at 04:04:13

Hi,
At first I like to say I love your Video an learn a lot of things.
But now I have a Problem.
With your Video I like to create a Youtubeclon for myself. Till now I can solve every Problem by myself. But now at 04:04:13 I have a Problem i can´t solve by myself.
If I write this code:
   return $this->render(view: 'view',
   ['model' => $video
]);

like you explaind, it will create that error: Cannot use positional argument after named argument
I think it will be a Problem with PHP8 and some new features, but I didn´t know what I can do to solve it.
Maybe you can help me, please.
Greets gismo2005

I can solve the Problem.


[e2e]: nodejs release main default slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/5935103988
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.nodejs.release.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.nodejs.release.main.default.slsa3.yml
Trigger: schedule
Branch: main
Date: Tue Aug 22 06:09:31 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/v40.0.70
Run: https://github.com/slsa-framework/example-package/actions/runs/5947677259
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.nodejs.release.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.nodejs.release.main.default.slsa3.yml
Trigger: release
Branch: v40.0.70
Date: Wed Aug 23 06:16:22 UTC 2023
Tests are passing now. Closing this issue.