Bug (closed)

Blank screen after creation of new tasks/items


Nov 24, 2006
May 29, 2007
Nov 24, 2006 / pixtur
Aug 5, 2009 / rafael.dalpra

Attached files

47234 bytes / ID 3902 / Jan 30, 2007
Show Details

original report from Bruno Gonzalez:π

In our current streber test at work, there's a problem: we can do everything but adding new items (taks/bug/milestone). All we get after clicking "submit" is a completely blank page. The source code of the resulting page is shown empty (as if nothing was really transferred).
Some details:

-Last lines of _tmp/...log right after trying to submit a task and a bug:

Log 20061124121429 usertime offset = 3600 sec
Log 20061124121429 'brgonzalez' logged in from
Log 20061124121736 usertime offset = 3600 sec
Log 20061124121736 'jpatino' logged in from
Log 20061124121812 usertime offset = 3600 sec
Log 20061124121812 'jpatino' logged in from
Using latest stable version of streber as of 24-11-2006
Browsers: ie7, firefox1.5, firefox2, opera9


We already tried the "repair tables" command.

We've only tried the latest stable version of streber, so we can't tell if the bug was present in previous ones. The creation of users and projects went fine, but right after that we tried to create tasks and it failed.



12 years ago

This is especially tricky, because it is so hard to reproduce and no details are written to the errors.log.

Potential hints / Questions:π

  • php.ini and my.ini would help
  • enable debug output
  • Is mod_rewrite enabled?
  • Any errors in the apache error log?


12 years ago -

Hello Pixtur,

I've encountered the same problem. It's not really minor, it really makes streber useless :)

Configuration: Apache/2.2.3 (Win32) PHP/5.2.0 Mysql 5.0.27

Log after debugging had been enabled:

Log 20061204231541 admin@ -> projViewTasks /streber/index.php?go=projViewTasks&prj=13
Log 20061204231545 admin@ -> projViewMilestones /streber/index.php?go=projViewMilestones&prj=13
Log 20061204231548 admin@ -> taskNewMilestone /streber/index.php?go=taskNewMilestone&prj=13&from=9cc096684c66777f9cc575b66b68bceb
Log 20061204231548 admin@ -> taskEdit /streber/index.php?go=taskNewMilestone&prj=13&from=9cc096684c66777f9cc575b66b68bceb
Log 20061204231552 admin@ -> taskEditSubmit /streber/index.php

No errors in apache log.
I've tried with mod_rewrite enabled and disabled.


pixtur:I fixed some issues which might have caused this problem...

12 years ago

Please check with rev220

guest:Same problem

12 years ago (2. update 12 years ago) -

I have the same issue with the same configuration, using either the latest stable version or the .780 version.


-> move into attachment.

No errors in any log that I can see...

pixtur:Still cannot reproduce this problem...

12 years ago

As pointed out in you should enable display_errors in your php.ini. Otherwise the errors will be displayed to your apache errors. Please look at this file for any relevant output.

Additionally the output of phpInfo() could give further clues.

guest:Similar Problem, different server setup

12 years ago -

We are experiencing the same problem with Streber 0.0704 on our IIS6 box (IIS6, PHP5.02, MySQL5). Apart from the inclusion of PHP5, our installation of IIS6 is pretty much bog-standard.

We have enabled display_errors, but nothing shows. Additionally, PHP is not reporting any problems to the Windows Event Logs apart from the usual ones.

Whilst it is probably not at all relevant, we have tried this with both the ISAPI Extension and the CGI executable with identical results (we normally use ISAPI).

Any help or ideas would be appreciated as we are very interested in using Streber.

Thanks in Advance,

Alex J

pixtur:Reply to Similar Problem, different server setup

12 years ago (2. update 12 years ago)

Hi Alex,

I am really interested in fixing this bug, but until now I did not find a possibility to reproduce this behavior. If you find some time, please provide the following information (either as comment, a via email):
  • Output phpInfo()
  • error.log with debug-mode enabled
I wonder if this problem could be related to the IIS server. If your server would be accessible from remote (http & ftp), I would like to do some debugging.

Please also read .

Thanks for your help.

guest:Re: Reply to Similar Problem, different server setup

12 years ago -


Thanks for your reply.

I think dumping the contents of phpinfo() into a comment may be impractical, but I am more than willing to e-mail it and my error.log if you could supply an e-mail address.

I can open my IIS server for a while if you wish to do some debugging, but as you will doubtless appreciate, I do not wish to publicly broadcast FTP details, so again I would need a contact e-mail address.




12 years ago

Hi Alex,

my email is thomas at pixtut dot de

pixtur:potential problems...

12 years ago (6. update 12 years ago)

please add folowing lines to php.ini:

 display_startup_errors= On
 error_reporting = E_ALL & ~E_NOTICE

When directly accessing index.php I get following error:

 PHP has encountered an Access Violation at 04579E2F

The original problem occurred with pretty much any PHP related action on Windows IIS servers (when 5 was originally released) and was not specific to CURL.

Make sure you are using the latest version of CURL because PHP 5 does not support any version lower than 7.10.5.

Also, Note to Win32 Users: In order to enable this module on a Windows environment, you must copy libeay32.dll and ssleay32.dll from the DLL folder of the PHP/Win32 binary package to the SYSTEM folder of your Windows machine. (Ex: C:WINNTSYSTEM32 or C:WINDOWSSYSTEM).

I know the question is closed, but I thought I'd help anyway. If you open another question I probably won't catch it (I haven't been checking EE that often lately). Good luck.

from Expert Exchange

Also make sure, php memory is set to at least 16mb (in php.ini)

Some more links: But I can still not be sure, if this causes the problem.

guest:A problem solved (hopefully)

12 years ago -

This is actually not directly related to this bug, but the comment above.

The message "PHP has encountered an Access Violation at <some address>" message appears to have multiple causes. After trawling around for a while, possible reasons include the http account (or IUSR_<COMPUTERNAME> in Windows) not having write permissions to directories specified in php.ini; low-allocated memory to PHP; or the version of PHP 5 you were using.

The solution which eventually (or so it appears) to have worked for me is to enable Register_Long_Arrays within php.ini file (for an explanation of this directive, see http://php.net/manual/en/ini.core.php). This did not sort out the blank pagesbug as originally reported.

Secondly, enabling display_startup_error caused my IIS WWW Service to hang or get stuck in some form of an infinite loop. This may be down to my server's config, but I will continue to test to see if there is any particular cause. To be sure, I have now isolated Streber from all other IIS sites and application pools with no ill-effect so far. With any luck, this might help matters.



pixtur:Reply to A problem solved (hopefully)

12 years ago (2. update 12 years ago)

Thanks for your testing. Together with the account on your server we will nail down the problem and finally make streber run on IIS too.
When we have some better understanding, we should add some comments to the Installation-Guide.

pixtur:new problem with database:

12 years ago (2. update 12 years ago)

Error 20070208230542 ERROR:        dbdb.inc.php :  38 Database exception. Please read <a href=http://streber.pixtur.de/index.php?go=taskView&tsk=1272'> next steps on database errors.</a>
Error 20070208230542                 dbdb.inc.php : 250 -> MysqlException::__construct("Querry=INSERT INTO task(id,nam")
Error 20070208230542            dbdb_item.inc.php :1094 -> DB_MysqlStatement::execute("", int1)
Error 20070208230542       pagestask_more.inc.php :1269 -> DbProjectItem::insert()
Error 20070208230542 stdclass_pagehandler.inc.php : 719 -> taskEditSubmit()
Error 20070208230542                     index.php : 209 -> PageHandler::show("taskEditSubmit")
Error 20070208230542 
Error 20070208230542      Variables in __construct():
Error 20070208230542                       message = Querry=INSERT INTO task(id,name,short,date_start,date_closed,status,prio,for_milestone,resolved_version,resolve_reason,description,is_folder,is_milestone,is_released,time_released,completion,parent_task,estimated,estimated_max,issue_report,label,planned_start,planned_end,view_collapsed,category,order_id) VALUES('23','blabla','','2007-02-08','0000-00-00 00:00:00','2','3','0','0','0','','0','0','0','0000-00-00 00:00:00','0000-00-00 00:00:00','0','0','0','0','0','0000-00-00 00:00:00','0000-00-00 00:00:00','0','0','0')
Error 20070208230542 
Error 20070208230542                          code = NULL
Error 20070208230542                       sql_obj = OBJECT
Error 20070208230542                   mysql_error = Data truncated for column 'completion' at row 1
Error 20070208230542    v0.0792, taskEditSubmit, from,  uri:/streber/index.php
Error 20070208230542

Fixing this bug was actually easy: But it is frustrating, that I cannot reproduce such bugs on my on XAMPP development environment. I already added following line to my.ini:

But it seems to have no effect at all. :(

guest:Thanks for the bug fix

12 years ago -

I'd noticed that you had fixed the bug as I had just connected to do some of my own investigating about the time you uploaded the amended files. Thanks for fixing this, and I will build up a separate Streber installation to test it under fire.

As I had experienced this error following the upgrade to 0.0791, I had been experimenting to see if I could track down the possible source. Interestingly, if I copied the actual SQL INSERT statement, and then executed it directly to the database through a SQL tool like sqlYOG it worked. So, is this possibly down to the connector between PHP & MySQL? It might be something a simple to a mismatch of versions of the two.

I've been trawling through my own my.ini and the line sql-mode has not been set (i.e. it is commented out). As I am running a pretty much default installation of MySQL 5, I can only presume that this the default setting. I can only assume that this is a backward compatability choice by MySQL for users migrating from v3.x or 4.x.

That said, the STRICT_ALL_TABLES and STRICT_TRANS_TABLES modes were added to MySQL in version 5.0.2, but I am running MySQL 5.0.18. So even if they were present, MySQL should ignore them.

To test this, I think that I might restore 0.0704 to a different location, add your sql-mode line to my.ini and see what happens. Also, I may build up a Virtual Server installation to see if there is different reaction for the latest version of MySQL as this has me puzzled.



pixtur:yeah, it is strict...

12 years ago

Yesterday night I spent some more time with MySQL and finally figured out, how to set it into strict mode with Streber (the my.ini file has always been ignored).

This will help us to find such issues much better. Thanks for your help! The next bug-fix will probably be out Sunday.

guest:Old with new

12 years ago -

I was experiencing this problem previously, but it has gone away completely when I installed mySQL 4.1 along with Streber 0.792.
Everything works perfectly now.


12 years ago

But it should work with mysql 5 as well :) I just spent another hour testing with strict mode and found another few issues. I there are no complains about the v0.0794 I will probably release 0.08 this weekend...

turner:Reply to yes...

12 years ago

Correct, the new 0.0796 version works fine with mySQL 5, so far as I can see.