| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008538 | mantisbt | bugtracker | public | 2007-11-02 10:37 | 2009-06-26 12:01 |
| Reporter | tinjaw | Assigned To | giallu | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| OS | linux | ||||
| Product Version | 1.1.0rc2 | ||||
| Summary | 0008538: View Issues page isn't fully rendered when Assigned To field is set to [any] (the default) | ||||
| Description | View Issues page isn't fully rendered when Assigned To field is set to [any] (the default). It stops after printing the filters. The source of the HTML page returned confirms this. | ||||
| Steps To Reproduce | Using an existing Mantis setup, upgrade to a4, rc1, or rc2. Go to the "View Issues" page and it will not fully render. If you select to filter on "Assigned to" with a value other than '[any]', the page will properly render. | ||||
| Additional Information | This has been reported by several people, including myself, in the forums. I will attach screenshot and the HTML source. | ||||
| Tags | blank screen | ||||
 |
When Javascript is disabled in the config_defaults_inc.php file the result is slightly different. No errors are displayed, even though $g_show_detailed_errors and $g_stop_on_errors are ON, and all $g_display_errors are set to 'halt'. |
 |
I see this too. I also get missing bugs when the bug status is 'confirmed' but it is assigned to me. As already stated, the page is not finishing rendering. [edit] - I looked at the source for my half-rendered page. The last line (line 348 on my page) in the html was 2287 characters long, representing the entire (well, nearly 3 lines) bugs table . The same page on this site has plenty of line breaks for this table, and continues on. the lines just before the long line look normal ... hope this helps |
 |
has duplicate 0008579 |
|
|
I'm getting this and I'm running PHP 5.2.4 on a shared server. Could this be a PHP 4/5 compatibility issue? Also running MySQL 5.0.45, if that's any help. |
|
|
PHP: 5.2.3 (apache)MySQL: 4.1.22-max-logon a on a shared server where php 4 and mysql 5 are available as well |
 |
Is anyone with this problem able to find some error messages in the apache log? |
|
|
No access to Apache log (shared server) BUT - page does render ok in PHP4. I can change the default PHP interpreter via the .htaccess file. changing it to PHP5.2.4 makes the page stop rendering. It seems to render fine, or at least finishes rendering, in PHP 4.4.7. Looks like there is broken backwards compatibility in PHP5 (we know that) that is crashing the code on that page. That Clunk you just heard is the limit of my knowledge on PHP. Educated onlookers, feel free to step in... FYI - my host is deprecating PHP4 and changing their default to PHP 5, as per their following announcement, so falling back to PHP4 is not a viable solution. System updates; General; ICDSoft will continue supporting PHP 4 until possible, but we urge our customers to look for ways to make their PHP applications suitable to run on PHP 5. After the end of 2007, we may be forced to discontinue any support for PHP 4, in case of a discovered security vulnerability which may endanger the integrity of our hosting environment. |
|
|
Well. Mantis will probably be php5 only starting from 1.2 http://www.mantisbt.org/blog/?p=15 But we need to fix 1.1 to work with php5 |
|
|
actually yes.. without manual error handler and only when accessing view_all_bug_page.php with [any], I get one of these: [Fri Nov 16 13:20:49 2007] [notice] child pid 6446 exit signal Segmentation fault (11) doesn't help much though, does it? |
 |
No problem on my server. (apache 2.0.59/ PHP 5.2.5-pl0-gentoo) |
|
|
I do have the problem, and my host is running MySQL 4.1.8a-Debian_1 |
|
|
Still happens with RC3. I've been able to track it down somewhat, and at least on my system, it seems to get stuck in one of the user_api functions. Something weird is happening with the $row variable (sometimes is contains values, even though it isn't initialized, and at other times it's empty when it should contain stuff), and this causes some functions to just drop dead (db_fetch_array might be the end-point, but that's more a symptom than the cause). To just avoid the whole issue altogether, try turning off the $g_show_assigned_names flag in config_defaults_inc.php. (This determines whether the assigned persons name will show up in the Status column. Something I can live fine without...) Also - could somebody please change the severity of this bug to "Crash"? |
|
|
This maybe happen when memory_limit(php.ini) is too small. |
|
|
Yeah, some memory corruption would definitely make sense in the kind of behavior I've seen. P.S. I did find out my memory_limit, and it's set to 256MB... |
|
|
Possible but not likely. The page renders ok in PHP 4 on my (shared) server. My PHP memory limit is 80MB. |
 |
I am seeing this problem on boxes with 90MB+ PHP memory limits. |
|
|
I am unable to find anything in the error logs about this problem. |
 |
FYI: I had the same problem, using an old 'wamp' installation on windows XP:
Deinstalled the above, then installed WampServer2.0a.exe, and problem was solved..:
|
|
|
Running RC2 with PHP 5.2.5 & MySQL 5.0.45. Still have same issue. Have not tried re-install but this may not be a practical option for those with working installations anyway (mine is still a tester). I will try re-install when I get time (just moved house). It seems that the HTML for actual table of bugs is being rendered without any HTML-tidy like formatting, all in the last line of 2353 characters. |
 |
user0815 - are you able to get a gdb stacktrace for that so we can see why php might be crashing? ;/ Paul |
|
|
As I'm on a shared server, this might not be possible. Or is there a way? [Fri Dec 7 15:28:45 2007] [notice] child pid 7892 exit signal Segmentation fault (11) Still getting these.. |
|
|
Has anybody tried disabling the $g_show_assigned_names option (as described in note 0016309 above)? Did it make any difference? |
|
|
Just tried it. Yes, it makes a difference. When disabled, everything works just fine. |
|
|
Do get this against php 5.2.5 ? |
|
|
Me? As described I'm on a PHP 5.2.3 (apache), MySQL 4.1.22-max-log Shared Server. |
 |
shared serverPHP version: 4.4.7MySQL version: 4.1.21-standardMantis: 1.1.0 stableI had the same problem and added this line below in config_inc.php and it worked: $g_show_assigned_names = OFF; Thank you for this software. nospamturker_ozt@yahoo.nospamcom |
 |
I have exactly the same problem and want to see the assigned names. So the problem is either a combination between the assigned to name and the status in the filter, or crashes on a particular value within the bugs when they have one of these two statuses. Another workaroundIf you have not too many users, you can workaround by choosing "advanced filters" and then multi-select all the users in the "assigned to"-field. Afterwards, apply the filter and then switch back to simple filters if you'd like. |
 |
shared serverPHP version: 4.4.7MySQL version: 4.1.14Mantis: 1.1.0 stableHad the same problem, was resolved by adding $g_show_assigned_names = OFF; to config_inc.php Also experiencing issue 0008537, which appears to be similar behavior. |
|
|
After some provider updates (e.g. Apache 5.2.5) it now works, even without the mentioned workaround. |
|
|
Shared Server (Apache) $g_show_assigned_names = OFF; workaround worked for me. Page source looks fine. Thank you to the developers for this software - it is the best of its kind. |
 |
shared Unix server with php5 and php4PHP version: 5.2.5MySQL version: 5.0.51Mantis: 1.1.1 stableWe also have this problem in the "View Issues" page. The workaraound with "$g_show_assigned_names = OFF" above works, but wee strongly need the "assigned to" names in the page. It seems that it has something do do with the lang-files, because the site renders some more lines (but still no tickets to see), if I change the language from german to english. Enclosed to this memo I give you a link to a database-sql (import it as latin1) so you can repoduce the issue (18k) - only one User "Admin" with password "admin". http://members.inode.at/k.eske/ANNONYM_TEST.zip It would be nice if there will soon be a patch to solve this. Many thanks, Karl |
|
|
I've added a log-File (all that we have) in Excel-format, so you can sort by error-code (using excel-Autofilter-function). => http://www.mantisbt.org/bugs/file_download.php?file_id=1707&type=bug added full-logfile for 24.2.2008 (mantisTEST is v 1.1.1 with the problem in view all): |
|
|
Could you tell us the status of this ID please giallu? Bevore some weeks I added all information what you wanted and it seems that this ID is presumed dead. We will update to 1.1.1 but we can not and our provider could not help us, because it is a bug in mantis-filters in connection with our server configuration (yes I see that this is running on your server). |
|
|
The problem is that I can't reproduce the problem here and additionally it's not even clear what all these "mee too" installations have in common. Is there anyone that can provide me with a shell account to a machine where this is happening? |
|
|
I am only able to give you an account to our mantis test enviroment, where we set up new versions of mantis bevore we put them into production. http://www.ebv4all.at/mantisTEST/ is running on v.1.1.1 and there are some tickets. So you are able to play around and you will be able to see the bug. Password and user are giallu Please tell me if that has helped you, because I must terminate the accound after some time. |
|
|
It exhibits the problem "live", but it does not help any further. Do you happen to have a shell account for the server where that is running ? With "shell account" I mean something accessible with ssh |
|
|
I have a shell account but I am not allowed to give you the ID and password, because it's a shared server and we have our production systems running on it. Unfortunately its not possible to create a second accound and I am not fit in using the shell. Could you tell me what I should do? If you would be in austria this will not be a problem to do this together. |
|
|
Dear giallu, in reconciliation with our IT-manager we made an update to mantis 1.1.1 with using the workaround "$g_show_assigned_names=off" to use the new features. But we ran in many problems with v.1.1.1, which are described in the IDs 0008537 and 0008727. "Error : [No Error] So we had to make a rollback to v 1.08 and erverything is running very well. I don't know how I should solve that bug and in my opinion this bug is not in the filters, it's in the rendering modul by using a shared server. I made some screenshots from the server variables and settings http://www.mantisbt.org/bugs/file_download.php?file_id=1730&type=bug maybe this will help you to find the cause. Yours, |
|
|
The only thing that would really help is having a backtrace of the function calls when the problem happens. This should be possible with the xdebug php extension, see the presentations at http://talks.php.net/index.php/Debugging for more details |
|
|
Dear giallu, thank you for the hint with Xdebug. I was not able to install this on our shared host by http://www.inode.at , so I asked our provider if they could debug this for me. "wir haben uns die Logs angesehen und entweder kamen wir auf einen
They found in the logs an error 302 and a OK-message 200: Error one - Tickets are not opening: Im Browser (mit live http headers) sieht man bei dem Test mit der Nummer 8 folgendes: GET /mantisTEST/view.php?id=8 HTTP/1.1 Host: www.ebv4all.at User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031704 Minefield/3.0b5pre Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Error 2 - View Issues page isn't fully rendered when Assigned To field is set to [any] (the default): Referer: http://www.ebv4all.at/mantisTEST/view_all_bug_page.php?page_number=1 Server: Inode Webhosting "Anscheinend gibt das Script nichts zurück. Dass die Seite nicht fertiggeladen wird, scheint deshalb zu sein, weil das Script abzubrechen scheint. Wieso das so ist können wir auch nicht feststellen." It sems so that the script is delivering nothing. The page is not be loaded complete, because the script is breaking off. The cause of this inode could not find out. Yours, |
|
|
Dear giallu, our provider inode gave us a link to the php-configuration - please have a look on it: http://eb000043.host.inode.at/phpinfo.php and tell me if this is helping you. It seems so that mantis 1.1.1. uses a statement that makes troubles with load-balancers, so we get the error. Inode said that this will be able to locate with the link above. Yours, |
|
|
Caching could be an issue, but looking at the phpinfo I note you are running the Zend Optimizer, which created some problems in the past to other projects (IIRC dokuwiki). Can you try to disable it temporarily and repeat the test? thank you |
|
|
Dear giallu, I asked inode about your wish to disable Zend Optimizer and they told us that this is not possible, because other customers are using Zend Guard scripts. Inode has made a segfaults-strace http://www.mantisbt.org/bugs/file_download.php?file_id=1760&type=bug - please have a look on it and tell me if you are able to find something out. Additional I have made an install of our test-instance on a Server from a friend with Zend optimizer and without caching and everything is running. Unfortunately we could not move our production to this server. I'm waiting for your reply. Thank you very much, |
|
|
This is what I can find in my phpinfo concerning the zend-optimizer. This program makes use of the Zend Scripting Language Engine: Zend Optimizer The only way I can change php-settings is via a .htaccess file. If you can give me the code I have to put in there to disable the zend-optimizer, I will test it for you and see if that solves the problem... |
|
|
I think you can try with: php_flag eaccelerator.enable 0 See also what seems to be the very same problem with drupal: |
|
|
Gially, I tested it with these values: but the problem is still not solved. You can take a look at my phpinfo on this location: http://bugs.altum.be/phpinfo.php I will delete this file soon, so please take a look asap. |
|
|
Dear giallu, our provider inode has made an update to Zend Optimizer v. 3.3.3 and everything is running very well. :)))))) Thank you for your support! Yours, |
 |
I had the same problem on a dreamhost.com server (Linux dinar 2.4.29)
I found a work around for this issue by downgrading to php4 and placed it in the base install directory. |
|
|
So, given comment 0008538:0017602 I'm leaning toward closing this as "no change required" but... Maybe it could be smarter to add a check for this known issue on check.php? |
|
|
Dear giallu, I think you can close this ID, too. Yours, |
|
|
Ok, we will track the change on 0009997. |
