| Summary: | [abrt] git-cola: posixpath.py:361:abspath:FileNotFoundError: [Errno 2] Aucun fichier ou dossier de ce type | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Gwendal <ezwen-redhatbugzilla> | ||||||
| Component: | git-cola | Assignee: | Nikos Roussos <comzeradd> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 23 | CC: | davvid, ezwen-redhatbugzilla, kevin, oliver | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/ca73b2b2fc26e5a61cd5085b58dcbd9f8744fa63 | ||||||||
| Whiteboard: | abrt_hash:f668c229247caade984d3c47dc9a9268ae1c8a11;VARIANT_ID=workstation; | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-05-06 17:57:02 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
Created attachment 1142083 [details]
File: backtrace
Created attachment 1142084 [details]
File: environ
Most impressive -- how did you trigger this behavior? From the looks of it, os.getcwd() failed, which can usually only be explained by someone doing "rm -rf" on their git repository while cola is running. It's unclear how to proceed in this scenario. One approach would be to fail fast (as we do) and abort the current operation. This would be pretty annoying to defensively handle. Theoretically, every call to abspath, relpath, getcwd, and probably lots of other standard library functionality would need to be wrapped to account for this narrow, arguably bogus use case. Thus, I think this falls into the category of, "if it hurts, don't do that", probably won't fix, not a real bug, or if it is, the bug is in the python standard library ;-) It could be argued that relpath() should return its argument unchanged when it fails to get the current directory. That said, I might try to repro this and perhaps terminate the inotify thread if possible. I am slightly curious to see if I can make cola robust to these shenanigans. Let's take the abrt challenge. Thanks for the report. glad to help! I usually try to send reports with ABRT when I can I don't know how I managed to trigger this. It only looked to a random crash to me, and I didn't pay attention to what I was doing at the same time. Sorry for the lack of precision :( Yet it never occurred again, so I guess it's not a big problem. But if that's an interesting challenge for you, that's still something :) Hmm, looking closer, I think we probably should close this bug. The later versions of git-cola completely reworked how the inotify subsystem works, so this one shouldn't really happen anymore. If you could kindly clone the latest from github (git clone git://github.com/git-cola/git-cola.git), run it in-place (./git-cola/bin/git-cola) and reproduce the problem there then we'd be happy to keep poking at this issue in our upstream bug tracker. Would you mind filing an issue on our github issue tracker? (https://github.com/git-cola/git-cola/issues) Even with the existing backtrace, that'll make sure that the other git-cola developers see it, particularly Daniel who completely restructured the inotify subsystem in v2.5. I'm pretty sure the nature of this problem will pique his interest. cheers, David This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Closing this per comment #5. If this error persists we re-open. |
Version-Release number of selected component: git-cola-2.3-1.fc23 Additional info: reporter: libreport-2.6.4 cmdline: /usr/bin/python3 /usr/bin/git-cola --prompt executable: /usr/bin/git-cola kernel: 4.4.6-300.fc23.x86_64 runlevel: N 5 type: Python3 uid: 1000 Truncated backtrace: posixpath.py:361:abspath:FileNotFoundError: [Errno 2] Aucun fichier ou dossier de ce type Traceback (most recent call last): File "/usr/share/git-cola/lib/cola/inotify.py", line 247, in run notifier.process_events() File "/usr/lib/python3.4/site-packages/pyinotify.py", line 1275, in process_events self._default_proc_fun(revent) File "/usr/lib/python3.4/site-packages/pyinotify.py", line 910, in __call__ return _ProcessEvent.__call__(self, event) File "/usr/lib/python3.4/site-packages/pyinotify.py", line 636, in __call__ return self.process_default(event) File "/usr/share/git-cola/lib/cola/inotify.py", line 137, in process_default path = os.path.relpath(os.path.join(event.path, event.name)) File "/usr/lib64/python3.4/posixpath.py", line 448, in relpath start_list = [x for x in abspath(start).split(sep) if x] File "/usr/lib64/python3.4/posixpath.py", line 361, in abspath cwd = os.getcwd() FileNotFoundError: [Errno 2] Aucun fichier ou dossier de ce type Local variables in innermost frame: path: '.'