[Fwd: PHP Access Violation using PEAR::Mail_smtp]

21 years ago by Ben Ramsey — view source — reply

unread

I'm forwarding this to the Internals list as a last resort and at the
suggestion of someone with PHPCommunity.org. I have not received any
response from php-general or pear-general (after 24 hours), and I have
posted a similar posting about this issue several weeks ago (also with
no response). I have just upgraded my Windows Server 2003 to the Apr 6
2004 20:12:15 build of PHP 5RC1 from snaps.php.net. Here's my phpinfo()
page: http://test.alpharetta.ga.us/info.php

I am not sure whether this is a bug with PHP, but I am sure that you
guys can tell that.

Any help at all is much appreciated. We cannot launch this site until
this issue is resolved, and don't ask me to revert back to a stable
version of PHP or we will have to modify much code throughout the site. ;-)

Thanks,
Ben

-------- Original Message --------
Subject: PHP Access Violation using PEAR::Mail_smtp
Date: Mon, 05 Apr 2004 13:58:31 -0400
From: lists@benramsey.com (Ben Ramsey)
To: pear-general@lists.php.net, php-general@lists.php.net
Newsgroups: php.general,php.pear.general

I'm getting the following error when using the Mail_smtp package from PEAR:

PHP has encountered an Access Violation at 0177A8B4

It does not occur everytime I use it, but even when send() returns true,
e-mail messages are not being sent. However, it all worked fine a week
ago when I was testing it, and I don't think anything has changed to my
installation of PHP.

I'm using PHP 5RC1 on a Windows Server 2003. The localhost has no
built-in mail functionality, so I cannot use mail(). I must use
Mail_smtp to log in to the mail server. I also have Net_SMTP and
Net_Socket installed, and, like I said, when I first dropped in my code,
all was working fine.

My code is, as follows:

<code> require_once 'Mail/smtp.php';

$smtp_settings = array(
'host' => 'localhost',
'port' => '25',
'auth' => 'LOGIN',
'username' => 'username',
'password' => 'password'
);

$to = "you@example.com";
$msg = "Line 1\nLine 2\nLine 3";
$headers = array(
'Subject' => "My Subject",
'From' => "me@example.com",
'Date' => date('r'),
'Content-Type' => 'text/plain',
'X-Mailer' => "PHP/" . phpversion()
);

$mail = new Mail_smtp($smtp_settings);

if ($mail->send($to, $headers, $msg)) {
echo "<h2>Sent successfully</h2>";
} else {
echo "<h2>Not sent</h2>";
}
</code>

If I don't get the access violation error, I get the message "Sent
successfully." Yet, I don't receive any messages.

In the code for Mail_smtp (in Mail/smtp.php), I have added the following
line just under the function declaration line for the send() method:

echo "test";

When the access violation occurs, I get this line:

PHP has encountered an Access Violation at 0177A8B4test

From this, it appears to me that the access violation is not occurring
when the class tries to send mail, but sometime earlier than that.
However, I do not know much more about these Access Violoations, other
than PHP is trying to access memory that it doesn't have permission to
access. I couldn't find anything at bugs.php.net or through Google that
helped much with this problem.

Any help would be greatly appreciated. I am on a tight deadline, so any
help ASAP would be even more greatly appreciated. ;-)

--
Regards,
Ben Ramsey
http://benramsey.com
http://www.phpcommunity.org/wiki/People/BenRamsey

21 years ago by Adam Maccabee Trachtenberg — view source — reply

unread

Any help at all is much appreciated. We cannot launch this site until
this issue is resolved, and don't ask me to revert back to a stable
version of PHP or we will have to modify much code throughout the site. ;-)

You will significantly improve your chances of a useful response if
you pare down the code that triggers to problem to the fewest number
of lines possible.

Ideally, you'd also remove the PEAR class and just strip out the lines
that trigger the bug.

Then file a bug report on http://bugs.php.net with the information.

-adam

--
adam@trachtenberg.com
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!

21 years ago by Ben Ramsey — view source — reply

unread

AT> You will significantly improve your chances of a useful response if
AT> you pare down the code that triggers to problem to the fewest number
AT> of lines possible.
AT>
AT> Ideally, you'd also remove the PEAR class and just strip out the
AT> lines that trigger the bug.

I will try to do this. Unfortunately, I goofed up and stated that it
could not send e-mail at all. This was do to setting my authentication
method to the wrong thing. When I changed it back to LOGIN, it will now
send e-mail messages flawlessly. However, every 4th or 5th time, it
will not send the message and will display a blank page with:

PHP has encountered an Access Violation at 0177A9D4

Like I said, I'll try to pare down the code, but I feel out of luck
here, since it's occurring intermittently.

Thank you for your time.

--
Regards,
Ben Ramsey
http://benramsey.com
http://www.phpcommunity.org/wiki/People/BenRamsey

21 years ago by Mark Spruiell — view source — reply

unread

Ben,

It may not be related to your situation, but I just submitted this
bug report:

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

Take care,

Mark

I will try to do this. Unfortunately, I goofed up and stated that it
could not send e-mail at all. This was do to setting my authentication
method to the wrong thing. When I changed it back to LOGIN, it will now
send e-mail messages flawlessly. However, every 4th or 5th time, it
will not send the message and will display a blank page with:

PHP has encountered an Access Violation at 0177A9D4

Like I said, I'll try to pare down the code, but I feel out of luck
here, since it's occurring intermittently.

Thank you for your time.

--
Regards,
Ben Ramsey
http://benramsey.com
http://www.phpcommunity.org/wiki/People/BenRamsey

21 years ago by Ben Ramsey — view source — reply

unread

I've been told by someone here to pare down my code and submit a bug
report. However, paring down my code corrected the problem, so I'm
still not sure what a PHP Access Violation error is. Following is the
post I made to php-general with my "solution." Am I on the right track
with my guess as to what may have been occurring with the Access
Violation errors, and should I still submit a bug report?

So, I found a solution to my problem. I still do not know what was
causing the PHP Access Violation errors, but I have an idea, which I
will relate in this message.

As many suggested, I have pared down my mail sending class by rewriting
it down to about 250 lines of code. Previously, the PEAR::Mail::smtp
class had much fewer lines of code, but if you count all of the other
files it had to include, then it was a whopping amount of code. The
difference here is that I am only using one class now to send mail,
whereas the PEAR::Mail::smtp class was using about 5 different classes.
Let me walk you through them.

Mail::smtp included and extended the Mail class. The Mail class
included and extended the PEAR class. The send() method of Mail::smtp
included the Net::SMTP class and created an object of that class. The
Net::SMTP class included the PEAR and Net::Socket classes (and
optionally checked for and included the Auth::SASL class). The
Net_SMTP() contstructor created a Net::Socket object. The Net::Socket
class included and extended the PEAR class.

So, in all, that's about 5 classes that Mail::stmp needed. Once I got
it down to one class, the Access Violations disappeared. So, here's
what I think was happening with the classes based on some of the
information I have been told.

I've been told that the Access Violation errors are probably caused when
PHP tries to access a space of memory that it doesn't have permission to
access. From this, I'm gathering that the sheer number of classes
needed and objects and variables created confused PHP so that it wasn't
sure what pointers pointed to the correct space in memory. (Again, I'm
out on a limb with this guess.) Because the pointer lost its space in
memory (I'm guessing that's what happened), PHP tried to access a space
that it either no longer had permission to access or it never had
permission to access.

Make sense? I'm sharing this here because several people expressed an
interest in knowing how it got resolved.

--
Regards,
Ben Ramsey
http://benramsey.com
http://www.phpcommunity.org/wiki/People/BenRamsey

21 years ago by Ben Ramsey — view source — reply

unread

Just curious - Did you completely eliminate the Access Violation errors? Or
just make them appear less frequently?

To my knowledge, they're completely eliminated. Previously, I could not
use the PEAR::Mail::smtp class more than once or twice without seeing
the error, and then the error sometimes occurred up to 10 times in a
row. I have tested my new code by repeatedly sending a mail message up
to 30 times without one instance of the Access Violation. In my mind,
30 times is good enough to warrant saying that the problem is gone
(especially since they occurred so frequently before).

I have (had?) a really bad problem where I was getting a lot of Access
Violations in my script - if I made my script shorter, they appeared less
frequently. I also fixed the problem by using the CGI version instead of
ISAPI (on IIS). Maybe your problem is along the same lines as mine.

I'm using the ISAPI module, actually, and no one has ever suggested that
I switch to the CGI module, but then again, what is the ISAPI module for
if I can't use it? ;-)

I have a feeling that PHP has a memory problem somewhere :/.

Jevon
(Windows XP Pro SP1; IIS 5.1; PHP5 RC1)

That may be so--at least on Windows. I am running Windows Server 2003,
IIS 6, with PHP 5RC1 (latest snapshot) ISAPI module.

--
Regards,
Ben Ramsey
http://benramsey.com
http://www.phpcommunity.org/wiki/People/BenRamsey

21 years ago by Todd Ruth — view source — reply

unread

I have a feeling that PHP has a memory problem somewhere :/.

I'm not sure if it caused any of the issues either of you spoke of,
but I can report that PHP does have some pointer problems. I've
been putting off this email until I had written up something nicer,
but it's probably better to just get the word out (assuming this isn't
already known)...

PHP has problems related to using a temporary as the source for a
reference. An obvious no-no is to write "$x =& NULL;" or
"$x =& @$y[5];". These are parse errors. On the other hand, PHP won't
complain about:

function &f() {
$y = array();
return @$y[5];
}
$x =& f();

It even acts OK. The above code could be a mistake or it could be
a misguided attempt at optimization (believing that keeping a ref
to a temporary is better than setting $x equal to the temporary).
Maybe there was a desire to modify $y if applicable, but otherwise
be OK with modifying a temporary. In any case, if you have a large
enough system and code like that lying around, there's a good chance
you'll get crashes. You may not get a crash but instead see unrelated
data mysteriously changed in functions that get called later.
There are at least 2 ways to adjust the code above to make PHP
happy. One is to remove the "&" in the assignment. Another is
to create a "real" temporary variable instead of letting PHP make its
own temporary. ie

function &f() {
$y = array();
$temp = @$y[5];
return $temp;
}
$x =& f();

I've had crashes go away and mysterious data overwrites go away with
the only change to the system being replacing a piece of code like
the first block of this email with a piece of code like the second
block. This has happened for just about every kind of "=& temp" you
can think of. Here are a few examples (in addition to the case above)
of using temporaries as sources for references. I think we've had a
crash / mysterious data overwrite for just about all of these (if not
all).

function f1() {
$y = 5;
return $y;
}
$x =& f1(); // Get rid of the & or add an & to f1

function &f2() {
return NULL; // Get rid of & below or use "$r = NULL; return $r;"
}
$x =& f2();

function g() {
return NULL;
}
function h(&$x) {
$x = 5;
}
h(g());

That last one could use some combination of the above recommendations
to be fixed. For the record, I agree that there are few (if any) cases
where the above code is the best code for a design problem, but I also
dislike that these code blocks can lead to crashes / corruptions.

BTW, we have never had a problem with using a temporary reference as
the source for a non-reference copy. That is to say the following has
never caused us a problem:

function &f() {
$y = 5;
return $y;
}
$x = f();

Best of luck,
Todd

21 years ago by Ben Ramsey — view source — reply

unread

After I posted my initial message, I thought about references in the
code with "=&". So, I went through looking for them, but I didn't find
any at a quick glance. Still, they could've been in there. I'll check
it out again and see what I can find.

-Ben

Todd Ruth wrote:

I have a feeling that PHP has a memory problem somewhere :/.

I'm not sure if it caused any of the issues either of you spoke of,
but I can report that PHP does have some pointer problems. I've
been putting off this email until I had written up something nicer,
but it's probably better to just get the word out (assuming this isn't
already known)...

PHP has problems related to using a temporary as the source for a
reference. An obvious no-no is to write "$x =& NULL;" or
"$x =& @$y[5];". These are parse errors. On the other hand, PHP won't
complain about:

function &f() {
$y = array();
return @$y[5];
}
$x =& f();

It even acts OK. The above code could be a mistake or it could be
a misguided attempt at optimization (believing that keeping a ref
to a temporary is better than setting $x equal to the temporary).
Maybe there was a desire to modify $y if applicable, but otherwise
be OK with modifying a temporary. In any case, if you have a large
enough system and code like that lying around, there's a good chance
you'll get crashes. You may not get a crash but instead see unrelated
data mysteriously changed in functions that get called later.
There are at least 2 ways to adjust the code above to make PHP
happy. One is to remove the "&" in the assignment. Another is
to create a "real" temporary variable instead of letting PHP make its
own temporary. ie

function &f() {
$y = array();
$temp = @$y[5];
return $temp;
}
$x =& f();

I've had crashes go away and mysterious data overwrites go away with
the only change to the system being replacing a piece of code like
the first block of this email with a piece of code like the second
block. This has happened for just about every kind of "=& temp" you
can think of. Here are a few examples (in addition to the case above)
of using temporaries as sources for references. I think we've had a
crash / mysterious data overwrite for just about all of these (if not
all).

function f1() {
$y = 5;
return $y;
}
$x =& f1(); // Get rid of the & or add an & to f1

function &f2() {
return NULL; // Get rid of & below or use "$r = NULL; return $r;"
}
$x =& f2();

function g() {
return NULL;
}
function h(&$x) {
$x = 5;
}
h(g());

That last one could use some combination of the above recommendations
to be fixed. For the record, I agree that there are few (if any) cases
where the above code is the best code for a design problem, but I also
dislike that these code blocks can lead to crashes / corruptions.

BTW, we have never had a problem with using a temporary reference as
the source for a non-reference copy. That is to say the following has
never caused us a problem:

function &f() {
$y = 5;
return $y;
}
$x = f();

Best of luck,
Todd

--
Regards,
Ben Ramsey
http://benramsey.com
http://www.phpcommunity.org/wiki/People/BenRamsey

21 years ago by Todd Ruth — view source — reply

unread

Unless the problems mentioned in the email I've quoted below
have been fixed, be glad to be getting an error message. :)
In the past it was quite painful to find all of the places
where non-variables were used as references. A big thank
you to whoever added the error message!

Due to the lack of reproducability, I never filed a bug
report for the crashes and corruptions I experienced. Do
any of the experts out there know if the underlying problems
have been addressed?

Thanks!
Todd

I'm not sure if it caused any of the issues either of you spoke of,
but I can report that PHP does have some pointer problems. I've
been putting off this email until I had written up something nicer,
but it's probably better to just get the word out (assuming this isn't
already known)...

PHP has problems related to using a temporary as the source for a
reference. An obvious no-no is to write "$x =& NULL;" or
"$x =& @$y[5];". These are parse errors. On the other hand, PHP won't
complain about:

function &f() {
$y = array();
return @$y[5];
}
$x =& f();

It even acts OK. The above code could be a mistake or it could be
a misguided attempt at optimization (believing that keeping a ref
to a temporary is better than setting $x equal to the temporary).
Maybe there was a desire to modify $y if applicable, but otherwise
be OK with modifying a temporary. In any case, if you have a large
enough system and code like that lying around, there's a good chance
you'll get crashes. You may not get a crash but instead see unrelated
data mysteriously changed in functions that get called later.
There are at least 2 ways to adjust the code above to make PHP
happy. One is to remove the "&" in the assignment. Another is
to create a "real" temporary variable instead of letting PHP make its
own temporary. ie

function &f() {
$y = array();
$temp = @$y[5];
return $temp;
}
$x =& f();

I've had crashes go away and mysterious data overwrites go away with
the only change to the system being replacing a piece of code like
the first block of this email with a piece of code like the second
block. This has happened for just about every kind of "=& temp" you
can think of. Here are a few examples (in addition to the case above)
of using temporaries as sources for references. I think we've had a
crash / mysterious data overwrite for just about all of these (if not
all).

function f1() {
$y = 5;
return $y;
}
$x =& f1(); // Get rid of the & or add an & to f1

function &f2() {
return NULL; // Get rid of & below or use "$r = NULL; return $r;"
}
$x =& f2();

function g() {
return NULL;
}
function h(&$x) {
$x = 5;
}
h(g());

That last one could use some combination of the above recommendations
to be fixed. For the record, I agree that there are few (if any) cases
where the above code is the best code for a design problem, but I also
dislike that these code blocks can lead to crashes / corruptions.

BTW, we have never had a problem with using a temporary reference as
the source for a non-reference copy. That is to say the following has
never caused us a problem:

function &f() {
$y = 5;
return $y;
}
$x = f();

Best of luck,
Todd