View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020075 | mantisbt | bugtracker | public | 2015-09-03 19:22 | 2016-06-12 00:42 |
Reporter | alex.volkov | Assigned To | dregad | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | Microsoft | OS | Windows Server 2012 R2 | ||
Product Version | 1.3.0-beta.2 | ||||
Target Version | 1.3.0-rc.2 | Fixed in Version | 1.3.0-rc.2 | ||
Summary | 0020075: 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 I have not tried on other database drivers or OSes. | ||||
Steps To Reproduce | Pull up a 'new' bug | ||||
Additional Information | MS Windows Server 2012 R2 / IIS v8.5 The culprit appears to be the following line in bug_update.php: '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 (!==): Changing the suspect line to the following resolves the issue: var_dump() from bug_update.php: 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) } | ||||
Tags | No tags attached. | ||||
I've reverted this since it broke both bug update and status update scenarios. |
|
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': 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) |
|
<pre> how does the MySQL driver return it to bug_cache_row(), as a string? Yes: I'll let @vboctor reply on the errors he got. |
|
Alex, Victor, none of you have provided any feedback... Where do we go from here ? |
|
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. |
|
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. |
|
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 ? |
|
Reducing to minor so it is not blocking, unless we have a repro and determine that is blocking. |
|
The issue is still present in 1.3-rc1 on Windows/MS SQL platform, same as before. The problem is due to the following:
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. |
|
Thanks for your analysis and feedback Alex.
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
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. |
|
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? |
|
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. |
|
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 |
|
Confirmed fixed in nightly build 1.3.0-rc.2-dev master-2a92f07. |
|
Thanks for the confirmation ! |
|
MantisBT: master b8fe45ae 2015-09-06 02:08 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 Details Diff |
Revert "Fix error 1105 while changing bug status" This reverts commit b8fe45aecd48cba57726bc8cba5940781d3fe0f9. |
Affected Issues 0020075 |
|
mod - bug_update.php | Diff File |