View Ticket causes trac to Oops...

[lighttpd@…]

When viewing a specific ticket it causes a "crash".

Trac detected an internal error:
Traceback (innermost last):
  File "neo_hdf.c", line 783, in hdf_set_value()
  File "neo_hdf.c", line 773, in _set_value()
AssertError: Unable to set Empty component ticket.changes.0.fields..new

Python traceback

Traceback (most recent call last):
  File "/usr/local/lib/python2.4/site-packages/trac/web/standalone.py", line 253, in do_trac_req
    dispatch_request(path_info, req, env)
  File "/usr/local/lib/python2.4/site-packages/trac/web/main.py", line 311, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/local/lib/python2.4/site-packages/trac/web/main.py", line 190, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/local/lib/python2.4/site-packages/trac/Ticket.py", line 473, in process_request
    self.insert_ticket_data(req, db, id, ticket, reporter_id)
  File "/usr/local/lib/python2.4/site-packages/trac/Ticket.py", line 676, in insert_ticket_data
    req.hdf['ticket.changes'] = changes
  File "/usr/local/lib/python2.4/site-packages/trac/web/clearsilver.py", line 216, in __setitem__
    add_value(name, value)
  File "/usr/local/lib/python2.4/site-packages/trac/web/clearsilver.py", line 213, in add_value
    add_value('%s.%d' % (prefix, idx), item)
  File "/usr/local/lib/python2.4/site-packages/trac/web/clearsilver.py", line 209, in add_value
    add_value('%s.%s' % (prefix, k), value[k])
  File "/usr/local/lib/python2.4/site-packages/trac/web/clearsilver.py", line 209, in add_value
    add_value('%s.%s' % (prefix, k), value[k])
  File "/usr/local/lib/python2.4/site-packages/trac/web/clearsilver.py", line 209, in add_value
    add_value('%s.%s' % (prefix, k), value[k])
  File "/usr/local/lib/python2.4/site-packages/trac/web/clearsilver.py", line 206, in add_value
    self.hdf.setValue(prefix, value)
Error: Traceback (innermost last):
  File "neo_hdf.c", line 783, in hdf_set_value()
  File "neo_hdf.c", line 773, in _set_value()
AssertError: Unable to set Empty component ticket.changes.0.fields..new

[lighttpd@…]

What I can see is that this only happens with closed tickets.

[mihau]

That is happens with tickets assigned to milestone.

[Christopher Lenz]

I am not able to reproduce this. Can you provide more details about the ticket that is causing the problem? Maybe a dump of the ticket record and all related records in the ticket_change table, if possible.

[anonymous]

In what format would you like to have this? Normal select?

[Christopher Lenz]

Yeah, something like:

  SELECT * FROM ticket WHERE id=123;
  SELECT * FROM ticket_change WHERE ticket=123 ORDER BY time;

(replacing "123" with the ID of the problematic ticket, of course)

[lighttpd@…]

sqlite> SELECT * FROM ticket WHERE id=12;

12|1115124718|1115491665|GUI|trivial|normal|anonymous|nervous||||Postfix Admin 2.1.1|assigned||the menu at the top of every page doesn't display correctly in opera|Both opera7.5x and opera8 (probably other versions too) display the top menu incorrectly, thus navigation is impossible.
Some links overlaps and are impossible to click.|

sqlite> SELECT * FROM ticket_change WHERE ticket=12 ORDER BY time;

12|1115124718|nervous|comment||
12|1115124718|nervous||postfixadmin-opera8.png|
12|1115397319|mihau|comment||Simple workaround:
edit stylesheet.css find:
#menu {
    width: 750px;        
    margin: 0 auto;
    padding-top: 10px;
}
and change width to 950 or more to fit your neeeds.
Occur when translation to other language contain long words.
12|1115397319|mihau||0000011|
12|1115397319|mihau|severity|major|trivial
12|1115397319|mihau|status|new|assigned
12|1115397319|mihau|summary|the menu at the top of every page doesn't display correctly in opera|the menu at the top of every page doesn\'t display correctly in opera
12|1115491665|mischa|milestone||Postfix Admin 2.1.1

[Matthew Good]

The problematic lines are

12|1115124718|nervous||postfixadmin-opera8.png|
12|1115397319|mihau||0000011|

The "field" column in these rows is empty. From the values can you tell what these are supposed to be?

[lighttpd@…]

What can they be? The first one is an attachment for that ticket. The second one I have no idea.

[anonymous]

Is the second one assignment of the ticket?

[Matthew Good]

What revision of Trac are you using? I took a look at the tickets here: ​http://dev.high5.net/trac/report/6 and all tickets associated with milestone "Postfix Admin 2.1.1" have this problem.

[anonymous]

At the moment I am running 0.9pre. And this happened when I upgraded from 0.8.2 to 0.9pre. Maybe something in the upgrade process that went wrong?

[anonymous]

I removed the milestones and still the same problem :(

[mihau]

What about dumps of other problematic tickets? Maybe comparing brings some light…

[mischa]

Tckets 1, 2 and 3 are generating an error. Tickets 4,5 and 6 not.

sqlite> SELECT * FROM ticket WHERE id=1;
1|1114333561|1115491808|Database|major|normal|mihau|Flip|||||closed|fixed|Bug in mysql_real_escape_string ()|If no magic_quotes_gpc is set then mysql_real_escape_string is used. But there is more than one connection to mysql so link_identifier must be set because if there is more than 1 connection mysql_real_escape_string is using default mysql connection settings.
Warning: mysql_real_escape_string(): Access denied for user 'www'@'localhost' (using password: NO) in /xxx/functions.inc.php on line 131|
sqlite> SELECT * FROM ticket_change WHERE ticket=1 ORDER BY time;
1|1114333561|Flip|comment||
1|1114337920|danger|comment||well, I have already fixed that. See attached diff...
1|1114337920|danger||0000001|
1|1114337948|danger||pfadmin.patch|
1|1114361979|mischa|status|new|closed
1|1114361979|mischa|resolution|10|20
1|1114361979|mischa|owner|anonymous|mischa
1|1114480234|mischa|status|closed|assigned
1|1114480234|mischa|resolution|20|30
1|1114480252|mischa|status|assigned|closed
1|1114480252|mischa|resolution|30|20
1|1114487320|mischa|comment||Rev.5 The mysql_escape problem are fixed now, but needs to be tested with:
- mysqli
- pgsql
Tested already and it works for mysql.
For the first look it works for mysqli also... But for sure someone should check it.
1|1114487320|mischa||0000003|
1|1114487320|mischa|owner|mischa|mihau
1|1114488177|mischa|severity|enhancement|major
1|1115491808|mischa|milestone||Postfix Admin 2.1.1
sqlite> SELECT * FROM ticket WHERE id=2;
2|1114487173|1115491851|Function|enhancement|normal|mihau|mihau|||||closed|fixed|Quotas are not calculated properly|Mailbox quotas are not displayed and calculated properly|
sqlite> SELECT * FROM ticket_change WHERE ticket=2 ORDER BY time;
2|1114487173|mihau|comment||
2|1114487186|mischa|status|new|assigned
2|1114487186|mischa|owner|anonymous|mihau
2|1114487219|mischa|comment||Rev.7 Added: Functions multiply_quota() and divide_quota() for recalculating quota values.
Negative values are not allowed from now, except '-1' for 'disabled'.
Before domain admins will be able to enter "large" negative values, which are misinterpreted as
positive.
2|1114487219|mischa|status|assigned|closed
2|1114487219|mischa|resolution|10|20
2|1114487219|mischa|owner|mihau|mischa
2|1114487219|mischa||0000002|
2|1114487271|mischa|reporter_id|2|3
2|1114487271|mischa|owner|mischa|mihau
2|1115491851|mischa|milestone||Postfix Admin 2.1.1
sqlite> SELECT * FROM ticket WHERE id=3;
3|1114487412|1115491832|Database|enhancement|normal|mischa|mischa|||||closed||PostgreSQL Patches (Tarvin)|The PostgreSQL side needs a lot of work|
sqlite> SELECT * FROM ticket_change WHERE ticket=3 ORDER BY time;
3|1114487412|mischa|comment||
3|1114487473|mischa|comment||Tarvin has merged his patches.
Full change description didn't fit well into a svn comment, 
so the change description can be seen at http://troels.arvin.dk/db/postfixadmin/
3|1114487473|mischa||0000004|
3|1114487473|mischa|owner|anonymous|mischa
3|1114487473|mischa|status|new|closed
3|1114487491|mischa|summary|PostgreSQL Patches|PostgreSQL Patches (Tarvin)
3|1115491832|mischa|milestone||Postfix Admin 2.1.1

These are working

sqlite> SELECT * FROM ticket WHERE id=4;
4|1114487604|1114681011|Vacation|enhancement|normal|anonymous|mischa|||||new||Make Virtual Vacation use some of the PostgreSQL (Tarvin)|Make the mysql virtual vacation script use some of the stuff from the pgsql-vacation script, including prepared statements (for security) and some more sanitity checks. The extra sanity checks makes the script dependent on more perl modules, though, so some might not find it acceptable.
|
sqlite> SELECT * FROM ticket_change WHERE ticket=4 ORDER BY time;
4|1114487604|mischa|comment||
4|1114680876|mischa|status|new|assigned
4|1114680876|mischa|owner|anonymous|mihau
4|1114680920|mischa|owner|mihau|anonymous
4|1114680973|mischa|reporter_id|2|9
4|1114680973|mischa|status|assigned|closed
4|1114681011|mischa|reporter_id|9|2
4|1114681011|mischa|status|closed|new
sqlite> SELECT * FROM ticket WHERE id=5;
5|1114487733|1114487733|Core|enhancement|normal|anonymous|mischa|||||new||Separate SQL from PHP|SQL needs to be separated from the PHP code.
Streamline SQL queries|
sqlite> SELECT * FROM ticket_change WHERE ticket=5 ORDER BY time;
5|1114487733|mischa|comment||
sqlite> SELECT * FROM ticket WHERE id=6;
6|1114487879|1114487892|GUI|enhancement|normal|mihau|mischa|||||assigned||Merge /admin part with core|Get rid of /admin.|
sqlite> SELECT * FROM ticket_change WHERE ticket=6 ORDER BY time;
6|1114487879|mischa|comment||
6|1114487892|mischa|status|new|assigned
6|1114487892|mischa|owner|anonymous|mihau
sqlite> .quit

[Christopher Lenz]

Weird. Questions:

• Are you using custom fields? Is that where the attachment file names and the values such as "0000001" might come from?
• I hope you still have the database from before the upgrade… ;-) (Look at the .bak files in the <projenv>/db directory) Can you run the above SQL queries against the backup DB?

[mischa]

No custom fields at all… at least none that I am aware of. I upgraded from Mantis to Trac with version 0.8.1.

[mischa]

Same queries on the backup db.

sqlite> SELECT * FROM ticket WHERE id=1;
1|1114333561|1115491808|Database|major|normal|mihau|Flip||||Postfix Admin 2.1.1|closed|fixed|Bug in mysql_real_escape_string ()|If no magic_quotes_gpc is set then mysql_real_escape_string is used. But there is more than one connection to mysql so link_identifier must be set because if there is more than 1 connection mysql_real_escape_string is using default mysql connection settings.
Warning: mysql_real_escape_string(): Access denied for user 'www'@'localhost' (using password: NO) in /xxx/functions.inc.php on line 131|
sqlite> SELECT * FROM ticket_change WHERE ticket=1 ORDER BY time;
1|1114333561|Flip|comment||
1|1114337920|danger|comment||well, I have already fixed that. See attached diff...
1|1114337920|danger||0000001|
1|1114337948|danger||pfadmin.patch|
1|1114361979|mischa|status|new|closed
1|1114361979|mischa|resolution|10|20
1|1114361979|mischa|owner|anonymous|mischa
1|1114480234|mischa|status|closed|assigned
1|1114480234|mischa|resolution|20|30
1|1114480252|mischa|status|assigned|closed
1|1114480252|mischa|resolution|30|20
1|1114487320|mischa|comment||Rev.5 The mysql_escape problem are fixed now, but needs to be tested with:
- mysqli
- pgsql
Tested already and it works for mysql.
For the first look it works for mysqli also... But for sure someone should check it.
1|1114487320|mischa||0000003|
1|1114487320|mischa|owner|mischa|mihau
1|1114488177|mischa|severity|enhancement|major
1|1115491808|mischa|milestone||Postfix Admin 2.1.1
sqlite> SELECT * FROM ticket WHERE id=2;
2|1114487173|1115491851|Function|enhancement|normal|mihau|mihau||||Postfix Admin 2.1.1|closed|fixed|Quotas are not calculated properly|Mailbox quotas are not displayed and calculated properly|
sqlite> SELECT * FROM ticket_change WHERE ticket=2 ORDER BY time;
2|1114487173|mihau|comment||
2|1114487186|mischa|status|new|assigned
2|1114487186|mischa|owner|anonymous|mihau
2|1114487219|mischa|comment||Rev.7 Added: Functions multiply_quota() and divide_quota() for recalculating quota values.
Negative values are not allowed from now, except '-1' for 'disabled'.
Before domain admins will be able to enter "large" negative values, which are misinterpreted as
positive.
2|1114487219|mischa|status|assigned|closed
2|1114487219|mischa|resolution|10|20
2|1114487219|mischa|owner|mihau|mischa
2|1114487219|mischa||0000002|
2|1114487271|mischa|reporter_id|2|3
2|1114487271|mischa|owner|mischa|mihau
2|1115491851|mischa|milestone||Postfix Admin 2.1.1
sqlite> SELECT * FROM ticket WHERE id=3;
3|1114487412|1115491832|Database|enhancement|normal|mischa|mischa||||Postfix Admin 2.1.1|closed||PostgreSQL Patches (Tarvin)|The PostgreSQL side needs a lot of work|
sqlite> SELECT * FROM ticket_change WHERE ticket=3 ORDER BY time;
3|1114487412|mischa|comment||
3|1114487473|mischa|comment||Tarvin has merged his patches.
Full change description didn't fit well into a svn comment, 
so the change description can be seen at http://troels.arvin.dk/db/postfixadmin/
3|1114487473|mischa||0000004|
3|1114487473|mischa|owner|anonymous|mischa
3|1114487473|mischa|status|new|closed
3|1114487491|mischa|summary|PostgreSQL Patches|PostgreSQL Patches (Tarvin)
3|1115491832|mischa|milestone||Postfix Admin 2.1.1
sqlite> SELECT * FROM ticket WHERE id=4;
4|1114487604|1114681011|Vacation|enhancement|normal|anonymous|mischa|||||new||Make Virtual Vacation use some of the PostgreSQL (Tarvin)|Make the mysql virtual vacation script use some of the stuff from the pgsql-vacation script, including prepared statements (for security) and some more sanitity checks. The extra sanity checks makes the script dependent on more perl modules, though, so some might not find it acceptable.
|
sqlite> SELECT * FROM ticket_change WHERE ticket=4 ORDER BY time;
4|1114487604|mischa|comment||
4|1114680876|mischa|status|new|assigned
4|1114680876|mischa|owner|anonymous|mihau
4|1114680920|mischa|owner|mihau|anonymous
4|1114680973|mischa|reporter_id|2|9
4|1114680973|mischa|status|assigned|closed
4|1114681011|mischa|reporter_id|9|2
4|1114681011|mischa|status|closed|new
sqlite> SELECT * FROM ticket WHERE id=5;
5|1114487733|1114487733|Core|enhancement|normal|anonymous|mischa|||||new||Separate SQL from PHP|SQL needs to be separated from the PHP code.
Streamline SQL queries|
sqlite> SELECT * FROM ticket_change WHERE ticket=5 ORDER BY time;
5|1114487733|mischa|comment||
sqlite> SELECT * FROM ticket WHERE id=6;
6|1114487879|1114487892|GUI|enhancement|normal|mihau|mischa|||||assigned||Merge /admin part with core|Get rid of /admin.|
sqlite> SELECT * FROM ticket_change WHERE ticket=6 ORDER BY time;
6|1114487879|mischa|comment||
6|1114487892|mischa|status|new|assigned
6|1114487892|mischa|owner|anonymous|mihau

[mischa]

any news?

[Matthew Good]

Did you use a script to import your Mantis tickets into Trac? It's possible something could have gone wrong during that process.

One thing I noticed is that all the tickets have a row in "ticket_change" from the same time the ticket was created with an empty comment. This normally should not happen when creating a ticket through Trac since the ticket creation doesn't do anything with this table.

You can get rid of the rows that are causing problems like:

delete from ticket_change where field is null or field = ''

I'm not sure that they're hurting anything, but you may also want to get rid of the empty comment changes as well.

All new tickets on the site from 13 and up don't have problems and don't have the empty comment at the beginning, so I don't think that there's anything to do beyond cleaning up the data on the old tickets.

[mischa]

Working. Thanx!