Skip to content
This repository has been archived by the owner on Dec 14, 2021. It is now read-only.

blocks after Finished Loading, probably because of many errors #287

Closed
payload opened this issue Jan 12, 2017 · 9 comments
Closed

blocks after Finished Loading, probably because of many errors #287

payload opened this issue Jan 12, 2017 · 9 comments
Assignees

Comments

@payload
Copy link

payload commented Jan 12, 2017

Coati version 0.10.0
I tried Coati on the project apitrace.
Indexing takes about 7 minutes.
Coati tells me the project has 19381 errors (47 fatal).
But apitrace is also a complicated project ;)

After indexing tells it is finished Coati is unresponsive and appears blocked for another couple of minutes.

After reopening the Coati apitrace project I get the status message "Finished Loading" but Coati is unresponsive and appears blocked for another couple of minutes.

I straced file accesses by Coati and noted that during the phase of being unresponsive,
Coati opens data/gui/indexing_dialog/error.png about 19377 times.
I guess there are problems in error message handling at GUI side which makes Coati unresponsive.

@mlangkabel
Copy link
Contributor

It looks like our QT GUI takes a loot of time to display all those errors. We'll set up a test project and investigate. Thanks a lot for reporting this one!

@egraether egraether added the bug label Jan 16, 2017
@egraether
Copy link
Contributor

Might be fixable by reusing the loaded error.png

@wrongway88
Copy link
Contributor

Gonna reduce the number of displayed code snippets to a reasonable amount, that should further reduce (well, hopefully eliminate) the issue of too many errors locking up the UI.

@wrongway88 wrongway88 self-assigned this Feb 3, 2017
@egraether
Copy link
Contributor

Reuse same error icon for all rows in the error table with 0.10.74

@egraether
Copy link
Contributor

@payload are you still experiencing these issues with our latest release?

@payload
Copy link
Author

payload commented May 22, 2017

Sourcetrail 0.12.25 hangs on 99% of indexing apitrace (retrace_stdc.cpp). Maybe it finishes, but it takes a lot more than 7 minutes.

Don't know what is happening. Strace shows a continously incrementing loop of recvmsg calls (note 240, 241, ...)

[pid 7700] recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\240o\0\0\0\0\325\0\0\0.\344\306\1\24\3\340\1\24\3\340\1\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
[pid 7700] recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\241o\0\0\0\0\325\0\0\0.\344\306\1\24\3\340\1\24\3\340\1\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
[pid 7700] recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\242o\0\0\0\0\325\0\0\0.\344\306\1\24\3\340\1\24\3\340\1\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
[pid 7700] recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\243o\0\0\0\0\325\0\0\0.\344\306\1\24\3\340\1\24\3\340\1\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
[pid 7700] recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\244o\0\0\0\0\325\0\0\0.\344\306\1\24\3\340\1\24\3\340\1\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
[pid 7700] recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\245o\0\0\0\0\325\0\0\0.\344\306\1\24\3\340\1\24\3\340\1\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
[pid 7700] recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\246o\0\0\0\0\325\0\0\0.\344\306\1\24\3\340\1\24\3\340\1\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
[pid 7700] recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\247o\0\0\0\0\325\0\0\0.\344\306\1\24\3\340\1\24\3\340\1\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
[pid 7700] recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\250o\0\0\0\0\325\0\0\0.\344\306\1\24\3\340\1\24\3\340\1\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32

After lot of time the Finish indexing window appeared, but strace still shows the slow recvmsg loop.

@payload
Copy link
Author

payload commented May 22, 2017

Please git clone apitrace and try to index it :)

@egraether
Copy link
Contributor

egraether commented May 22, 2017

I had a look and I'm also running into the 99% problem. This is caused by the really large file retrace/glretrace_wgl_font_outlines.cpp. When all other files already finished indexing, Sourcetrail still needs to wait for that one. If you set Indexer Threads in Sourcetrail's preferences to 1 you will see that indexing gets stuck for a while on that file.

Then, while browsing the project, I quickly realized this was not the only huge file. There are several more within the build directory. They caused massive performance problems within the code view, especially in single file mode, or when a symbol was referenced a lot in one of these big files. It kind of seemed to work in snippet mode, but nonetheless this is not a nice user experience, I opened #389.

But other than that project setup works fine and without any errors for me.

For reference:
I could build apitrace without trouble and exported compile_commands.json for Sourcetrail:

git clone https://github.com/apitrace/apitrace.git
cd apitrace/
cmake -H. -Bbuild -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_EXPORT_COMPILE_COMMANDS=true -DCMAKE_PREFIX_PATH=<Qt_Dir>/5.8/clang_64
make -C build

I then used project setup from Compilation Database with the exported compile_commands.json and added the apitrace root directory to Indexed Header Paths. Indexing took 5:34 on my laptop, 7:47 when using only 1 indexer thread:

463 files
632870 lines of code

67518 symbols
316506 relations

0 errors (0 fatal)

@egraether
Copy link
Contributor

No update in 3 months, closing now.

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

No branches or pull requests

4 participants