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.

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

Segmentation fault during --stop #30

Closed
mathbunnyru opened this issue Jan 14, 2020 · 9 comments
Closed

Segmentation fault during --stop #30

mathbunnyru opened this issue Jan 14, 2020 · 9 comments

Comments

@mathbunnyru
Copy link
Contributor

Unfortunately, when using with our project, I get Segmentation fault (core dumped) during --stop.
I could provide you with the data you need, but I don't exactly know what to attach.

Our project is quite small - less than 100K LOC, number of files is not big either.

I noticed in htop, that the utility starts to use a lot of RAM, maybe this could help.

@mathbunnyru mathbunnyru changed the title Segmentation fault Segmentation fault during --stop Jan 14, 2020
@mathbunnyru
Copy link
Contributor Author

I think it would be useful to have the ability to easily build with sanitizer, for example.

@aras-p
Copy link
Owner

aras-p commented Jan 19, 2020

I could provide you with the data you need, but I don't exactly know what to attach.

The .json files from under artifacts path would help.

@mathbunnyru
Copy link
Contributor Author

mathbunnyru commented Jan 21, 2020

Nope, I think the problem is that you allocate a lot of memory and don't deallocate it. I deleted Allocator.cpp and now I get:

asalikhov@vm-dol-asalikhov-u18:~/ClangBuildAnalyzer/build$ ./ClangBuildAnalyzer --stop ~/twix/build/ capture_file
Stopping build tracing and saving to 'capture_file'...
done in 477.4s. Run 'ClangBuildAnalyzer --analyze capture_file' to analyze it.

Yes, it took some time, but it did work!
Virtual memory was around 12G.

If you don't mind, I propose to delete Allocator.cpp. But maybe you could tell why having it may be useful.

@aras-p
Copy link
Owner

aras-p commented Jan 21, 2020

The "never deallocate anything" is on purpose, so that it's faster :) The actual question is, why it needs that many gigabytes to allocate. Perhaps I should try to reduce the memory consumption somehow. But for that having the .json files that cause this much memory usage would be useful.

@mathbunnyru
Copy link
Contributor Author

mathbunnyru commented Jan 21, 2020

I see your point. I would like to ask you to take a look at this issue: #33

If you add useful logging, I will understand which file takes the longest to finish.

The utility is great and I'm happy that I was able to use it with deleting Allocator.cpp, but let's make it better. I would gladly send you several .json files which take too much time, but I do have to take a look at them to see that they don't have some sensitive info. That's why I created the new issue.

@mathbunnyru
Copy link
Contributor Author

Unfortunately, the project I'm using your utility on is private, so I cannot easily just send you all the json files, sorry for that :(

@aras-p
Copy link
Owner

aras-p commented Mar 2, 2020

@mathbunnyru I did a bunch of changes (memory handling, threading, ...) that made the thing 2x faster, use 10x less memory and the data file is 4x smaller in my tests, see #37 -- plan to merge it to master branch soon.

@mathbunnyru
Copy link
Contributor Author

Nice to hear, thank you, @aras-p !

I will check if the issue is gone after merge to master and will close it then.

@mathbunnyru
Copy link
Contributor Author

No crashes anymore! Thank you once again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants