Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Crash(Assertion failure) when opening large data #629

Closed
kxxt opened this issue May 3, 2024 · 2 comments · Fixed by #636 · May be fixed by #632
Closed

Crash(Assertion failure) when opening large data #629

kxxt opened this issue May 3, 2024 · 2 comments · Fixed by #636 · May be fixed by #632
Labels
bug

Comments

@kxxt
Copy link

kxxt commented May 3, 2024

Describe the bug
hotspot crashed when opening a very large data file(1.72GB).

To Reproduce
Steps to reproduce the behavior:

hotspot hotspot_crash.data &> ~/hotspot.log

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 Kernel version: Linux spectre 6.8.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 28 Apr 2024 15:59:47 +0000 x86_64 GNU/Linux
  • perf version: perf version 6.7-3
  • hotspot version (appimage? selfcompiled?): 1.4.80 from chaotic-aur (package version 20240412-1)
  • if self-compiled hotspot, what version of elfutils:

Additional context

unhandled event type 13   unknown type
/usr/include/c++/13.2.1/valarray:588: const _Tp& std::valarray<_Tp>::operator[](std::size_t) const [with _Tp = long long int; std::size_t = long unsigned int]: Assertion '__i < this->size()' failed.
zsh: IOT instruction (core dumped)  hotspot hotspot_crash.data

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
@kxxt kxxt added the bug label May 3, 2024
lievenhey added a commit that referenced this issue May 13, 2024
@lievenhey
fix: crash if samples have different amount of costs associated
1255426 
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
@lievenhey lievenhey mentioned this issue May 13, 2024
Merged
lievenhey added a commit that referenced this issue May 13, 2024
@lievenhey
fix: crash if samples have different amount of costs associated
93ec535 
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
@lievenhey
Copy link
Contributor

Hi,
thanks for finding this bug. I hope I have found the issue. I was able to open your dump with the following appimage.

Can you try again with that version to see if it fixed the bug?

@kxxt
Copy link
Author

kxxt commented May 13, 2024

Hi, thanks for finding this bug. I hope I have found the issue. I was able to open your dump with the following appimage.

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.

lievenhey added a commit that referenced this issue May 16, 2024
@lievenhey
fix: add a wrapper for std::valarray to catch out of range access
b3f5224 
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
lievenhey added a commit that referenced this issue May 16, 2024
@lievenhey
fix: add a wrapper for std::valarray to catch out of range access
f63d01f 
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
lievenhey added a commit that referenced this issue May 16, 2024
@lievenhey
fix: add a wrapper for std::valarray to catch out of range access
b695535 
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
lievenhey added a commit that referenced this issue May 16, 2024
@lievenhey
fix: add a wrapper for std::valarray to catch out of range access
96603d4 
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
lievenhey added a commit that referenced this issue May 16, 2024
@lievenhey
fix: add a wrapper for std::valarray to catch out of range access
637a8d7 
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
lievenhey added a commit that referenced this issue May 17, 2024
@lievenhey
fix: add a wrapper for std::valarray to catch out of range access
6f289bd 
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
lievenhey added a commit that referenced this issue May 17, 2024
@lievenhey
fix: add a wrapper for std::valarray to catch out of range access
58fba35 
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
milianw pushed a commit that referenced this issue May 23, 2024
@lievenhey @milianw
fix: add a wrapper for std::valarray to catch out of range access
d8de369 
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
@github-actions github-actions bot mentioned this issue May 23, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
2 participants
@kxxt @lievenhey