-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash(Assertion failure) when opening large data #629
Comments
If we have a recording with the following layout: A B C where A: part where function f is accessed B: list samples C: part where function g is accessed then f won't have the lost events cost while g does. This will cause a crash when the model tries to access it fixes: #629
If we have a recording with the following layout: A B C where A: part where function f is accessed B: list samples C: part where function g is accessed then f won't have the lost events cost while g does. This will cause a crash when the model tries to access it fixes: #629
Hi, Can you try again with that version to see if it fixed the bug? |
Hi, thanks for your fix. I can confirm that the bug is fixed by your PR. |
If we have a recording with the following layout: A B C where A: part where function f is accessed B: list samples C: part where function g is accessed then f won't have the lost events cost while g does. This will cause a crash when the model tries to access it. This patch replaces the typedef ItemCost with a real wrapper that will catch the out range access. fixes: #629
If we have a recording with the following layout: A B C where A: part where function f is accessed B: list samples C: part where function g is accessed then f won't have the lost events cost while g does. This will cause a crash when the model tries to access it. This patch replaces the typedef ItemCost with a real wrapper that will catch the out range access. fixes: #629
If we have a recording with the following layout: A B C where A: part where function f is accessed B: list samples C: part where function g is accessed then f won't have the lost events cost while g does. This will cause a crash when the model tries to access it. This patch replaces the typedef ItemCost with a real wrapper that will catch the out range access. fixes: #629
If we have a recording with the following layout: A B C where A: part where function f is accessed B: list samples C: part where function g is accessed then f won't have the lost events cost while g does. This will cause a crash when the model tries to access it. This patch replaces the typedef ItemCost with a real wrapper that will catch the out range access. fixes: #629
If we have a recording with the following layout: A B C where A: part where function f is accessed B: list samples C: part where function g is accessed then f won't have the lost events cost while g does. This will cause a crash when the model tries to access it. This patch replaces the typedef ItemCost with a real wrapper that will catch the out range access. fixes: #629
If we have a recording with the following layout: A B C where A: part where function f is accessed B: list samples C: part where function g is accessed then f won't have the lost events cost while g does. This will cause a crash when the model tries to access it. This patch replaces the typedef ItemCost with a real wrapper that will catch the out range access. fixes: #629
If we have a recording with the following layout: A B C where A: part where function f is accessed B: lost samples C: part where function g is accessed then f won't have the lost events cost while g does. This will cause a crash when the model tries to access it. This patch replaces the typedef ItemCost with a real wrapper that will catch the out range access. fixes: #629
If we have a recording with the following layout: A B C where A: part where function f is accessed B: lost samples C: part where function g is accessed then f won't have the lost events cost while g does. This will cause a crash when the model tries to access it. This patch replaces the typedef ItemCost with a real wrapper that will catch the out range access. fixes: #629
Describe the bug
hotspot crashed when opening a very large data file(1.72GB).
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Version Info (please complete the following information):
Linux spectre 6.8.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 28 Apr 2024 15:59:47 +0000 x86_64 GNU/Linux
Additional context
hotspot.log
Thanks for creating such a nice tool for analyzing performance. I really love using it. Large files are usually difficult to handle in GUI applications, which I think is what this bug reveals.
hotspot_crash.data is saved by cargo-flamegraph command.
It is attached here in a zstd compressed form. Due to github's limitation, it is again compressed with gzip before uploading:
hotspot_crash.data.zst.gz
The text was updated successfully, but these errors were encountered: