View Issue Details

IDProjectCategoryView StatusLast Update
0020075mantisbtbugtrackerpublic2016-06-12 00:42
Reporteralex.volkovAssigned Todregad 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformMicrosoftOSWindows Server 2012 R2OS Version
Product Version1.3.0-beta.2 
Target Version1.3.0-rc.2Fixed in Version1.3.0-rc.2 
Summary0020075: Error 1105 while changing bug status from bug_change_status_page.php
Description

Attempting to change the bug status from the bug_change_status_page.php (for example, acknowledging or confirming a bug) results in

APPLICATION ERROR #1105
This issue has been updated by another user, please return to the issue and submit your changes again.

I have not tried on other database drivers or OSes.

Steps To Reproduce

Pull up a 'new' bug
Select 'acknowledged' in [Change Status To:]
Click on [Change Status To:]
Enter comment in [Add Note]
Click on [Acknowledge Issue]
Get error 1105

Additional Information

MS Windows Server 2012 R2 / IIS v8.5
MS SQL Server 2012
PHP 5.6.12 x86, FastCGI, php-cgi.exe
MS Driver for SQL Server v3.2 x86, NTS, php_sqlsrv_56_nts.dll
mssqlnative ADODB driver: cachedSchemaFlush patched
database_api.php: $ADODB_FETCH_MODE patched; db_prepare_binary_string() patched

The culprit appears to be the following line in bug_update.php:
$t_updated_bug->last_updated = gpc_get_string( 'last_updated' );

'last_updated' is an int in $t_existing_bug, but is read as string into $t_updated_bug, which results in a failed exact compare (!==):
if( $t_existing_bug->last_updated !== $t_updated_bug->last_updated ) {
trigger_error( ERROR_BUG_CONFLICTING_EDIT, ERROR );
}

Changing the suspect line to the following resolves the issue:
$t_updated_bug->last_updated = gpc_get_int( 'last_updated' );

var_dump() from bug_update.php:
t_existing_bug: object(BugData)#33 (36) { ["id":protected]=> int(1) ["project_id":protected]=> int(1) ["reporter_id":protected]=> int(1) ["handler_id":protected]=> int(0) ["duplicate_id":protected]=> int(0) ["priority":protected]=> int(20) ["severity":protected]=> int(50) ["reproducibility":protected]=> int(30) ["status":protected]=> int(10) ["resolution":protected]=> int(10) ["projection":protected]=> int(10) ["category_id":protected]=> int(3) ["date_submitted":protected]=> int(1441229707) ["last_updated":protected]=> int(1441310706) ["eta":protected]=> int(10) ["os":protected]=> string(0) "" ["os_build":protected]=> string(0) "" ["platform":protected]=> string(0) "" ["version":protected]=> string(7) "current" ["fixed_in_version":protected]=> string(0) "" ["target_version":protected]=> string(0) "" ["build":protected]=> string(0) "" ["view_state":protected]=> int(10) ["summary":protected]=> string(16) "Test Hamster bug" ["sponsorship_total":protected]=> int(0) ["sticky":protected]=> int(1) ["due_date":protected]=> int(1) ["profile_id":protected]=> int(0) ["description":protected]=> string(46) "Testing Mantis - test bug 0000001 Line 2 Line 3" ["steps_to_reproduce":protected]=> string(0) "" ["additional_information":protected]=> string(0) "" ["_stats":"BugData":private]=> NULL ["attachment_count"]=> NULL ["bugnotes_count"]=> NULL ["loading":"BugData":private]=> bool(false) ["bug_text_id"]=> int(1) }

t_updated_bug: object(BugData)#34 (36) { ["id":protected]=> int(1) ["project_id":protected]=> int(1) ["reporter_id":protected]=> int(1) ["handler_id":protected]=> int(1) ["duplicate_id":protected]=> int(0) ["priority":protected]=> int(20) ["severity":protected]=> int(50) ["reproducibility":protected]=> int(30) ["status":protected]=> int(30) ["resolution":protected]=> int(10) ["projection":protected]=> int(10) ["category_id":protected]=> int(3) ["date_submitted":protected]=> int(1441229707) ["last_updated":protected]=> string(10) "1441310706" ["eta":protected]=> int(10) ["os":protected]=> string(0) "" ["os_build":protected]=> string(0) "" ["platform":protected]=> string(0) "" ["version":protected]=> string(7) "current" ["fixed_in_version":protected]=> string(0) "" ["target_version":protected]=> string(0) "" ["build":protected]=> string(0) "" ["view_state":protected]=> int(10) ["summary":protected]=> string(16) "Test Hamster bug" ["sponsorship_total":protected]=> int(0) ["sticky":protected]=> int(1) ["due_date":protected]=> int(1) ["profile_id":protected]=> int(0) ["description":protected]=> string(46) "Testing Mantis - test bug 0000001 Line 2 Line 3" ["steps_to_reproduce":protected]=> string(0) "" ["additional_information":protected]=> string(0) "" ["_stats":"BugData":private]=> NULL ["attachment_count"]=> NULL ["bugnotes_count"]=> NULL ["loading":"BugData":private]=> bool(false) ["bug_text_id"]=> int(1) }

TagsNo tags attached.

Relationships

related to 0020478 closeddregad bug_update.php: do not use strict type checking unless necessary 

Activities

vboctor

vboctor

2015-09-06 12:56

manager   ~0051382

I've reverted this since it broke both bug update and status update scenarios.

alex.volkov

alex.volkov

2015-09-08 16:36

reporter   ~0051405

Interesting. Which scenarios did the patch break? Everything appears to work correctly on my MS platform with just 3 small MSSQL-related patches, plus the one proposed here. Could this be a difference between the MSSQL and MySQL db schemas, or the ADODB driver operation? For example, I see 'UNSIGNED' all over the schema.php, but MSSQL does not support unsigned ints, so the columns are just 'int':
last_updated int DEFAULT(1) NOT NULL,
bug_get() returns the 'last_updated' column as an 'int' here.

How does the 'last_updated' column look in the MySQL db, and how does the MySQL driver return it to bug_cache_row(), as a string?

I do see the last_updated initialized to an empty string in BugData, but it is later set to db_now() in many places, including the BugData::create in bug_api.php. Here is a var_dump() of db_now() on my PHP 5.6.12 x86 / MS platform: int(1441744082)

dregad

dregad

2015-09-09 04:14

developer   ~0051420

How does the 'last_updated' column look in the MySQL db,

mysql> desc mantis_bug_table;
+-------------------+------------------+------+-----+---------+----------------+
| Field             | Type             | Null | Key | Default | Extra          |
+-------------------+------------------+------+-----+---------+----------------+
...
| last_updated      | int(10) unsigned | NO   |     | 1       |                |
+-------------------+------------------+------+-----+---------+----------------+
29 rows in set (0.01 sec)

how does the MySQL driver return it to bug_cache_row(), as a string?

Yes:

array (size=29)
...
  'last_updated' => string '1441627391' (length=10)

I'll let @vboctor reply on the errors he got.

dregad

dregad

2015-10-24 18:53

developer   ~0051703

Alex, Victor, none of you have provided any feedback... Where do we go from here ?

vboctor

vboctor

2015-10-25 00:46

manager   ~0051707

I don't recall the error right now. However, I'm not seeing any errors with the current head. Did you try 1.3.0-beta.3 and latest master code? Let's start by reproducing the error you are trying to fix.

vboctor

vboctor

2015-10-25 00:58

manager   ~0051708

Last edited: 2015-10-25 01:06

View 2 revisions

I have retested without the revert, and I get the following error:

"This issue has been updated by another user, please return to the issue and submit your changes again.

/Users/vboctor/php/mantisbt-master/bug_update.php 117 - - trigger_error ( <string>'1105', <integer>256 )"

Without the "fix" and with latest master, I don't get this error.

dregad

dregad

2015-12-20 18:46

developer   ~0052147

Alex, I'm not able to reproduce this on latest master with MySQL or PostgreSQL. I don't have access to MSSQL setup, can you please confirm this is still an issue ?

vboctor

vboctor

2015-12-26 20:10

manager   ~0052184

Reducing to minor so it is not blocking, unless we have a repro and determine that is blocking.

alex.volkov

alex.volkov

2016-01-26 13:47

reporter   ~0052392

The issue is still present in 1.3-rc1 on Windows/MS SQL platform, same as before. The problem is due to the following:

  • MySQL db schema uses UNSIGNED INT for date columns. Unsigned 32-bit integers are NOT a native type to PHP, so ADODB returns them as 'string'.
  • MS SQL does not have unsigned integer data types, so instead the signed INT data type was chosen. Signed 32-bit integers ARE native to PHP, so ADODB returns them as 'int'.
  • The PHP's 'not identical' operator is used to compare the last_updated dates in bug_update.php, which returns true because int !== string.
    This difference must be reconciled in some way in order to solve the issue.

One way to do it is to force a database column data type which is not native to PHP, which in turn would cause ADODB to return it as 'string'. A suitable MS SQL data type is 'bigint' (64-bit signed). Initial testing looks promising. I changed all date columns to 'bigint' in mantis_bug_table on my MS SQL, and the issue went away. The dates are displayed normally, and I can update the bugs without any issues so far. Using 'bigint' also solves the looming year 2038 problem.

That said, I do not see an easy way of translating 'I UNSIGNED' used in schema.php to 'bigint' for MS SQL, and doing it for date columns only. This is probably moot anyway, because the current schema scripts and drivers are incapable of generating working schema change scripts for MS SQL. There are dramatic differences between MySQL and MS SQL when it comes to altering tables, indexes and constraints. Complex database upgrades must be performed manually on MS SQL.

dregad

dregad

2016-01-27 06:58

developer   ~0052406

Thanks for your analysis and feedback Alex.

the current schema scripts and drivers are incapable of generating working schema change scripts for MS SQL.

Are you saying that the SQL generated by ADOdb library does not work ? If so, I would suggest you report that https://github.com/ADOdb/ADOdb/issues

  • The PHP's 'not identical' operator is used to compare the last_updated dates in bug_update.php, which returns true because int !== string.

Maybe we should simply use != instead of !== in bug_update.php ? I didn't look in details, but I don't see the benefit of the strict comparison off-hand. That was most likely added by dhx when he refactored that code.

macdoncj

macdoncj

2016-02-25 15:57

reporter   ~0052568

Using != instead of !== in bug_update.php fixed this issue with 1.3-rc1 on MSSQL2012. My team and I are new to Mantis, but we haven't come across any issues as a result of it. Could we consider this a viable fix or should we be on the lookout in future updates?

dregad

dregad

2016-02-25 18:53

developer   ~0052569

I don't believe it would have any negative side-effect. In fact, with your confirmation, I'll probably make this change a part of MantisBT Core unless vboctor or one of the other devs object to it.

dregad

dregad

2016-02-26 08:08

developer   ~0052571

Just realised I had already fixed this in 0020478 a few weeks ago, can you kindly confirm using a nightly build of latest master [1] that the problem is indeed resolved ? TIA

[1] http://mantisbt.org/builds.php

macdoncj

macdoncj

2016-02-26 10:46

reporter   ~0052577

Confirmed fixed in nightly build 1.3.0-rc.2-dev master-2a92f07.

dregad

dregad

2016-02-26 11:10

developer   ~0052578

Thanks for the confirmation !

Related Changesets

MantisBT: master b8fe45ae

2015-09-06 06:08:14

dregad

Details Diff
Fix error 1105 while changing bug status

Attempting to change the bug status from bug_change_status_page.php
(for example, acknowledging or confirming a bug) results in APPLICATION
ERROR 1105.

'last_updated' is an int in $t_existing_bug, but is read as string into
$t_updated_bug, which results in a failed exact compare (!==) at line
116.

Thanks to Alex Volkov for the research and proposed fix.

Fixes 0020075
mod - bug_update.php Diff File

MantisBT: master fe6b8cab

2015-09-06 12:54:41

vboctor

Details Diff
Revert "Fix error 1105 while changing bug status"

This reverts commit b8fe45aecd48cba57726bc8cba5940781d3fe0f9.
mod - bug_update.php Diff File

Issue History

Date Modified Username Field Change
2015-09-03 19:22 alex.volkov New Issue
2015-09-06 06:01 dregad Status new => acknowledged
2015-09-06 06:01 dregad Target Version => 1.3.0-beta.3
2015-09-06 06:11 dregad Changeset attached => MantisBT master b8fe45ae
2015-09-06 06:11 dregad Assigned To => dregad
2015-09-06 06:11 dregad Status acknowledged => resolved
2015-09-06 06:11 dregad Resolution open => fixed
2015-09-06 06:11 dregad Fixed in Version => 1.3.0-beta.3
2015-09-06 12:55 vboctor Status resolved => feedback
2015-09-06 12:55 vboctor Resolution fixed => reopened
2015-09-06 12:56 vboctor Note Added: 0051382
2015-09-06 17:46 vboctoradmin Target Version 1.3.0-beta.3 => 1.3.0-rc.1
2015-09-08 16:36 alex.volkov Note Added: 0051405
2015-09-08 16:36 alex.volkov Status feedback => assigned
2015-09-09 03:37 atrol Fixed in Version 1.3.0-beta.3 =>
2015-09-09 04:14 dregad Note Added: 0051420
2015-10-24 18:53 dregad Note Added: 0051703
2015-10-24 18:54 dregad Changeset attached => MantisBT master fe6b8cab
2015-10-25 00:46 vboctor Note Added: 0051707
2015-10-25 00:58 vboctor Note Added: 0051708
2015-10-25 01:06 vboctor Note Edited: 0051708 View Revisions
2015-12-06 02:55 vboctor Target Version 1.3.0-rc.1 => 1.3.0-rc.2
2015-12-20 18:46 dregad Status assigned => feedback
2015-12-20 18:46 dregad Note Added: 0052147
2015-12-26 20:10 vboctor Severity major => minor
2015-12-26 20:10 vboctor Note Added: 0052184
2016-01-26 13:47 alex.volkov Note Added: 0052392
2016-01-26 13:47 alex.volkov Status feedback => assigned
2016-01-27 06:58 dregad Note Added: 0052406
2016-02-25 15:57 macdoncj Note Added: 0052568
2016-02-25 18:53 dregad Note Added: 0052569
2016-02-26 08:08 dregad Note Added: 0052571
2016-02-26 08:08 dregad Relationship added related to 0020478
2016-02-26 10:46 macdoncj Note Added: 0052577
2016-02-26 11:10 dregad Status assigned => resolved
2016-02-26 11:10 dregad Resolution reopened => fixed
2016-02-26 11:10 dregad Fixed in Version => 1.3.0-rc.2
2016-02-26 11:10 dregad Note Added: 0052578
2016-06-12 00:42 vboctor Status resolved => closed