View Issue Details

IDProjectCategoryView StatusLast Update
0008267mantisbtsqlpublic2019-12-13 18:06
Reporteropi Assigned Todregad  
Status closedResolutionno change required 
Summary0008267: APPLICATION ERROR #203 - A number was expected for filter.


Here is a step by step procedure to reproduce the issue:

  1. log into mantis
  2. click "View Issues"
  3. change nothing and click "Apply Filter"
    on the follow page i get an Error:
    A number was expected for filter....

(The Bad thing it's not displayed in IE or Firefox but
on my used Browser)

If i enable "$g_show_detailed_errors" the Page show follow:
(the paths are truncated to keep the Report short)

Begin Error Message

A number was expected for filter.
Please use the "Back" button in your web browser to return to
the previous page. There you can correct whatever problems were
identified in this error or select another action. You can also
click an option from the menu bar to go directly to a new section.

Full path: pub/mantis/core/gpc_api.php
Line: 76
Variable Value Type
p_var_name filter string
p_default 0 string
t_result Apply Filter string
t_val ApplyFilter string

Variable Value Type
0 filter string
1 0 string

Filename Line Function Args
/pub/mantis/core/gpc_api.php 76 trigger_error ( '203', 256 )
/pub/mantis/view_all_inc.php 106 gpc_get_int ( 'filter', 0 )
/pub/mantis/view_all_bug_page.php 58 include ( '/pub/mantis/view_all_inc.php' )

Previous non-fatal errors occurred. Page contents follow.

End Error Message

I guess i get this because all types are strings but the
function expect a Value form type Number!?

I hope you can have a look at this and hopefully also fix the issue.
Many thanks in advance and keep you very good work.

Best Regards
Frank (Opi) Weber





2007-08-16 19:35

reporter   ~0015441

Last edited: 2007-08-16 19:37


I investigate the issue a little bit.

Is it possible that in the File view_all_inc.php in the Lines
106 and 195 the called function should be gpc_get_string() instead
of gpc_get_int()? At least then i become no Error Message here.

Best Regards
Frank (Opi) Weber



2007-12-10 04:15

reporter   ~0016424


I got the similar error with Mantis 1.0.8:
A number was expected for relationship_type.

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

Full path: /data/Q03PHP/httpd-dvpt/htdocs.dvpt/core/gpc_api.php
Line: 76
Variable Value Type
p_var_name relationship_type string
p_default -1 string
t_result any string
t_val any string

Variable Value Type
0 relationship_type string
1 -1 string

Filename Line Function Args
/data/Q03PHP/httpd-dvpt/htdocs.dvpt/core/gpc_api.php 76 trigger_error ( '203', 256 )
/data/Q03PHP/httpd-dvpt/htdocs.dvpt/view_all_set.php 230 gpc_get_int ( 'relationship_type', -1 )

I corrected it replacing in view_all_set.php line 230 a gpc_get_int()? by a gpc_get_string() BUT I do not manage the consequence of that.


2008-06-27 10:41


gpc_get_int.diff (486 bytes)   
Index: core/gpc_api.php
--- core/gpc_api.php	(revision 400)
+++ core/gpc_api.php	(working copy)
@@ -71,7 +71,7 @@
 		$t_val = str_replace( " ", "", trim( $t_result ) );
-		if ( ! preg_match( "/^-?([0-9])*$/", $t_val ) ) {
+		if ( ! sscanf($t_val, "%d", $t_val) ) {
 			error_parameters( $p_var_name );
 			trigger_error( ERROR_GPC_NOT_NUMBER, ERROR );
gpc_get_int.diff (486 bytes)   


2008-06-27 10:45

reporter   ~0018206

I've uploaded a small patch that changes the behaviour of gpc_get_int. This should fix these problems.

I changed it to use sscanf so that it would still work if attempting to get an integer value from something parseable, but not containing only digits.



2008-07-15 15:51

reporter   ~0018566

I can't see anything wrong with the original regex,
How exactly do you get this to occur ?

(i've never seen this myself)




2008-07-15 16:01

reporter   ~0018569

grangeway, You can get it to occur in many ways, one is entering a strange id for a bug: . My patch basically does a best effort attempt to read a number from the beginning of $t_val, and if something's there that fits (even if something on the end isn't numeric, etc) it uses that.



2008-07-28 15:01

reporter   ~0018792

Why you ask how exactly i get this to occur?
Please read the initial comment about the Issue.

But here again:
Turn on "$g_show_detailed_errors" in config_defaults_inc.php
Then follow the 3 steps to reproduce the issue:

  1. log into mantis
  2. click "View Issues"
  3. change nothing and click "Apply Filter"

Now you should see the errormessage...

Best Regards
Frank (Opi) Weber



2008-12-08 19:49

reporter   ~0020298

Last edited: 2008-12-08 19:56

I think that the filter storage may be corrupted. Could you post the results from the following query?

SELECT * FROM mantis_filters_table WHERE user_id=<your userid>;

Another thought is that your browser has remembered a URL with broken information in it. Could you clear your browser cache, history, and cookies for the site?



2008-12-10 08:09

reporter   ~0020316

Hmm i really don't know what you mean but i do the follow:

Log in to phpMyAdmin (2.11.4), select the correct Database,
click "SQL", enter your query (with my userid =2), click "OK",
wait for the result, click Export (in the last line of the right
side window) and on the follow page select "send" and click "OK"

The resulting file will be attached to this Issue.

I hope that is what you want. If not please let me know.
BTW: here is a patch for this issue provided by bbryant. Does
this patch not work or why it's not yet included in mantisbt?

BTW: i still run the old Mantis 1.2.0a1 Version.
BTW2: Is here a chance to get a copy of the git version
back to svn? Or at least a permalink from which a user (betetester)
can download a recent Version?

Best Regards
Frank (Opi) Weber

2008-12-10 08:10




2008-12-10 14:09

reporter   ~0020324

bbryant: I think that given your example, we are doing the right thing. There can never be a bug 826--7. Your patch doesn't change this (It just accepts the erroneous data and displays bug 827 instead).

opi: The saved filters look correct. We do may use a browser cookie to save the filter information between sessions. It is possible that this has been corrupted. Can you log out of Mantis, clear the cookies related to the site, and retest this?



2008-12-10 14:34

reporter   ~0020325

opi, You can find nightly snapshots at



2009-01-12 11:19

reporter   ~0020589

thraxisp thanks for the link for the nightly snapshots.
(it was a lot easier with SVN) and sorry for the late answer.

I test the issue again with the latest version and the
issue still exists. So i had again a look at this:

In view_all_inc.php (Line 164) is this call:
$f_filter = gpc_get_int( 'filter', 0);

so i add some debug output to this function and get
for the variables follow output:

$t_result=Apply Filter

So call_user_func_array( gpc_get, $args ) return 'Apply Filter'
and that is exactly what was send for filter from the Browser:
httpdebug says: POST ...&dir_0=DESC&search=&filter=Apply+Filter

So the fault is in this line (received from the Server):
<input type="submit" name="filter" class="button-small" value="Apply Filter" />

because the Browser add the name="filter" with the value="Apply Filter"
to the POST string (&filter=Apply+Filter) which triggers the error.

The easy solution is to remove the name="filter" from the input tag,
which is full html conform.
e.g. <input type="submit" class="button-small" value="Apply Filter" />

I guess here are some other submit buttons with a not needed name in
the mantis tree. Maybe anybody can check this?

Best Regards
Frank (Opi) Weber



2009-01-12 11:30

reporter   ~0020590

i forget to mention thet the page is buld in view_filters_page.php

BTW: why the action = "view_all_set.php?f=3"
i think action = "view_all_set.php?" should work too!?

Best Regards
Frank (Opi) Weber



2019-12-03 09:59

developer   ~0063180

We are resolving this issue as "no change required", because it was reported against an old version of MantisBT which is no longer supported.

We recommend that you upgrade to the latest stable version [1]; if after doing so the problem still exists, do not hesitate to reopen the issue.


Issue History

Date Modified Username Field Change
2007-08-16 04:30 opi New Issue
2007-08-16 19:35 opi Note Added: 0015441
2007-08-16 19:37 opi Note Edited: 0015441
2007-12-10 04:15 plume7 Note Added: 0016424
2008-06-27 10:41 bbryant File Added: gpc_get_int.diff
2008-06-27 10:45 bbryant Note Added: 0018206
2008-07-15 15:51 grangeway Note Added: 0018566
2008-07-15 15:51 grangeway Status new => feedback
2008-07-15 16:01 bbryant Note Added: 0018569
2008-07-28 15:01 opi Note Added: 0018792
2008-12-08 19:49 thraxisp Note Added: 0020298
2008-12-08 19:56 thraxisp Note Edited: 0020298
2008-12-10 08:09 opi Note Added: 0020316
2008-12-10 08:10 opi File Added: mantis_filters_table.sql
2008-12-10 14:09 thraxisp Note Added: 0020324
2008-12-10 14:34 thraxisp Note Added: 0020325
2009-01-12 11:19 opi Note Added: 0020589
2009-01-12 11:30 opi Note Added: 0020590
2009-01-12 18:39 siebrand Tag Attached: patch
2019-12-03 09:59 dregad Assigned To => dregad
2019-12-03 09:59 dregad Status feedback => resolved
2019-12-03 09:59 dregad Resolution open => no change required
2019-12-03 09:59 dregad Note Added: 0063180
2019-12-13 18:06 atrol Status resolved => closed