php-general Digest 13 Sep 2007 11:53:54 -0000 Issue 5016
Topics (messages 262057 through 262075):
Re: PHP 5.2.3 - Segmentation fault (core dumped) [SOLVED]
262057 by: Zbigniew Szalbot
262058 by: Daniel Brown
262059 by: Zbigniew Szalbot
262063 by: Daniel Brown
262064 by: Per Jessen
Re: PHP 5.2.3 - Segmentation fault (core dumped)
262060 by: Per Jessen
262061 by: Per Jessen
262066 by: Stut
Re: Getting line count of a text file
262062 by: Greg Donald
262065 by: mike
262068 by: bruce
262069 by: Chris
262073 by: mike
blocking exec() silently
262067 by: Samuel Vogel
262070 by: Chris
262072 by: Nathan Nobbe
PHP Fatal error: Call to undefined function hash_hmac()
262071 by: Aaron Axelsen
262074 by: Per Jessen
Re: PHP Installer on Vista
262075 by: dcastillo.tsanalytics.com
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
Dear Daniel and all!
2007/9/12, Daniel Brown <[EMAIL PROTECTED]>:
> > > > > > > <IfModule mod_dir.c>
> > > > > > > <IfModule mod_php3.c>
> > > > > > > <IfModule mod_php4.c>
> > > > > > > DirectoryIndex index.php index.php3 index.html
> > > > > > > </IfModule>
> > > > > > > <IfModule mod_php5.c>
> > > > > > > DirectoryIndex index.php index.php3 index.html
> > > > > > > </IfModule>
> > > > > > > <IfModule !mod_php4.c>
> > > > > > > DirectoryIndex index.php3 index.html
> > > > > > > </IfModule>
> > > > > > > </IfModule>
> > > > > > > <IfModule !mod_php3.c>
> > > > > > > <IfModule mod_php4.c>
> > > > > > > DirectoryIndex index.php index.html
> > > > > > > </IfModule>
> > > > > > > <IfModule !mod_php4.c>
> > > > > > > DirectoryIndex index.html
> > > > > > > </IfModule>
> > > > > > > </IfModule>
> > > > > > > </IfModule>
> Try commenting out the whole block of data you sent to the list
> from your httpd.conf file and entering only this instead:
>
> <IfModule mod_dir.c>
> DirectoryIndex index.php index.php3 index.html index.htm
> </IfModule>
Problem solved! Daniel - this really helped. I do not even know how to
thank you but surely, this is amazing. This thing actually works! :)
Thanks to all!
Zbigniew Szalbot
--- End Message ---
--- Begin Message ---
On 9/12/07, Zbigniew Szalbot <[EMAIL PROTECTED]> wrote:
> Dear Daniel and all!
>
> 2007/9/12, Daniel Brown <[EMAIL PROTECTED]>:
> > > > > > > > <IfModule mod_dir.c>
> > > > > > > > <IfModule mod_php3.c>
> > > > > > > > <IfModule mod_php4.c>
> > > > > > > > DirectoryIndex index.php index.php3 index.html
> > > > > > > > </IfModule>
> > > > > > > > <IfModule mod_php5.c>
> > > > > > > > DirectoryIndex index.php index.php3 index.html
> > > > > > > > </IfModule>
> > > > > > > > <IfModule !mod_php4.c>
> > > > > > > > DirectoryIndex index.php3 index.html
> > > > > > > > </IfModule>
> > > > > > > > </IfModule>
> > > > > > > > <IfModule !mod_php3.c>
> > > > > > > > <IfModule mod_php4.c>
> > > > > > > > DirectoryIndex index.php index.html
> > > > > > > > </IfModule>
> > > > > > > > <IfModule !mod_php4.c>
> > > > > > > > DirectoryIndex index.html
> > > > > > > > </IfModule>
> > > > > > > > </IfModule>
> > > > > > > > </IfModule>
>
> > Try commenting out the whole block of data you sent to the list
> > from your httpd.conf file and entering only this instead:
> >
> > <IfModule mod_dir.c>
> > DirectoryIndex index.php index.php3 index.html index.htm
> > </IfModule>
>
> Problem solved! Daniel - this really helped. I do not even know how to
> thank you but surely, this is amazing. This thing actually works! :)
>
> Thanks to all!
>
> Zbigniew Szalbot
>
No problem at all.
Now my guess at explaining it....
Notice how `IfModule mod_php5.c` if only mentioned when nested
inside of the `IfModule mod_php3.c` container. If you want to have
the intelligent-detection of PHP's availability, you should be able to
update this:
<IfModule mod_dir.c>
DirectoryIndex index.php index.php3 index.html index.htm
</IfModule>
.... like so:
<IfModule mod_dir.c>
<IfModule mod_php5.c>
DirectoryIndex index.php index.php3 index.html index.htm
</IfModule>
<!IfModule mod_php5.c>
DirectoryIndex index.html index.htm
</IfModule>
</IfModule>
--
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107
Give a man a fish, he'll eat for a day. Then you'll find out he was
allergic and is hospitalized. See? No good deed goes unpunished....
--- End Message ---
--- Begin Message ---
Hello,
2007/9/12, Daniel Brown <[EMAIL PROTECTED]>:
> No problem at all.
Your help was very much appreciated!
>
> Now my guess at explaining it....
>
> Notice how `IfModule mod_php5.c` if only mentioned when nested
> inside of the `IfModule mod_php3.c` container. If you want to have
> the intelligent-detection of PHP's availability, you should be able to
> update this:
>
> <IfModule mod_dir.c>
> DirectoryIndex index.php index.php3 index.html index.htm
> </IfModule>
>
> .... like so:
>
> <IfModule mod_dir.c>
> <IfModule mod_php5.c>
> DirectoryIndex index.php index.php3 index.html index.htm
> </IfModule>
> <!IfModule mod_php5.c>
> DirectoryIndex index.html index.htm
> </IfModule>
> </IfModule>
By now you almost made me an expert :) and the above should actually say:
<IfModule mod_dir.c>
<IfModule mod_php5.c>
DirectoryIndex index.php index.php3 index.html index.htm
</IfModule>
<IfModule !mod_php5.c>
DirectoryIndex index.html index.htm
</IfModule>
</IfModule>
Regards,
Zbigniew Szalbot
--- End Message ---
--- Begin Message ---
On 9/12/07, Zbigniew Szalbot <[EMAIL PROTECTED]> wrote:
> Hello,
>
> 2007/9/12, Daniel Brown <[EMAIL PROTECTED]>:
> > No problem at all.
>
> Your help was very much appreciated!
>
> >
> > Now my guess at explaining it....
> >
> > Notice how `IfModule mod_php5.c` if only mentioned when nested
> > inside of the `IfModule mod_php3.c` container. If you want to have
> > the intelligent-detection of PHP's availability, you should be able to
> > update this:
> >
> > <IfModule mod_dir.c>
> > DirectoryIndex index.php index.php3 index.html index.htm
> > </IfModule>
> >
> > .... like so:
> >
> > <IfModule mod_dir.c>
> > <IfModule mod_php5.c>
> > DirectoryIndex index.php index.php3 index.html index.htm
> > </IfModule>
> > <!IfModule mod_php5.c>
> > DirectoryIndex index.html index.htm
> > </IfModule>
> > </IfModule>
>
> By now you almost made me an expert :) and the above should actually say:
>
> <IfModule mod_dir.c>
> <IfModule mod_php5.c>
> DirectoryIndex index.php index.php3 index.html index.htm
> </IfModule>
> <IfModule !mod_php5.c>
> DirectoryIndex index.html index.htm
> </IfModule>
> </IfModule>
>
> Regards,
>
> Zbigniew Szalbot
>
Heh. Yup, you're right.... forgot the ! to indicate NOT in the second case.
--
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107
Give a man a fish, he'll eat for a day. Then you'll find out he was
allergic and is hospitalized. See? No good deed goes unpunished....
--- End Message ---
--- Begin Message ---
Zbigniew Szalbot wrote:
> Problem solved! Daniel - this really helped. I do not even know how to
> thank you but surely, this is amazing. This thing actually works! :)
Amazing indeed. PHP does good work for me, but I'm not impressed.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
Zbigniew Szalbot wrote:
> It is clearly problem with indexes but how and where that is an issue
> for me. there is a solution which I could live with. That is I can
> create an index.html page which will simply redirect to index.php and
> so index-wise everything will work but I would really prefer to find
> out what is wrong.
Get hold of one of core dumps, and submit it to the PHP developers. They
understand those.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
Jay Blanchard wrote:
>> Whenever I've reported a core-dump (which I've stopped doing),
>> nothing's been done about it unless I've been able to produce a short
>> script to reproduce.
>> [/snip]
>
> That is to be expected and is standard operating procedure for any
> development team.
I beg to differ. In the past 20 years, I've spent plenty of time
working with core dumps, stand-alone dumps, slip traps and system
traces debugging my own software (running at customer sites) without
the remotest possibility of reproducing a problem on-demand.
If you think a problem must be reproducable for "any development team"
to solve it, you need to try working in a real one. No offence, just
my opinion.
> In order to replicate the issue they have to duplicate the action that
> caused the failure.
Unless you work based on trial&error, there is no real need to replicate
the issue until you feel you may have identified the problem. A core
dump or an strace or some debug output at the right time will have 99%
of the information you need - provided you understand how to read it.
I submit there is generally no need to reproduce a problem in order to
diagnose it. To fix it, yes, it will undoubtedly help if you can
reproduce it, but once you've diagnosed it, reproducing it is a
lot easier.
> You see that time and again on this list as well....without the
> offending action all we can do is attempt to guess at what was going
> on at the time of the failure. Diligent trouble-shooting on your part
> would have gotten a much better response. You could have likely
> isolated the code that caused the core dump (just as we isolate
> problem code on this list...
Jay, this is the same kind of c... that PHP developers have responded
with in the past. I'm sorry, but IMO that is entirely unprofessional.
OK, so maybe one isn't being paid to write open source software, but
that's no excuse for not being professional about it. IMHO.
What's the purpose of a core dump if it does not provide the key
information for solving a problem? If I still have to isolate and
reproduce the issue in user code, there seems to be very little need for
the core dump, right?
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
Per Jessen wrote:
Stut wrote:
Anyway, I think it's exceptionally poor show by php to cause a
segfault, probably due to user code. I know it does it every now and
then, and nobody has ever been interested in looking at the core
dump.
This will have nothing to do with user code since no user code is
involved in displaying the version info. It's most likely a problem
with mixed version numbers, or possibly (but unlikely) a configuration
issue. If there's an auto_prepend_file or auto_append_file in the
configuration that may be loaded by php -v, I'm not sure.
Blaming PHP for this is like blaming Microsoft because Photoshop
crashed on a Windows machine. It's possible PHP is to blame but there
is a whole stack of other considerations to go through before coming
to that conclusion.
Stut, put this problem aside for a sec, and let me ask this - if I can
produce an apache core-dump using vanilla apache, vanilla php (even
with no extensions if you want) and a PHP script, you'll get someone to
debug it? (I cannot promise a easily reproducable problem, just the
core-dump, and a few hundred lines of script)
FYI, I've tried that before, and the PHP developers are not interested
and/or they do not work with core dumps.
Please tell me you're kidding? If you can't provide a piece of code that
always causes the segfault are you seriously expecting the devs to waste
their time trying to find the cause? Talk about a needle in a haystack.
The ease of reproduction is not particularly important, although the
easier the better. The important thing is that every time you run the
script it causes a segfault.
> I still maintain it is exceptionally poor show by php to let user code
> produce segfaults in apache.
To me this comment indicates a lack of experience in software
development with C. Segfaults are a fact of life and it's very difficult
to cover every possible cause, especially when you are using a number of
external libraries. Expecting PHP to be perfect is unrealistic.
The core development team is a limited resource and they need to put
their time where their time provides the most benefit. I'm not saying
they always get this right, but you can't expect them to invest their
time into fixing a problem you've found unless you've done the work
yourself to isolate where the problem is and you have a piece of code
that causes it 100% of the time.
-Stut
--
http://stut.net/
--- End Message ---
--- Begin Message ---
On Wed, 12 Sep 2007, mike wrote:
> personally i try to use as little shell commands as possible,
> especially stacked on top of each other in exec().
Why? Shell commands are a lot less likely to change than the
current PHP function names.
I'm aware the PHP function naming algorithm currently remains a
secret, but without a doubt, someday someone _will_ crack it. I
personally hope this occurs before the renaming of PHP to Java.
--
Greg Donald
Cyberfusion Consulting
http://cyberfusionconsulting.com/
--- End Message ---
--- Begin Message ---
On 9/12/07, Greg Donald <[EMAIL PROTECTED]> wrote:
> Why? Shell commands are a lot less likely to change than the
> current PHP function names.
>
> I'm aware the PHP function naming algorithm currently remains a
> secret, but without a doubt, someday someone _will_ crack it. I
> personally hope this occurs before the renaming of PHP to Java.
if the basic functions i mentioned above change names that one line of
code will be the least of everyone's concerns.
not to mention PHP maintains cross-platform support, whereas shell
commands wouldn't, shell commands may have inherent security risks,
disabled, not installed, selinux or some other weird limitations, etc.
PHP most likely wouldn't have specific basic functions disabled.
--- End Message ---
--- Begin Message ---
greg...
while you are correct in your assertion that the shell cmds provided are
specific to linux, your assertion/statement that the functions might be 'turned
off' are fud... basic bash functions are inherently part of the shell....
and yes, you are correct in your statement that php is relatively cross
platform, however, i imagine that you can quite easily get into situations
where your php code has to have different branches based upon the platform that
it's running on...
every other language i've ever written for has required me to have subtle
differences based upon the underlying platform, i'm pretty sure php would/can
as well.... the assumption here, is that you're getting into complex stuff..
peace.
-----Original Message-----
From: mike [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2007 2:18 PM
To: Greg Donald
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP] Getting line count of a text file
On 9/12/07, Greg Donald <[EMAIL PROTECTED]> wrote:
> Why? Shell commands are a lot less likely to change than the
> current PHP function names.
>
> I'm aware the PHP function naming algorithm currently remains a
> secret, but without a doubt, someday someone _will_ crack it. I
> personally hope this occurs before the renaming of PHP to Java.
if the basic functions i mentioned above change names that one line of
code will be the least of everyone's concerns.
not to mention PHP maintains cross-platform support, whereas shell
commands wouldn't, shell commands may have inherent security risks,
disabled, not installed, selinux or some other weird limitations, etc.
PHP most likely wouldn't have specific basic functions disabled.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
bruce wrote:
greg...
while you are correct in your assertion that the shell cmds provided are
specific to linux, your assertion/statement that the functions might be 'turned
off' are fud... basic bash functions are inherently part of the shell....
Sure they can - enable safe-mode and it causes all sorts of weirdness
with running exec or system calls.
I also disable exec/system calls in php altogether by editing my php.ini
file (see disabled_functions).
Lastly wc and awk and sed are not part of the shell, they are external
programs.
Shell functions are things like if, while, do.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
On 9/12/07, Chris <[EMAIL PROTECTED]> wrote:
> bruce wrote:
> > greg...
actually, i was the one that said this.
> Sure they can - enable safe-mode and it causes all sorts of weirdness
> with running exec or system calls.
not to mention shell commands expect to be in PATH, and if you
hardcode in /bin/awk, it might not be the same location in freebsd vs.
linux vs. solaris vs. another unix. or a crippled or broken system.
> I also disable exec/system calls in php altogether by editing my php.ini
> file (see disabled_functions).
>
> Lastly wc and awk and sed are not part of the shell, they are external
> programs.
thank you.
> Shell functions are things like if, while, do.
exactly, thank you. your reply was much more eloquent than what i
would have said.
--- End Message ---
--- Begin Message ---
Hey guys,
Actually I'm still looking for a way to block for example the exec()
function without throwing an error!
Since there seems to be no way to do this, without hacking the code of
php, it seems like that is what I'll have to do...
Do you people think it would be a good way to just look for where the
exec() function is defined in the source and then just empty it out an
let it return true or whatever value it normaly returns?
Or would there be a better, different way?
And could some of you devs, just give me a short hint where to look for
example for the exec() function in the source, since I never looked into
php?
Regards,
Samy
--- End Message ---
--- Begin Message ---
Samuel Vogel wrote:
Hey guys,
Actually I'm still looking for a way to block for example the exec()
function without throwing an error!
Since there seems to be no way to do this, without hacking the code of
php, it seems like that is what I'll have to do...
Why do you have to do this and not your customers or their developers?
Seems like you're going to have to run a cron script or something to
check once a week in case someone uploads a new file with this stuff in it.
Do you people think it would be a good way to just look for where the
exec() function is defined in the source and then just empty it out an
let it return true or whatever value it normaly returns?
Well it returns a string (see
http://www.php.net/manual/en/function.exec.php) so it's hard to give a
"default" answer because it depends on the context.
And could some of you devs, just give me a short hint where to look for
example for the exec() function in the source, since I never looked into
php?
If you're on a *nix box, you could do something like:
grep -nri '[^_]exec(' /path/to/folder/
and it will show you the files & line numbers you need to look at.
The [^_] means it skips pg_exec, curl_exec, stuff like that.
But you'll have to run a separate check for shell_exec (unless you want
to play with the regex).
If you're on windows, use the filters in the search area to do it.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
i dont know why you wouldnt just use the
disable_functions directive in php.ini
disable_functions = "exec"
this will indeed raise an error, well a warning rather, from my test
[12-Sep-2007 19:22:24] PHP Warning: exec() has been disabled for security
reasons
but i always suppress warnings and errors to the browser in production
anyway, which is good practice. i dont see a problem letting the warnings
spit out in preproduction either, then
developers would get the hint..
-nathan
in /home/nathan/testDisable.php on line 2
On 9/12/07, Samuel Vogel <[EMAIL PROTECTED]> wrote:
>
> Hey guys,
>
> Actually I'm still looking for a way to block for example the exec()
> function without throwing an error!
> Since there seems to be no way to do this, without hacking the code of
> php, it seems like that is what I'll have to do...
>
> Do you people think it would be a good way to just look for where the
> exec() function is defined in the source and then just empty it out an
> let it return true or whatever value it normaly returns?
> Or would there be a better, different way?
>
> And could some of you devs, just give me a short hint where to look for
> example for the exec() function in the source, since I never looked into
> php?
>
> Regards,
> Samy
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
We are running Novell SUSE Linux Enterprise Server 10 sp1. It has php
5.1.2. We are using a standard out of the box install, and for some
reason the hash functions only work using the cli interface, and fails
to work with apache giving the following error:
PHP Fatal error: Call to undefined function hash_hmac()
Does anyone have any suggestions as to what might be causing this?
--
Aaron Axelsen
[EMAIL PROTECTED]
Great hosting, low prices. Modevia Web Services LLC -- http://www.modevia.com
--- End Message ---
--- Begin Message ---
Aaron Axelsen wrote:
> We are running Novell SUSE Linux Enterprise Server 10 sp1. It has php
> 5.1.2. We are using a standard out of the box install, and for some
> reason the hash functions only work using the cli interface, and fails
> to work with apache giving the following error:
>
> PHP Fatal error: Call to undefined function hash_hmac()
>
> Does anyone have any suggestions as to what might be causing this?
The Apache and the CLI environments do have different setups - is it
possible that the hash extension was not built into what apache is
running?
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
there is a web page somewhere where there are instruction and a bat file to
help you install it. (google it)
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: "M. Sokolewicz" <[EMAIL PROTECTED]>
> Sent: Thursday, September 13, 2007 1:11 PM
> Subject: Re: [PHP] PHP Installer on Vista
>
>
> >
> > its true, I had to install it manually
> > ----- Original Message -----
> > From: "M. Sokolewicz" <[EMAIL PROTECTED]>
> > To: "Rahul Sitaram Johari" <[EMAIL PROTECTED]>
> > Cc: "PHP" <[EMAIL PROTECTED]>
> > Sent: Wednesday, September 12, 2007 4:56 PM
> > Subject: Re: [PHP] PHP Installer on Vista
> >
> >
> > > Rahul Sitaram Johari wrote:
> > > > Ave,
> > > >
> > > > Is it true that the PHP Installer does not work on Windows Vista?
And
> if
> > it
> > > > does, it only installs the CGI version?
> > > >
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > Rahul Sitaram Johari
> > > > CEO, Twenty Four Seventy Nine Inc.
> > > >
> > > > W: http://www.rahulsjohari.com
> > > > E: [EMAIL PROTECTED]
> > > >
> > > > ³I morti non sono piu soli ... The dead are no longer lonely²
> > >
> > > Did you try it? Easiest way to find out...
> > >
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
>
--- End Message ---
