Edgewall Software
Modify

Opened 12 years ago

Closed 12 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)

t424-delete_log_files-r710.diff (1.6 KB) - added by osimons 12 years ago.
Fixes (?) the logic for deleting log + level files.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 12 years ago by osimons

  • Cc osimons added

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:

sqlite> select * from bitten_log where build=17;
67|17|bug|http://bitten.cmlenz.net/tools/sh#exec|0|67.log
68|17|checkout|http://bitten.cmlenz.net/tools/svn#checkout|0|68.log
69|17|py|http://bitten.cmlenz.net/tools/python#exec|0|69.log

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).

Changed 12 years ago by osimons

Fixes (?) the logic for deleting log + level files.

comment:2 follow-up: Changed 12 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: Changed 12 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 12 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 12 years ago by osimons

  • Resolution set to fixed
  • Status changed from new to closed

Committed in [714].

Add Comment

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain osimons.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.