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

ipykernel: Introspector build failure/timeout #9914

Closed
jesslatimer opened this issue Mar 13, 2023 · 9 comments
Closed

ipykernel: Introspector build failure/timeout #9914

jesslatimer opened this issue Mar 13, 2023 · 9 comments
Assignees

Comments

@jesslatimer
Copy link
Contributor

The introspector build for ipykernel fails every so often with TIMEOUT ERROR: context deadline exceeded

@DavidKorczynski DavidKorczynski self-assigned this Mar 13, 2023
@jonathanmetzman
Copy link
Contributor

compilation is literally taking almost 20 hours(!!!) when this happens

@oliverchang
Copy link
Collaborator

@DavidKorczynski are there any fixes possible here? OR should we just disable this one?

@DavidKorczynski
Copy link
Collaborator

I think we can solve this -- am in the process of debugging this and will update here shortly.

DavidKorczynski referenced this issue in AdaLogics/PyCG Mar 29, 2023
DavidKorczynski added a commit that referenced this issue Mar 30, 2023
This change includes:
- bug fixes for #9914
- bug fixes for overall coverage calculation in python projects. This is
  the issue mentioned here:
#9957 (comment) At
this stage fuzz introspector should give a more accurate overview of
"how much coverage does the fuzzers have" than the code coverage reports
itself due to the nature of python coverage, as described in the above
comment
- updates on the java frontend that makes it possible to refine which
  java code to analyse
- updates to the output `.json` of fuzz introspector which will enable
  us to solve the issues mentioned here:
https://github.com/google/oss-fuzz/blob/9fc6c644b93b90415a6111fdbea027be701337ae/infra/build/build_status/fuzz_introspector_page_gen.py#L250-L253

Signed-off-by: David Korczynski <[email protected]>
oliverchang pushed a commit that referenced this issue Apr 6, 2023
This change includes:
- bug fixes for #9914
- bug fixes for overall coverage calculation in python projects. This is
the issue mentioned here:
#9957 (comment) At
this stage fuzz introspector should give a more accurate overview of
"how much coverage does the fuzzers have" than the code coverage reports
itself due to the nature of python coverage, as described in the above
comment
- updates on the java frontend that makes it possible to refine which
java code to analyse
- updates to the output `.json` of fuzz introspector which will enable
us to solve the issues mentioned here:
https://github.com/google/oss-fuzz/blob/9fc6c644b93b90415a6111fdbea027be701337ae/infra/build/build_status/fuzz_introspector_page_gen.py#L250-L253

---------

Signed-off-by: David Korczynski <[email protected]>
@evverx
Copy link
Contributor

evverx commented Apr 20, 2023

@DavidKorczynski I noticed that scapy is built successfully with FI now. Could it be that 4f10812 fixed it too? According to AdaLogics/PyCG@507c89d#r106590415

the converging will not happen in the usual manner

Could you expand on that a bit?

@evverx
Copy link
Contributor

evverx commented May 7, 2023

I played with it a bit and it seems it works in practice. Admittedly I use it to look for large uncovered chunks and maybe if I needed more granular results it would be a different story but I haven't reached that point yet :-)

@DavidKorczynski
Copy link
Collaborator

@DavidKorczynski I noticed that scapy is built successfully with FI now. Could it be that 4f10812 fixed it too? According to AdaLogics/PyCG@507c89d#r106590415

the converging will not happen in the usual manner

Could you expand on that a bit?

Sorry for missing this @evverx -- I will expand shortly!

@evverx
Copy link
Contributor

evverx commented May 7, 2023

@DavidKorczynski no problem. I was just wondering whether that change could affect my local stuff and I haven't noticed any significant coverage drops. It's just that scapy stopped timing out and it drew my attention. Its report contains "The number of runtime covered functions are larger than the number of reachable functions" though and my guess would be that it has something to do with various meta-programming techniques used there but I have to admit I haven't taken a close look yet. I'll open a separate issue if I've gotten round to it.

@DavidKorczynski
Copy link
Collaborator

@evverx in that case, then yes that change is likely the cause of having no more timeouts.
I left a comment with more notes on the commit: AdaLogics/PyCG@507c89d#r112363177

The The number of runtime covered functions are larger than the number of reachable functions primarily happens because of limitations in the the control-flow analysis of Python. Sometimes I find places this can be improved, but I think it's likely that there will be inherent limitations to it, and in particular in python, until we solve bulletpoint 2 in ossf/fuzz-introspector#4 (comment)

@DavidKorczynski
Copy link
Collaborator

Closing as ipykernel has had no timeouts in a while

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

5 participants