View Issue Details

IDProjectCategoryView StatusLast Update
0020075mantisbtbugtrackerpublic2016-06-12 00:42
Reporteralex.volkov Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformMicrosoftOSWindows Server 2012 R2 
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,

<pre>
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)
</pre>

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

Yes:
<pre>
array (size=29)
...
'last_updated' => string '1441627391' (length=10)
</pre>

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

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 02:08

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
Affected Issues
0020075
mod - bug_update.php Diff File

MantisBT: master fe6b8cab

2015-09-06 08:54

vboctor


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

This reverts commit b8fe45aecd48cba57726bc8cba5940781d3fe0f9.
Affected Issues
0020075
mod - bug_update.php Diff File