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

Track / monitor test failures and core dump in FileWidget #835

Open
ntoll opened this issue Feb 28, 2020 · 2 comments
Open

Track / monitor test failures and core dump in FileWidget #835

ntoll opened this issue Feb 28, 2020 · 2 comments

Comments

@ntoll
Copy link
Contributor

ntoll commented Feb 28, 2020

This issue has been created to track random crashes in the test suite when exercising event_filter method of FileWidget. The original comment left in the code on that method is:

        # HERE BE DRAGONS.
        # The checks for "not self.downloading" in the following lines of code
        # probably look strange. The obvious thing to do is to wrap such a
        # check as a conditional. However, for reasons that are not entirely
        # clear, this regularly caused random crashes when running the test
        # suite (on Ubuntu 18.04, Python3.7). The following code expresses the
        # same logic but without causing the random the crash of the test
        # suite.
        if t == QEvent.HoverEnter and not self.downloading:
            self.download_button.setIcon(load_icon('download_file_hover.svg'))
        elif t == QEvent.HoverLeave and not self.downloading:
            self.download_button.setIcon(load_icon('download_file.svg'))
        return QObject.event(obj, event)
@ntoll
Copy link
Contributor Author

ntoll commented Feb 28, 2020

Ref #792 for context.

@gonzalo-bulnes
Copy link
Contributor

gonzalo-bulnes commented Jun 7, 2022

Taking a mental note of this because I noticed that the FileWidget's test suite may be destroying QThread instances without stopping the thread first. That typically results in a Python core dump.

I don't know if the crashes you observed @ntoll are related to that, but I'm planning on addressing the thread management issue. (See #1510)

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