Replies: 4 comments 3 replies
-
|
I'm not sure I have a clear picture of what you are trying to accomplish here. Regarding memory exhaustion:
Are you trying to identify where the library is allocating memory? Recall that there are two kinds of memory in XS - slots and chunks.
|
Beta Was this translation helpful? Give feedback.
-
|
Super helpful, thank you! I'll take advantage of those As for the crash being reproducible, it's 100% consistent for me. However, my setup is rather complex (and Windows) and would not be easy to reproduce at your location. I'm open to setting up a session (Zoom, whatever) at any time that might fit your team's schedule (if interested). I can also be your remote hands and, given guidance, add debugging lines or anything else you suggest and provide feedback. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks - remote debugging of these things is generally challenging. It is a problem that the heap is in a bad state though. Let's figure out a solution because it would be a shame to lose a reproducible test case. (While I don't run Windows these days, other members of the team do, so a Windows-only way to reproduce the problem is fine.) |
Beta Was this translation helpful? Give feedback.
-
|
I came up with a way to export my setup, based on taking the This private repo has @phoddie's email as an admin. If you need somebody else added, just let me know. Setup steps
"wifi": {
"ssid": "YOUR_SSID",
"password": "YOUR_PASSWORD"
},
Running
I hope this will reproduce for you. Let me know if you get any other errors, as it's difficult for me to prove I've fully isolated everything from my environment! Good luck, and thanks for the help. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome. Thanks for putting this together. Will give a try in the next day or two. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Closing a Peter and team have found and fixed the issue. Thanks! |
Beta Was this translation helpful? Give feedback.
-
Hi - I've been working with a third-party library (@nats-io/nats.js) that requires allocating an excessive amount of chuck and heap space (around 150K) for it to work. On each call I make to
natsin my test I callDebug.gc()and then get/log theInstrumentationvalues. I never exceed 12K of the total space required. I know it may be making allocations and then releasing them before the individual call is over, so I've added debug code throughout their code to identify large allocations (buffers, arrays, objects, excessive heap usage, large strings, etc). I found and fixed a few places but have yet to find anything to explain this behavior.So my first question is: Do you happen to have any tricks or hints to find where these allocations are happening?
One thing I find surprising is that when I run this with a chunk space 5 times larger (50K) but still under the 100K (where it does work), it crashes in xsMemory.c:1355:
It crashes the windows simulator with no information, but on instrumented ESP32 I get the GDC output and can see the crash.
It is included here if interested:
GDB crash output
This leads to my second question: Should I expect this type of crash, or would you have expected it to give an out-of-heap/chunk/stack error (which I normally see when I exceed my limits)?
I'm not looking to ask for help finding the root cause, but I would appreciate any tricks on finding these allocations, and your thoughts on if the crash is expected behavior or perhaps it's a smoking gun that might provide some clues. Thanks!
Beta Was this translation helpful? Give feedback.
All reactions