unexpected EOF error for empty python files #184

Activity

1. creachadair commented on Mar 18, 2019

   

   creachadair

   on Mar 18, 2019

   Contributor

   More actions

   I tried to reproduce this in the driver:

   $ docker exec -it srcd-cli-bblfshd touch /tmp/empty.py
   $ docker exec -it srcd-cli-bblfshd bblfshctl parse --address=localhost:9432 /tmp/empty.py
   Status: Ok
   Elapsed: 15.2µs

   That would suggest this is downstream of the driver—but if you include the --native flag it generates a JSON error, so I'm not sure this is the whole story.

   @dennwc am I doing something wrong here?
2. bzz commented on Mar 19, 2019

   

   bzz

   on Mar 19, 2019

   Last edited by bzz

   Contributor

   More actions

   @creachadair Interesting find with --native! For some reason was not able to reproduce it using bblfsh-cli.

   To reproduce this on latest master, similar to https://github.com/bblfsh/bblfshd/issues/266#issuecomment-474314324 do:

   wget https://raw.githubusercontent.com/src-d/apollo/master/apollo/__init__.py
   
   bblfsh-cli __init__.py
    couldn't parse __init__.py: unexpected EOF
   bblfsh-cli -m annotated __init__.py
    couldn't parse __init__.py: unexpected EOF
   bblfsh-cli -m native __init__.py
    couldn't parse __init__.py: unexpected EOF
   

   logs

   [2019-03-19T12:33:30+01:00] DEBUG empty request received, returning empty UAST
   [2019-03-19T12:33:30+01:00] DEBUG request processed content 0 bytes elapsed=426.484µs filename=__init__.py
   [2019-03-19T12:33:39+01:00] DEBUG empty request received, returning empty UAST
   [2019-03-19T12:33:39+01:00] DEBUG request processed content 0 bytes elapsed=336.058µs filename=__init__.py
   [2019-03-19T12:33:44+01:00] DEBUG empty request received, returning empty UAST
   [2019-03-19T12:33:44+01:00] DEBUG request processed content 0 bytes elapsed=217.685µs filename=__init__.py
   

   While running only on latest python driver:

   docker run --rm -it -p 9432:9432 bblfsh/python-driver:v2.8.1
   bblfsh-cli __init__.py
   
   syntax error: Traceback (most recent call last):
     File "/opt/driver/bin/.local/lib/python3.6/site-packages/python_driver/requestprocessor.py", line 177, in process_request
       if failed:
   UnboundLocalError: local variable 'failed' referenced before assignment
   
   

   If no objections, going to move it to python-driver and handle it from there as part of the next release scope https://github.com/bblfsh/python-driver/milestone/1
3. bzz

   transferred this issue frombblfsh/bblfshdon Mar 19, 2019
4. bzz

   added

   bug

   on Mar 19, 2019
5. bzz

   added this to the v2.8.2 milestone on Mar 19, 2019
6. creachadair commented on Mar 21, 2019

   

   creachadair

   on Mar 21, 2019

   Contributor

   More actions

   For some reason was not able to reproduce it using bblfsh-cli.

   Hmm. I would have expected the Go client to use the same logic as bblfshctl. Does bblfsh-cli access a different RPC endpoint than bblfshctl uses?
7. bzz commented on Apr 14, 2019

   

   bzz

   on Apr 14, 2019

   Contributor

   More actions

   For some reason was not able to reproduce it using bblfsh-cli.

   Hmm. I would have expected the Go client to use the same logic as bblfshctl. Does bblfsh-cli access a different RPC endpoint than bblfshctl uses?

   Indeed, it seems like bblfshctl uses UASTv1 protocol, while bblfsh-cli uses UASTv2.
8. creachadair commented on Apr 15, 2019

   

   creachadair

   on Apr 15, 2019

   Contributor

   More actions

   Indeed, it seems like bblfshctl uses UASTv1 protocol, while bblfsh-cli uses UASTv2.

   Was this intentional, or did we just never get around to bringing them in sync? This could explain several odd differences I've encountered when trying to reproduce bug reports.
9. bzz commented on May 3, 2019

   

   bzz

   on May 3, 2019

   Contributor

   More actions

   Indeed, it seems like bblfshctl uses UASTv1 protocol, while bblfsh-cli uses UASTv2.

   Was this intentional, or did we just never get around to bringing them in sync? This could explain several odd differences I've encountered when trying to reproduce bug reports.

   I think the latter one - nobody uses it, so we never got around to syncing them properly.
10. dennwc commented on May 3, 2019

    

    dennwc

    on May 3, 2019

    Member

    More actions

    We still suggest using bblfshctl in the documentation, so we should definitely sync it. I'll take care of it.