Opened 17 years ago
Last modified 10 years ago
#4794 closed defect
Error if ticket reference is bigger than sys.maxint — at Version 2
Reported by: | anonymous | Owned by: | Jonas Borgström |
---|---|---|---|
Priority: | high | Milestone: | 0.10.4 |
Component: | wiki system | Version: | 0.10.3 |
Severity: | normal | Keywords: | traclinks |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
If you have "#12222222 22222222" (I put the space in there only so trac's trac doesn't crash due to this same bug) on a Wiki page or in a subversion commit log, trac tries to look up that ticket number. If the number is larger than maxint, there is an error. This makes the revision log and the timeline unusable. I'm not sure if it is strictly a postfix problem or not. I fixed it by adding
if long(target) < maxint
to api.py, just before:
cursor = formatter.db.cursor() cursor.execute("SELECT summary,status FROM ticket WHERE id=%s", (str(int(target)),)) row = cursor.fetchone() if row: return html.A(label, class_='%s ticket' % row[1], title=shorten_line(row[0]) + ' (%s)' % row[1], href=formatter.href.ticket(target))
and indenting those lines (at about line 215). Of course, I added "from sys import maxint" at the top.
I think that will fix the same problem for report numbers as well.
Change History (2)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Description: | modified (diff) |
---|
Seems this is PostgreSQL specific (works fine with SQLite and MySQL).
With PostgreSQL, #2147483647 works but #2147483647+1 doesn't ;-)
So yes, checking against sys.maxint
seems the right thing to do (would be worth a check on a 64-bits machine, though).
Looks like #4792 and #4793 are nice demos of the same problem in the ticket system…