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

Fix stall after resizing LMDB #1619

Closed
wants to merge 1 commit into from
Closed

Fix stall after resizing LMDB #1619

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Jan 23, 2017

No idea why this works, but my stall error (#1595) is fixed by changing all instances of LOG_PRINT_L3 to MDEBUG in /cryptonote_core/blockchain.cpp

Also took the opportunity to change LOG_ERROR messages to MERROR

…cryptonote_core/blockchain.cpp

Also changed LOG_ERRORs to MERROR
@moneromooo-monero
Copy link
Collaborator

If you change the L3, they should be MTRACE. They'll swamp the debug level otherwise.
You should find what the problem is in the first place anyway, this is just poking the thing until it doesn't fall over. Again, if you get a deadlock, look at the stack trace to see what deadlocks.

@ghost
Copy link
Author

ghost commented Jan 23, 2017

Will change and try to keep analysing

@moneromooo-monero
Copy link
Collaborator

In particular, check what LOG_PRINT_Lx get changed to. The changes you made should be noop.
Also you can run with valgrind to see if there's previous memory corruption.

@ghost
Copy link
Author

ghost commented Jan 23, 2017

How do I use valgrind?

@moneromooo-monero
Copy link
Collaborator

Instead of running "X", you run "valgrind X". It'll be slow.

@ghost
Copy link
Author

ghost commented Jan 23, 2017

Debug build or normal build?

@moneromooo-monero
Copy link
Collaborator

Whichever you are seeing the problems with should be fine.

@ghost
Copy link
Author

ghost commented Jan 24, 2017

Can you tell me how to check if the changes I made were noop?

@moneromooo-monero
Copy link
Collaborator

Well... that's not super easy. If you knew how to use makefiles, you could add -E to the GCC commands and avoid linking, then you'd get preprocessed files as objects, which you could diff. Otherwise, well.. it should behave the same :) There's a chance the binaries would be the same, though those things probably contain timestamps etc so that probably doesn't help in practice.

@ghost
Copy link
Author

ghost commented Jan 30, 2017

I think @moneromooo-monero figured out a solution by changing mutex for recursive_mutex...just testing. Closing this one in favour.

@ghost ghost closed this Jan 30, 2017
@ghost ghost deleted the Fix_stall branch February 3, 2017 20:17
This pull request was closed.
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

Successfully merging this pull request may close these issues.

None yet

1 participant