0014234: Error 401 When openning Summary

(0031803)
badmoon (reporter)
2012-05-10 12:23

Solved updating summary_api.php
function summary_nw_bug_count_by_date
adding cast ... as signed

$query = "SELECT COUNT(*)
FROM $t_mantis_bug_table
WHERE " . db_helper_compare_days( "" . db_now() . "", "cast(date_submitted as signed)", "<= $c_time_length" ) . " AND $specific_where";

(0031809)
dregad (developer)
2012-05-11 04:42

Your fix is not really portable as data types vary across RDBMS.

Since you imported data using CSV plugin, I suggest you have a closer look at the contents of the date_submitted field (compare it with an issue created manually within Mantis)

(0031812)
rombert (developer)
2012-05-11 06:15

According to http://dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html [^] for BIGINT the unsigned range is 0 to 18446744073709551615 , so it looks like the date_submitted value is way out of range. Casting to an integer will only mask the real problem.

(0031814)
badmoon (reporter)
2012-05-11 06:36

I have checked date_submitted and there is no rows > 18446744073709551615 or < 0

(0031819)
grangeway (developer)
2012-05-12 12:12

If you can reproduce this issue with a stock mantis installation, please reopen and we'll take a look into the cause.

(0031825)
rombert (developer)
2012-05-13 15:34

I'm actually interested to see how this plays out. Maybe it's an error in the core code which is exposed by the plugin so let's not rule it out so quickly.

(0031826)
grangeway (developer)
2012-05-13 17:53

hence why I said reopen with more information - there's still no information here to fix anything :)

(0031827)
grangeway (developer)
2012-05-13 18:06

It's a bug in the plugin -

We convert the values to an int - depending on timezone, what the csv import plugin does and badmoon's timezone for the imported data - it's feasible that current time - imported time in different timezone is less than 0, hence outside the range of an unsigned bit int.

As soon as you cast it one of the data type's in the where clause I suspect that causes the whole where clause to get evaluated as signed, hence does't error.

So the only thing we could is patch bug_create to ensure timestamps on submitted issues are not in the future. This is something that'll be somewhat easier to check for when using objects.

If you look at the source code of the csv import plugin, it calls:

$t_bug_data->date_submitted = date('Y-m-d G:i:s');

That's not a supported way of setting up date_submitted.

(0031896)
rombert (developer)
2012-05-24 15:11

Paul, thanks for the investigation. I'm moving this to the csv import plugin.

Issue History
Date Modified	Username	Field	Change
2012-05-10 11:49	badmoon	New Issue
2012-05-10 12:23	badmoon	Note Added: 0031803
2012-05-11 04:42	dregad	Note Added: 0031809
2012-05-11 06:15	rombert	Note Added: 0031812
2012-05-11 06:36	badmoon	Note Added: 0031814
2012-05-11 07:45	sjannu	Note Added: 0031815
2012-05-11 07:46	sjannu	Note Deleted: 0031815
2012-05-12 12:12	grangeway	Note Added: 0031819
2012-05-12 12:12	grangeway	Status	new => resolved
2012-05-12 12:12	grangeway	Resolution	open => unable to reproduce
2012-05-12 12:12	grangeway	Assigned To	=> grangeway
2012-05-13 15:34	rombert	Note Added: 0031825
2012-05-13 15:34	rombert	Assigned To	grangeway =>
2012-05-13 15:34	rombert	Status	resolved => assigned
2012-05-13 15:34	rombert	Resolution	unable to reproduce => reopened
2012-05-13 15:34	rombert	Description Updated	View Revisions
2012-05-13 17:53	grangeway	Note Added: 0031826
2012-05-13 18:06	grangeway	Note Added: 0031827
2012-05-24 15:11	rombert	Note Added: 0031896
2012-05-24 15:12	rombert	Project	mantisbt => Plugin - CsvImport
2012-05-24 15:12	rombert	Category	db mysql => General
2013-04-05 08:25	atrol	Relationship added	has duplicate 0015715

Notes
(0031803) badmoon (reporter) 2012-05-10 12:23	Solved updating summary_api.php function summary_nw_bug_count_by_date adding cast ... as signed $query = "SELECT COUNT(*) FROM $t_mantis_bug_table WHERE " . db_helper_compare_days( "" . db_now() . "", "cast(date_submitted as signed)", "<= $c_time_length" ) . " AND $specific_where";

(0031809) dregad (developer) 2012-05-11 04:42	Your fix is not really portable as data types vary across RDBMS. Since you imported data using CSV plugin, I suggest you have a closer look at the contents of the date_submitted field (compare it with an issue created manually within Mantis)

(0031812) rombert (developer) 2012-05-11 06:15	According to http://dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html [^] for BIGINT the unsigned range is 0 to 18446744073709551615 , so it looks like the date_submitted value is way out of range. Casting to an integer will only mask the real problem.

(0031814) badmoon (reporter) 2012-05-11 06:36	I have checked date_submitted and there is no rows > 18446744073709551615 or < 0

(0031819) grangeway (developer) 2012-05-12 12:12	If you can reproduce this issue with a stock mantis installation, please reopen and we'll take a look into the cause.

(0031825) rombert (developer) 2012-05-13 15:34	I'm actually interested to see how this plays out. Maybe it's an error in the core code which is exposed by the plugin so let's not rule it out so quickly.

(0031826) grangeway (developer) 2012-05-13 17:53	hence why I said reopen with more information - there's still no information here to fix anything :)

(0031827) grangeway (developer) 2012-05-13 18:06	It's a bug in the plugin - We convert the values to an int - depending on timezone, what the csv import plugin does and badmoon's timezone for the imported data - it's feasible that current time - imported time in different timezone is less than 0, hence outside the range of an unsigned bit int. As soon as you cast it one of the data type's in the where clause I suspect that causes the whole where clause to get evaluated as signed, hence does't error. So the only thing we could is patch bug_create to ensure timestamps on submitted issues are not in the future. This is something that'll be somewhat easier to check for when using objects. If you look at the source code of the csv import plugin, it calls: $t_bug_data->date_submitted = date('Y-m-d G:i:s'); That's not a supported way of setting up date_submitted.

(0031896) rombert (developer) 2012-05-24 15:11	Paul, thanks for the investigation. I'm moving this to the csv import plugin.