Opened 15 years ago
Closed 15 years ago
#424 closed defect (fixed)
AttributeError: 'NoneType' object has no attribute 'rfind'
Reported by: | anonymous | Owned by: | osimons |
---|---|---|---|
Priority: | major | Milestone: | 0.6 |
Component: | General | Version: | 0.5.3 |
Keywords: | Cc: | dfraser | |
Operating System: | BSD |
Description
AttributeError: 'NoneType' object has no attribute 'rfind' Reported by: nkatsy Owned by: Priority: normal Milestone: Component: general Version: 0.11.5rc2 Severity: normal Keywords: Cc: Description ¶ How to Reproduce ¶ While doing a POST operation on /build/installer/5893, Trac issued an internal error. (please provide additional details here) Request parameters: {'__FORM_TOKEN': u'2188023fbf669d8095110f1f', 'action': u'invalidate', 'config': u'installer', 'id': u'5893'} User Agent was: Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9.0.11) Gecko/20080528 Fedora/2.24.3-7.fc10 Epiphany/2.22 Firefox/3.0 System Information ¶ Trac 0.11.5rc2 Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38) [GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] setuptools 0.6c2 psycopg2 2.0.11 Genshi 0.6dev-r1063 Bitten 0.6dev-r657 Subversion 1.5.4 (r33841) RPC 1.0.6 jQuery: 1.2.6 Python Traceback ¶ Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/Trac-0.11.5rc2-py2.5.egg/trac/web/main.py", line 444, in _dispatch_request dispatcher.dispatch(req) File "/usr/lib/python2.5/site-packages/Trac-0.11.5rc2-py2.5.egg/trac/web/main.py", line 205, in dispatch resp = chosen_handler.process_request(req) File "/usr/lib/python2.5/site-packages/Bitten-0.6dev_r657-py2.5.egg/bitten/web_ui.py", line 473, in process_request self._do_invalidate(req, build, db) File "/usr/lib/python2.5/site-packages/Bitten-0.6dev_r657-py2.5.egg/bitten/web_ui.py", line 612, in _do_invalidate step.delete(db=db) File "/usr/lib/python2.5/site-packages/Bitten-0.6dev_r657-py2.5.egg/bitten/model.py", line 575, in delete log.delete(db=db) File "/usr/lib/python2.5/site-packages/Bitten-0.6dev_r657-py2.5.egg/bitten/model.py", line 734, in delete log_file = self.get_log_file(log_file[0]) File "/usr/lib/python2.5/site-packages/Bitten-0.6dev_r657-py2.5.egg/bitten/model.py", line 716, in get_log_file if filename != os.path.basename(filename): File "/usr/lib/python2.5/posixpath.py", line 112, in basename return split(p)[1] File "/usr/lib/python2.5/posixpath.py", line 77, in split i = p.rfind('/') + 1 AttributeError: 'NoneType' object has no attribute 'rfind'
Attachments (1)
Change History (6)
comment:1 Changed 15 years ago by osimons
- Cc osimons added
comment:2 follow-up: ↓ 3 Changed 15 years ago by osimons
- Cc dfraser added; osimons removed
- Owner set to osimons
I've looked at the logic for deleting log files, and to me it seems wrong - it feels like it is left over from an earlier iteration of the db->file conversion of logs. At least in my database created after this update was introduced.
Each BuildLog in my db (bitten_log table) is a single filename - with a one-to-one between log item and file. This is also confirmed by the BuildLog.insert() method that creates these two files. However, the current logic seems to select from the database expecting many files - and additionally don't handle the levels file properly so it was left dangling (in my dev project I now have a lot of .level files without corresponding log files).
attachment:t424-delete_log_files-r710.diff fixes this to work with the current logic, and it also checks that filename is populated so that the error described in this ticket (because filename is None) should no longer happen.
David, could you look at this please?
comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 15 years ago by dfraser
Replying to osimons:
Each BuildLog in my db (bitten_log table) is a single filename - with a one-to-one between log item and file. This is also confirmed by the BuildLog.insert() method that creates these two files. However, the current logic seems to select from the database expecting many files - and additionally don't handle the levels file properly so it was left dangling (in my dev project I now have a lot of .level files without corresponding log files).
Yes, the logic would totally fail for level files so definitely needs fixing.
attachment:t424-delete_log_files-r710.diff fixes this to work with the current logic, and it also checks that filename is populated so that the error described in this ticket (because filename is None) should no longer happen.
The only thing here is that it relies on self.filename being initialized properly - it looks to me like BuildLog.select constructs the BuildLogs without passing in a filename, so this looks like it would simply ignore files that actually exist. For that reason it makes sense to still query the database, but to handle the null case properly (and it's safe to assume that there's only one filename and we should only get one row back)
comment:4 in reply to: ↑ 3 Changed 15 years ago by osimons
Replying to dfraser:
The only thing here is that it relies on self.filename being initialized properly - it looks to me like BuildLog.select constructs the BuildLogs without passing in a filename, so this looks like it would simply ignore files that actually exist.
No, it shouldn't. select() calls fetch() to load each BuildLog, and fetch() properly handles filename (as it also reads the messages as part of fetching).
comment:5 Changed 15 years ago by osimons
- Resolution set to fixed
- Status changed from new to closed
Committed in [714].
Could you check your trac.ini setting for [bitten] logs_dir? Does it just say log/bitten?
Similar message to #408, but I feel this is different - seems more like there isn't a logfile attached to the build for some reason. If you get another chance to invalidate, could you run this SQL for the relevant build number just to have a record of the database before delting?
I use SQLite, and run sqlite3 /path/to/trac/project/db/trac.db, and a select for a random build (17) in my development database looks like this:
If it fails again, then please post the output of the pre-invalidate SQL - and also please verify that the mentioned files actually exists inside log/bitten (ie. 67.log, 68.log, 69.log from example above).