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

Added error log tab in debug window #466

Merged
merged 7 commits into from
May 30, 2019
Merged

Conversation

mxaddict
Copy link
Contributor

@mxaddict mxaddict commented May 4, 2019

Added error log tab in debug window that parses last 500 debug.log entries for errors and loads more errors as they come in while debugwindow is open

…tries for errors and loads more errors as they come in while debugwindow is open
…og entries since the last time Debug Window was opened
@mxaddict
Copy link
Contributor Author

mxaddict commented May 6, 2019

@aguycalled @craigmacgregor This PR is ready for review, I have added the new error.log support and optimized the Debug Window code to not lock up the wallet.

@aguycalled
Copy link
Member

I'm not sure if filtering which entries should go to the error log by trying to find a string ('ERROR') is the right approach.

Using error() vs LogPrint* to decide on where should it be logged looks like a more efficient, elegant and future-prone solution.

Thoughts?

@mxaddict
Copy link
Contributor Author

mxaddict commented May 7, 2019

I'm not sure if filtering which entries should go to the error log by trying to find a string ('ERROR') is the right approach.

Using error() vs LogPrint* to decide on where should it be logged looks like a more efficient, elegant and future-prone solution.

Thoughts?

Agreed, I will make the change now.

@mxaddict
Copy link
Contributor Author

mxaddict commented May 7, 2019

I'm not sure if filtering which entries should go to the error log by trying to find a string ('ERROR') is the right approach.

Using error() vs LogPrint* to decide on where should it be logged looks like a more efficient, elegant and future-prone solution.

Thoughts?

I've pushed the changes, waiting on travis 😄

@proletesseract
Copy link
Member

Is there some way to generate errors which will display in the error tab so i can test this is working?

@mxaddict
Copy link
Contributor Author

mxaddict commented May 9, 2019

Is there some way to generate errors which will display in the error tab so i can test this is working?

I just add a error("test") call to the init, compiled then checked the error log :D

@mxaddict
Copy link
Contributor Author

@aguycalled were you able to test a node running this?

Copy link
Member

@aguycalled aguycalled left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tested debian

Copy link
Member

@proletesseract proletesseract left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when i start with a blank data directory immediately errors are generated when it can't open the peers.dat and banlist.dat files and i see them in the debug console tab.

I have tested this on ubuntu and it works for me there.

@proletesseract
Copy link
Member

approved, waiting for travis to complete then will merge

@mxaddict
Copy link
Contributor Author

Looks like changes to QT version on master branch break this PR, I will fix the branch now

@mxaddict
Copy link
Contributor Author

@proletesseract I've made the changes to fix the QT dependency issue, Build should pass now 👍

@mxaddict
Copy link
Contributor Author

@proletesseract tests passed, merging 👍

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

Successfully merging this pull request may close these issues.

None yet

3 participants