Yeah...sure it's on line 42.
How about some code to look at? A backtrace... Anything...
-Sara
- Original Message -
From: ""RG"" <[EMAIL PROTECTED]>
Newsgroups: php.internals
To:
Sent: Wednesday, September 14, 2005 7:11 PM
Subject: Segfault
This is quite unusual, for some reas
The following code segfaults after either I call die/exit or call
socketi_accept once again.
Can anyone spot anything working with it?
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include "php.h"
#include "php_hello.h"
#include
#include
#include
#include
#include
#include
#include
#def
> new_sock->bsd_socket = accept(php_sock->bsd_socket, &sa, &salen);
>
In all liklihood it's that.
Now In the nicest way possible, why don't I suggest that you CLEAN UP
YOUR CODE NEXT TIME!?!?! You might have noticed that new_sock isn't alloc'd
if it wern't for all the comments and flat-out b
For some reason I can't malloc php_socket structs, and that's not where it
segfaults. The function works perfectly once. Then if I attempt to exit /
die or call that function again, it dies.
""Sara Golemon"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > new_sock->bsd_socket = acc
That's not where it segfaults. The function works perfectly once. If I
attempt to exit /
die or call that function again, it segfaults.
However, I have noticed that if I do not use ZEND_REGISTER_RESOURCE the
program no longer segfaults.
And sorry for the comments, someone people don't write the fin
That's not where it segfaults. The function works perfectly once. If I
attempt to exit /
die or call that function again, it segfaults.
However, I have noticed that if I do not use ZEND_REGISTER_RESOURCE the
program no longer segfaults.
I didn't say that's where it segfaults, I said that's where
Well I did try to use it in RINIT, but PHP just wasn't RINIT so I
figured why not put it in MINIT
""Sara Golemon"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > That's not where it segfaults. The function works perfectly once. If I
> > attempt to exit /
> > die or call that f
Well I did try to use it in RINIT, but PHP just wasn't RINIT so I
figured why not put it in MINIT. And I solved the problem, I guess I should
have been more careful when reading the PHP API tutorials, I used malloc
instead of emalloc, so malloc was causing gcc to miscalculate its size or
make i
RG wrote:
Well I did try to use it in RINIT, but PHP just wasn't RINIT so I
figured why not put it in MINIT.
...
> I used malloc
instead of emalloc, so malloc was causing gcc to miscalculate its size or
make it quit with an error.
both claims above don't make *any* sense to me, making m
> both claims above don't make *any* sense to me, making me think
> you still really do not know what you are doing :(
O_O, wow, sorry...
I did not write that like that..
What I meant to say was that I did use zend_fetch_list_dtor_id in RINIT at
first, but I noticed that PHP was not calling RI
What I meant to say was that I did use zend_fetch_list_dtor_id in RINIT
at
first, but I noticed that PHP was not calling RINIT. So then I migrated it
MINIT, which is called when the module is loaded.
Doubtful... PHP calls every module's RINIT at the start of every request.
If you were "testin
On Sat, 6 Mar 2004 23:22:07 +0100
[EMAIL PROTECTED] (Pierre-Alain Joye) wrote:
> Hello,
>
> The following command segfaults (equivalent to "pear.sh package"):
>
> # cd /path/to/pecl/philter
> # php /path/to/pearcmd.php package
>
> please find the backtrace and valgring output as attachments.
>
On Tue, 9 Mar 2004 12:26:35 +0100
[EMAIL PROTECTED] (Pierre-Alain Joye) wrote:
> We use exit(1) inside an instance of an PEAR_Frontend_CLI object,
> removing it do not crash. Still no small script to reproduce...
Fixed by the last commits
pierre
--
PHP Internals - PHP Runtime Development Mail
On Wed, May 11, 2005 at 04:18:40AM -0700, Kamesh Jayachandran wrote:
> Hi Derick and Joe,
> html_entity_decode(' ‘†′⁄€',
> ENT_QUOTES, 'UTF-8'); (same testcase bug #29119) is causing Segfault in
> NetWare.
>
> The cause of the segfault seems to be the size of ent_uni_338_402. Which
> I persume sh
Hi Joe,
The array should be as follows,
static entity_table_t ent_uni_338_402[] = {
/* 338 (0x0152) */
"OElig", "oelig", NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
/* 352 (0x0160) */
"Scaron", "scaron", NULL, NULL, NULL, NULL, NUL
I decided to delete everything and do a new cvs checkout, and now the
segfault has disappeared. Not sure what was going on.
Thanks,
Greg
Greg Beaver wrote:
Hi,
When I try to run phpDocumentor with HEAD in win32/apache 1.3 checked
out a few minutes ago, I get a segfault, here's a stack trace g
Andi Gutmans wrote:
Did this happen after my commit or is it a general problem?
Andi
At 02:03 PM 3/1/2004 +0100, Andrey Hristov wrote:
Hi,
this :
php -r 'class a{function a(){}} $a=new
Reflection_Class("a");$b=$a->getMethod("a"); $b->invoke(NULL);'
segfaults on my machine and generates bus er
>This should be fixed now. Thanks for the short reproducing script.
>
>Andi
I don't think, that it is fixed in latest cvs.
Simply changing the script to this, the problem/bug still exists:
foo = false;
}
public function start() {
throw new Exception();
}
}
Hi - I know that this segfault report is quite vague. Can anyone tell
me by looking at the stacktrace where I could start looking for the
problem?I have not tested this on latest snapshot (the stacktrace
below is w/ PHP5b4), but am told the problem persists. Seems clearly to
be in shutdo
On Mon, 2004-03-01 at 16:53, [EMAIL PROTECTED] wrote:
> >This should be fixed now. Thanks for the short reproducing script.
> >
> >Andi
>
> I don't think, that it is fixed in latest cvs.
> Simply changing the script to this, the problem/bug still exists:
[...]
$ cat destruct_segfault.php
foo = fa
Sebastian Bergmann wrote:
> As with most segfaults I discover while working on PHPUnit2 I could not
> reproduce it with a small standalone script.
Here is the correct stacktrace.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4
This is most likely fixed already in CVS.
--Jani
p.s. ALWAYS try the latest snapshot first before submitting
any bug report / sending any mails.
On Tue, 24 Feb 2004, Hans Lellelid wrote:
>Hi - I know that this segfault report is quite vague. Can anyone tell
>me
On Tue, 2004-02-24 at 22:45, Jani Taskinen wrote:
> This is most likely fixed already in CVS.
>
> --Jani
It wasn't yesterday, but now it is:) I was able to reproduce it but
couldn't come up with a simple script demonstrating the behaviour.
- Timm
--
PHP Internals - PHP Runtime Deve
Sebastian Bergmann wrote:
> Here is the correct stacktrace.
I now worked around the segfault.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Maili
Paul Eggert wrote:
>> http://bugs.php.net/bug.php?id=22215
I applied the patch above to my current CVS checkout of PHP 5 and
it still segfaults when the parsers are generated with bison 1.875:
Starting program: /usr/src/php/php5/sapi/cli/php
[New Thread 16384 (LWP 22087)]
Program received s
Martin Schlemmer wrote:
> what did you try to get this?
I simply called ./sapi/cli/php without a script.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals
Martin Schlemmer <[EMAIL PROTECTED]> writes:
> > #0 0x0823c5e8 in zend_stream_read (file_handle=0x0, buf=0x83c4e10 "",
> > len=8192) at /usr/src/php/php5/Zend/zend_stream.c:95
> > #1 0x0820ebbf in yy_get_next_buffer () at Zend/zend_ini_scanner.c:1242
> > ...
>
> I am still trying to track this
I had a look at this. I think it is only the ini file parser that is
crashing. Try running without a php.ini. Not that this is ok, but it at
least narrows it down a bit if true.
-Rasmus
On Sun, 5 Oct 2003, Sebastian Bergmann wrote:
> Paul Eggert wrote:
> >> http://bugs.php.net/bug.php?id=2
On Sun, 5 Oct 2003, Rasmus Lerdorf wrote:
> I had a look at this. I think it is only the ini file parser that is
> crashing. Try running without a php.ini. Not that this is ok, but it at
> least narrows it down a bit if true.
Oh, never mind, just read the bug report all the way to the end and
Just don't use bison 1.875
--Wez.
- Original Message -
From: "Paul Eggert" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 6:24 AM
Subject: [PHP-DEV] Re: Segfault with PHP
"Wez Furlong" <[EMAIL PROTECTED]> writes:
> Just don't use bison 1.875
We're trying to get the Bison bug (if there is one) fixed.
Possibly the bug is in flex, or is in PHP itself.
I understand that the PHP folks prefer to use older version of
software tools if they happen to work, and that's
Do you experience this bug with PHP 4.3.2?
Zeev
At 18:29 06/10/2003, Paul Eggert wrote:
"Wez Furlong" <[EMAIL PROTECTED]> writes:
> Just don't use bison 1.875
We're trying to get the Bison bug (if there is one) fixed.
Possibly the bug is in flex, or is in PHP itself.
I understand that the P
The bug is there with the current PHP4_3 HEAD. Haven't tried compiling
4.3.2 with 1.875.
-Rasmus
On Mon, 6 Oct 2003, Zeev Suraski wrote:
> Do you experience this bug with PHP 4.3.2?
>
> Zeev
>
> At 18:29 06/10/2003, Paul Eggert wrote:
> >"Wez Furlong" <[EMAIL PROTECTED]> writes:
> >
> > > Ju
> > Just don't use bison 1.875
> If you can't help us solve the problem, fine; but please don't
> discourage other people from helping.
Step back a moment and consider...
The original response to this issue from the bison people was the
not very encouraging "thou shalt not use the skeleton fi
At 18:50 06/10/2003, Rasmus Lerdorf wrote:
The bug is there with the current PHP4_3 HEAD. Haven't tried compiling
4.3.2 with 1.875.
Well, judging by the suggested patch at the report for bug #22215, it
appears it might be somehow related to the fd patch, so it's interesting to
see whether 4.3.2
Zeev Suraski <[EMAIL PROTECTED]> writes:
> Do you experience this bug with PHP 4.3.2?
Here's how I tried to reproduce the problem. I am running Debian
GNU/Linux 3.0r1 (stable) with Bison 1.875.
wget http://downloads.php.net/ilia/php-4.3.4RC1.tar.bz2
tar xjf php-4.3.4RC1.tar.bz2
cd php-4.3
On 6 Oct 2003, Paul Eggert wrote:
> Here's how I tried to reproduce the problem. I am running Debian
> GNU/Linux 3.0r1 (stable) with Bison 1.875.
You need a php.ini file to reproduce the problem. Here is how to figure
out where it wants it:
% php -i | grep ini
Configuration File (php.ini) Path
Rasmus Lerdorf <[EMAIL PROTECTED]> writes:
> You need a php.ini file to reproduce the problem.
OK, thanks. With everybody's help I reproduced the problem.
It turns out to be a portability bug in Zend/zend_ini_parser.y.
That grammar uses the character constant '\0' as a token.
POSIX says that th
"Wez Furlong" <[EMAIL PROTECTED]> writes:
> The original response to this issue from the bison people was the
> not very encouraging "thou shalt not use the skeleton file".
> ... the bison team had made it apparent in the past
> that they were not interested in fixing the problem.
Sorry, I don't
Paul Eggert wrote:
> 2003-10-06 Paul Eggert <[EMAIL PROTECTED]>
>
> * Zend/zend_ini_parser.y:
> This fixes PHP bugs #25770 and #21159.
Seems fixed indeed, no longer segfaults on my GENTOO/Linux laptop with
bison 1.875.
Thanks Paul,
Sebastian
--
Sebastian Bergmann
http://se
40 matches
Mail list logo
