ejwa / gitinspector

:bar_chart: The statistical analysis tool for git repositories
GNU General Public License v3.0
2.36k stars 327 forks source link

'NoneType' object is not iterable due to bug in threading code #118

Closed carera closed 7 years ago

carera commented 8 years ago

Hi

for one particular repository, gitinspector just stopped working

Fetching and calculating primary statistics (1 of 2): 99%Traceback (most recent call last):
  File "../gitinspector/gitinspector.py", line 24, in <module>
    gitinspector.main()
  File "/Users/minarikj/apps/gitinspector/gitinspector/gitinspector.py", line 206, in main
    run.process(repos)
  File "/Users/minarikj/apps/gitinspector/gitinspector/gitinspector.py", line 70, in process
    changes = Changes(repo, self.hard)
  File "/Users/minarikj/apps/gitinspector/gitinspector/changes.py", line 222, in __init__
    self.commits = [item for sublist in self.commits for item in sublist]
TypeError: 'NoneType' object is not iterable

I am running Mac OS El Capitan 10.11.4 script is being run with Python 2.7

It works for other repositories, and if I git reset --hard HEAD^ (i.e. hard reset to second last commit), it works for this particular repository as well. The last commit that 'breaks' it containts nothing more than a couple of files changed and added (merge from a PR branch). Now adding a new commit on top of HEAD makes it work again.

adam-waldenberg commented 8 years ago

Hi. Please see #115 and try to apply that fix. I think this might be related. I actually looked into this and it is related to the new threading code in changes.py.

tomriddly commented 8 years ago

@adam-waldenberg I found the issure may cause by uncommited(maybe unpushed?) changes. I think this might be helpful;-)

mensfeld commented 7 years ago

I have the same problem when using --json (for non json works ok)

I get following error after applying patch that @adam-waldenberg suggested:

Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/share/gitinspector/gitinspector/blame.py", line 106, in run
    self.__handle_blamechunk_content__(row)
  File "/usr/share/gitinspector/gitinspector/blame.py", line 87, in __handle_blamechunk_content__
    if (self.blamechunk_time - self.changes.first_commit_date).days > 0:
AttributeError: 'Changes' object has no attribute 'first_commit_date'

FYI if I replace this:

CHANGES_PER_THREAD = 200
NUM_THREADS = multiprocessing.cpu_count()

with this (basically disabling multithreading):

CHANGES_PER_THREAD = 2000000
NUM_THREADS = 1

things work fine.

hindsholm commented 7 years ago

I run into this bug consistently on two repositories. There are no uncommitted changes. I am running ver. 0.4.4.

adam-waldenberg commented 7 years ago

@hindsholm, As you can see from the above discussion, the Issue is well understood... I just haven't had time to sit down and actually fix it yet...

hindsholm commented 7 years ago

@adam-waldenberg I understand. I just wanted to let you know that the issue will also show up when there are no uncommitted changes :-)

adam-waldenberg commented 7 years ago

@hindsholm Yes. Thank you. It's actually caused by a logic error in the threading code (overflow), causing it to end up with an empty changeset. In the meantime you can remedy it with the fix mentioned in https://github.com/ejwa/gitinspector/issues/118#issuecomment-258506482.

hindsholm commented 7 years ago

@adam-waldenberg I have cloned the repo and applied the workaround and I can confirm that it does indeed work :-)

mensfeld commented 7 years ago

@hindsholm it needs to work - It runs around 2-5k times per day for me ;)

adam-waldenberg commented 7 years ago

Should be fixed now. Please report any problems.