[Webkit-unassigned] [Bug 184039] webkitpy: Implement coredumpctl support on linux

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Mar 28 23:54:27 PDT 2018


Daniel Bates <dbates at webkit.org> changed:

           What    |Removed                     |Added
                 CC|                            |dbates at webkit.org
 Attachment #336581|review?                     |review-
              Flags|                            |

--- Comment #3 from Daniel Bates <dbates at webkit.org> ---
Comment on attachment 336581
  --> https://bugs.webkit.org/attachment.cgi?id=336581

View in context: https://bugs.webkit.org/attachment.cgi?id=336581&action=review

> Tools/Scripts/webkitpy/port/linux_get_crash_log.py:32
> +import datetime

Not in sorted order. Please sort all the  import lines suchthat they are in sorted order according to the UNIX sort tool.

> Tools/Scripts/webkitpy/port/linux_get_crash_log.py:60
> +        for ntry in range(5):

This is a suboptimal way to loop as we malloc a list. What does ntry stand for? Did you mean to write retries?

> Tools/Scripts/webkitpy/port/linux_get_crash_log.py:62
> +                # Loopping, it means we conceder the logs might not be ready

Please remove this comment as it is redundant given the comment on line 59. Also, I am surprised we don’t have a convenience function in webktpy to do waiting for us.

> Tools/Scripts/webkitpy/port/linux_get_crash_log.py:64
> +                time.sleep(1)

Is there not a more direct way to know if systemd generating the backtrack so we can avoid busy waiting?

> Tools/Scripts/webkitpy/port/linux_get_crash_log.py:67
> +                info = subprocess.check_output(['coredumpctl', 'info',

Can we write this logic using the Executive object? Can this class take an Executive object in its constructor?

> Tools/Scripts/webkitpy/port/linux_get_crash_log.py:71
> +                # The trace might not be ready yet

:( Can we find a more deterministic and direct way to test this. Writing code that sleeps and hopes the data becomes available when we wake artificially slows down testing.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180329/fc580f55/attachment-0001.html>

More information about the webkit-unassigned mailing list