Bogus PHP bug on Mac OS X...

Hi,

I am trying to get attention placed on a crippling bug in PHP. You can view it at http://bugs.php.net/bug.php?id=25394

It has been labeled bogus twice as the PHP maintainers cannot reproduce the bug. This is odd since I can get the beast to bonk out on every Mac I can get my hands on.

The bug is tickled by any script in the 8,000 to 10,000 line range. The test case is simple $x = 1; done 8041 times. The script crashes, and prints an error to the error logs. A no fail test would be to do $x = 1; about 10,000 times.

The crash will not hoop your system, and PHP will recover within two seconds.

The PHP maintainers, windows and unix users I have contacted in the last month have accomplished over 100,000 lines as expected, but no-one from the Mac community but me has been able to even give it a try.

I guess what I am looking for here is a sanity check, as I seem to be the only one who can make this thing happen... and that is 100% of the time.

Please give it a whirl and post back here what you have found. Then I can maybe get this thing fixed. If it crashes it would be great if you would also leave a comment and vote at the bug page mentioned above.

Thanks,
Mark.

I gave it a whirl.. and no problems at all.. I just did a for loop that went through 9000 times.. then tried it again at 10000 and still no errors... Im on a Mac most definitely

Whoops read your post wrong.. you didnt say a for loop you said that many lines.. Well I did that.. and including the open and ending php tags I could get in 7998 lines, if I added one more line.. the script would crash.. so there you go.. crashed for me also

Murlyn,

Thank you, thank you, thank you. I could go on...

Funny enough, I am ecstatic to here your script crashed. Your help will be used in two ways. First, it proves this thing can be tickled by other people than me. Second it presents some insight into what the maintainers may have been trying that would not crash - creating a loop.

Your comment at the bug database about why this is useful pretty much hit the nail on the head. Yes, I do write scripts that long, and yes, I was hoping that if for no other reason they would fix it as the possible side effect of other bugs or performance hits.

I can't thank you enough.. now if more people would give it a shot I could truly flip the bug to OPEN with confidence.

Thanks one last time,
Mark.

Merlin,

Whoa!

Where did your comment go at php.net? Do they get deleted if a bug is left bogus?

At the same time I recieved an email saying you put a message here. Not here. The stuff headaches are made of.

*Pretending that message made it here* yes everyone has had the same response about modularity and rediculouse script length and what not. Fact is, the bug happens when the code is split up with include() 's as well.

Mark.

Im not sure what to say.. that is strange that the message was removed.. or lost or whatever happened to it.. I sent a message to the php-general mailing list since I belong on it also and Ill see what they have to say about it.

if I come across any type of answer Ill try and post it here.

This is what I wrote:

Well I saw a post on a forum talking about a certain bug that PHP has for Mac OS X.. so I thought.. Im on OS X, I should see if that bug is real since on bugs.php.net they say it's bogus, which you can view here:

http://bugs.php.net/bug.php?id=25394

So I tried it out.. at first I created a loop that assigned $x = 1; a whole bunch of times, but that didn’t crash anything.. I then read the authors post a little closer and I realized it was a number of lines problem.. so I created a php file that had a whole bunch of $x = 1; commands in it.. 7996 to be exact.. add the opening and closing php tag.. that made 7998 lines.. the script still worked.. Now I added one more line so that there were 7999 lines and guess what? Yep you got it.. my script didn’t work anymore. With the author it looks like it took 8014 lines instead of my 7999 lines to break it.

I thought this was strange and it looked like the author of the php bug report was indeed on the up-and-up and it wasn’t a bogus bug as bugs.php.net had said it was.

So I thought to myself.. well I should post to bugs.php.net and tell them that I too can reproduce the bug. So I did.

Well to make an already long story short.. it looks like after a couple of hours bugs.php.net has removed my post.

My question to you is.. is there any reason why they would remove my post? For me.. since I do not write that many lines of code for one run of a script it really didn’t matter much to me, but since they removed my post.. it's beginning to make me wonder what's going on..

Hopefully someone can shed some light!

Cheers and thanks!

Rick

Hi,

There is so much to post I may miss it all...

Beautiful email to the QA people. I hope they listen this time.

There was another anonymous comment that did not stick added this morning to bug.php.net. It went like this...

ID: 25394
Comment by: eugene at fsck dot net
Reported By: mark dot meredith at shaw dot ca
Status: Bogus
Bug Type: Reproducible crash
Operating System: MAC OS 10.2.6
PHP Version: 4CVS-2003-09-06 (stable)
New Comment:

I get the same problems with php-4.3.3 built with "--

enable-memory-limit" as recommended, as well as

"memory_limit = -1" in php.ini.



I ran a simple PHP script that contains 8192 identical

lines that perform a simple variable assignment:



$x = 1;





My gdb session:

---------------

(gdb) run ~/crash.php

Starting program: /Users/eugene/src/php/php-4.3.3/sapi/cli/

php ~/crash.php

Reading symbols for shared libraries . done



Program received signal EXC_BAD_ACCESS, Could not access

memory.

execute (op_array=0x134de8) at /Users/eugene/src/php/php-

4.3.3/Zend/zend_execute.c:1027

1027 EX(Ts) = (temp_variable *)

do_alloca(sizeof(temp_variable)*op_array->T);

(gdb) bt

#0 execute (op_array=0x134de8) at /Users/eugene/src/php/

php-4.3.3/Zend/zend_execute.c:1027

#1 0x000c704c in zend_execute_scripts (type=4231488,

retval=0x0, file_count=3) at /Users/eugene/src/php/php-

4.3.3/Zend/zend.c:885

#2 0x0009c4ec in php_execute_script (primary_file=0x0) at

/Users/eugene/src/php/php-4.3.3/main/main.c:1723

#3 0x000d9e34 in main (argc=2, argv=0xbffffc94) at /Users/

eugene/src/php/php-4.3.3/sapi/cli/php_cli.c:818





Mac OS X 10.2.8, build 6R65.



$ uname -v

Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003;

root:xnu/xnu-344.49.obj~2/RELEASE_PPC

$ gcc -v

Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs

Thread model: posix

gcc version 3.3 20030304 (Apple Computer, Inc. build 1493)

... I assume this was posted by a guy named Eugene. Which is a different person entirely from a thread I found at entropy.ch tp://www.entropy.ch/phpbb2/viewtopic.php?t=523 (outdated link removed) who's name is Randy. I am hoping that Randy will post here from now on as, if you read the thread, you will find there will be no adequate help given at entropy.ch for the problem.

Because now another comment has been deleted I am beginning to think it must be automatic for BOGUS bugs. Problem is, they will change it back to bogus very quickly if I edit the bug status back to OPEN.

Mark.

Yep he's a guy that is on the php-general mailing list and he told me that he had posted there.. maybe you should reset it to open again if that will make our posts stick... You don't happen to have a copy of my post do you?

Mulyn,

Your comment...

http://news.php.net/article.php?group=php.bugs&article=48399

Eugene's comment...

http://news.php.net/article.php?group=php.bugs&article=48413

I could set it back to open, but they will flip it back very quickly. Since the links above prove they have seen the comments, along with the fact that the comments do get published for at least a little while, it is hard to say what is happening. All this would suggest that someone may be editing this by hand. I mean, why would the system be that latent to delete the comments?

If you have the time to repost your comment, I will throw it to OPEN, though. What is there to lose? I have copies of everything. I just do not want to poke the dragon too much. They may block me or something as this will be the third time I have edited this bug from BOGUS.

Ideas, comments?

Thanks,
Mark.

Let's wait a bit.. Im resending the email to the php-general mailing list to see what comes of it

Mulyn,

I am not sure why the wrong people keep looking into this thing. Hopefully the resend of that masterpiece of an email will get to the right people this time.

I just took a look the last email thread http://news.php.net/article.php?group=php.general&article=164740

... which essentially describes exactly the problem I have encountered many times. I do not know whether it is ego's or I am just not wording this bug right. Jay wrote in that thread...

Because it is not a bug, it is bad code design! 8000+ lines of $x = 1; is just downright goofy! Did you happen to try it with 8000+ repeated blocks of any other type? My bet is that it would quit then too.

... which I believe means he actually thinks I write scripts that assign x to 1 ten thousand times and call it a day.

That is just funny.

Same deal with the actual bug page. Jani refered to my test script as "stupid". Wow.

That is just stupefying.

And countless others have had similar comments.

I need people to understand that the "stupid" and "goofy" $x = 1; script is just a test case that represents some very tight and modular scripts that actually exceed the crash length mentioned. You are the only one who has figured that out so far.

Mark.

Im not sure either As programmers we are supposed to think expansively, all encompassing, take everything into consideration.. and yet so far it seems that there is a lot of linear thinking going on Hopefully we'll figure it out though..

Hi again,

A lot has unfolded in the last few hours. I was able to contact the project manager of Kronophobia- a school calendaring system. And let me tell you, I should now only refer to him as "Man of Action". He posted an alias to my bug report at bugs.php.net. It takes care of a lot of issues surrounding this bug.

You can view his report at PHP :: Bug #25738 :: Long Scripts Consistently Segfault

I can smell that bug baking under a magnifying glass already.

I should also point you to tp://www.entropy.ch/phpbb2/viewtopic.php?t=523 (outdated link removed)

... I just do not know what to think about what happened there. Anyone?

Mark.

I guess at this point we're going to have to wait it out.. and see what happens.

I've been reading this thread, and I follow it, I think. Are you guys saying that php has a bug in it, that once the code reaches greater than a set amount in lines, it just dies? And this amount is different for everybody, but is generally greater than 8000 lines of code? And they keep ignoring it?

Seems like this is a major bug and somethig that should be attended to.

Emrys,

Yep, that is pretty much it. What this bug means is that no scripts can be any longer than about 9,000 lines. Doesn't matter if you break the script up into multiple includes(); or if you fiddle with compile and runtime options. A serious road block for Mac PHP developers.

Amazingly enough, yes, we have had a lot of trouble getting any attention placed on this. I have been working on this thing for almost a month, and Murlyn has just gotten a taste of what I have been having to deal with. Basically, everyone keeps getting so hung up on the thought of writing an 8,000 line script that they brush it off as an extremely rare crasher, or not a crasher at all. This is boggling as even the recent PHP survey http://www.zend.com/zend/php_survey_results.php indicates that at least some developers are writing some substantially long systems. Just look at the seventh poll question from the bottom.

I am still not ruling out some sort of human error on my part here, as it just seems too hefty a mistake to have gone unnoticed for so long (I have tested back to 4.3.0). But as the days creep by, more and more people are able to say they can reproduce it, and less and less people are flaming.

I have actually gotten into some flame wars with people over this, and that just isn't like me. The bug is truly bringing out the worst in me.

Murlyn,

Funny enough, your comment was removed from the new bug page PHP :: Bug #25738 :: Long Scripts Consistently Segfault , I suppose to make more room.

I tested the snapshot last night as per Jani's request and left a comment.

Mark.

Oh boy,

Now my comment at http://bugs.php.net/bug.php?id=25738 on the fact that the snapshot crashed has disappeared. This must be a technical issue. I am getting Ohornoiu to post the comment for me in case his will stick as he is the original author. I think we may need some more reproduce votes.

Mark.

yep that's pretty much the gyst of it

Booyah!

A developer whipped up a patch this afternoon. Shortly after, the fix was worked into the CVS and now all PHP sources from here on in are fixed!

Thanks a million Murlyn -and anyone else who contributed,
Mark.

Awesome great to hear! Now if you can.. shorten those scripts!