Re: [PHP-DEV] Re: Segfault

[Hartmut Holzgraefe]

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 me think
you still really do not know what you are doing :(

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault

[RG]

> 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 RINIT. So then I migrated it
MINIT, which is called when the module is loaded.

As for malloc/emalloc, I tried using malloc(sizeof(struct php_socket));
which did not work because gcc was erroring with "Incomplete datatype". I
then re-read the Zend API function list and came across emalloc, which I had
omitted when I first read it. So once I used emalloc, it worked.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault

[Sara Golemon]

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 "testing" RINIT by launching something like `php -m` or `php -i` 
or something then sure RINIT wouldn't be called.  There's no actual request 
involved.  In a real script execute it most certainly would call RINIT.



As for malloc/emalloc, I tried using malloc(sizeof(struct php_socket));
which did not work because gcc was erroring with "Incomplete datatype". I
then re-read the Zend API function list and came across emalloc, which I 
had

omitted when I first read it. So once I used emalloc, it worked.

The malloc/emalloc issue is genuine enough in that yes, you do need to be 
using the emalloc() family over the system malloc allocators (except in rare 
cases involving persistency).


The larger issue of the incomplete type comes from the fact that the form of 
your structure declaration means you'll want to get your size from 
sizeof(php_socket) not sizeof(struct php_socket).


typedef struct {
   PHP_SOCKET bsd_socket;
   int type;
   int error;
} php_socket;

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: Segfault in HEAD

[Timm Friebe]

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 = false;
}
public function start() {
  throw new Exception();
}
  }

  function bar() {
$test = new test();
$test->start();
  }
  
  bar();
?>
$ php5 destruct_segfault.php 

Fatal error: Uncaught exception 'exception' in
/usr/home/thekid/devel/php/tests/destruct_segfault.php:7
Stack trace:
#0 /usr/home/thekid/devel/php/tests/destruct_segfault.php(13):
test->start()
#1 /usr/home/thekid/devel/php/tests/destruct_segfault.php(16): bar()
#2 {main}
  thrown in /usr/home/thekid/devel/php/tests/destruct_segfault.php on
line 7

Looks fine to me.

- Timm

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: segfault in shutdown sequence

[Jani Taskinen]

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 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 shutdown sequence but beyond that I'm not sure -- Reflection_API, 
>XML (expat) ... ?  Not using destructors...
>
>Thanks-
>Hans
>
>Hans Lellelid wrote:
>> I'm getting a segfault at the end of (successful) script execution. 
>> Appears to be an issue in the shutdown sequence; I'm unsure how to 
>> report this bug, since providing duplicating code is not possible.
>> 
>> The segfault is happening at the end of a Phing (http://phing.info) 
>> build process, which involves many (over a hundred, I'm sure) classes, 
>> uses reflection api heavily, XML (expat), etc.
>> 
>> Here's a bugtrace from the core file.  I don't know if this is any help 
>> at all.  I was hoping to find some 'execute' lines so I could track down 
>> the issue in my code.  This seems to be just part of the shutdown 
>> sequence, though. If anyone has some suggestions for things I could look 
>> for, please let me know.
>> 
>> Thanks,
>> Hans
>> 
>> #0  0x0818e625 in zend_mm_remove_from_free_list (heap=0x81f7a80, 
>> mm_block=0xbed43144)
>> at /home/work/php-5.0.0b4/Zend/zend_mm.c:163
>> #1  0x0818e158 in zend_mm_free (heap=0x81f7a80, p=0xbed434b0)
>> at /home/work/php-5.0.0b4/Zend/zend_mm.c:356
>> #2  0x0816bf79 in _efree (ptr=0x3) at 
>> /home/work/php-5.0.0b4/Zend/zend_alloc.c:283
>> #3  0x0818bc50 in zend_objects_free_object_storage (object=0xbed44fec)
>> at /home/work/php-5.0.0b4/Zend/zend_objects.c:78
>> #4  0x0818e94e in reflection_free_objects_storage (object=0xbed44fec)
>> at /home/work/php-5.0.0b4/Zend/zend_reflection_api.c:191
>> #5  0x0818da3c in zend_objects_store_del_ref (zobject=0x3)
>> at /home/work/php-5.0.0b4/Zend/zend_objects_API.c:140
>> #6  0x0817c1d1 in _zval_dtor (zvalue=0xbed443e4)
>> at /home/work/php-5.0.0b4/Zend/zend_variables.c:61
>> #7  0x08174f79 in _zval_ptr_dtor (zval_ptr=0xbed48798)
>> at /home/work/php-5.0.0b4/Zend/zend_execute_API.c:359
>> #8  0x08182da0 in zend_hash_destroy (ht=0xbedae214)
>> at /home/work/php-5.0.0b4/Zend/zend_hash.c:513
>> #9  0x0817c1fd in _zval_dtor (zvalue=0xbedafc14)
>> at /home/work/php-5.0.0b4/Zend/zend_variables.c:52
>> #10 0x08174f79 in _zval_ptr_dtor (zval_ptr=0xbed46430)
>> at /home/work/php-5.0.0b4/Zend/zend_execute_API.c:359
>> #11 0x08182da0 in zend_hash_destroy (ht=0xbed44324)
>> at /home/work/php-5.0.0b4/Zend/zend_hash.c:513
>> #12 0x0818bc47 in zend_objects_free_object_storage (object=0xbedac1cc)
>> at /home/work/php-5.0.0b4/Zend/zend_objects.c:77
>> #13 0x0818d878 in zend_objects_store_free_object_storage 
>> (objects=0x81f7f70)
>> at /home/work/php-5.0.0b4/Zend/zend_objects_API.c:71
>> #14 0x08174d90 in shutdown_executor ()
>> at /home/work/php-5.0.0b4/Zend/zend_execute_API.c:273
>> #15 0x0817d4ec in zend_deactivate () at 
>> /home/work/php-5.0.0b4/Zend/zend.c:813
>> #16 0x0814cd9b in php_request_shutdown (dummy=0x0)
>> at /home/work/php-5.0.0b4/main/main.c:1243
>> #17 0x081a13bf in main (argc=9, argv=0xbff651c4)
>> at /home/work/php-5.0.0b4/sapi/cli/php_cli.c:1044
>
>

-- 
https://www.paypal.com/xclick/[EMAIL PROTECTED]&no_note=1&tax=0¤cy_code=EUR
 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: segfault in shutdown sequence

[Timm Friebe]

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 Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault in PHP_5_0 and HEAD

[Sebastian Bergmann]

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 Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Rasmus Lerdorf]

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=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 signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 22087)]
> 0x0823c5e8 in zend_stream_read (file_handle=0x0, buf=0x83c4e10 "",
> len=8192) at /usr/src/php/php5/Zend/zend_stream.c:95
> 95  if (file_handle->handle.stream.interactive) {
> (gdb) bt
> #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
> #2  0x0820e87b in ini_lex (ini_lval=0xbfffe2c0) at
> Zend/zend_ini_scanner.c:1076
> #3  0x0820d863 in ini_parse () at Zend/zend_ini_parser.c:1087
> #4  0x0820d5cd in zend_parse_ini_file (fh=0xb480, unbuffered_errors=1
> '\001',
>  ini_parser_cb=0x81e5a29 , arg=0x83b1000) at
> zend_ini_parser.y:156
> #5  0x081e637b in php_init_config () at /usr/src/php/php5/main/php_ini.c:420
> #6  0x081e0ef5 in php_module_startup (sf=0x82ef200,
> additional_modules=0x0, num_additional_modules=0)
>  at /usr/src/php/php5/main/main.c:1390
> #7  0x0825b67e in main (argc=1, argv=0xb794) at
> /usr/src/php/php5/sapi/cli/php_cli.c:593
> #8  0x403feb47 in __libc_start_main () from /lib/libc.so.6
> 
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Rasmus Lerdorf]

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 you 
guys have already figured this out.

-Rasmus 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Wez Furlong]

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 and bison 1.875(a)


> 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 one, but it basically works this
> > side and not yours, as I have disabled NLS (or multibyte) and
> > you have it enabled.
>
> The backtrace indicates that the non-working version has multibyte
> disabled.  I.e., it looks like YY_INPUT invoked zend_stream_read,
> which means that ZEND_MULTIBYTE was not defined.  This is the default,
> and it is how I configured php5.  I didn't observe the bug.
>
> I also tried configuring php5 with "configure --enable-zend-multibyte",
> but couldn't reproduce the bug that way either.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Paul Eggert]

"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 a reasonable
approach in the short run, but as time goes on it becomes more and
more unsustainable.  The Bison maintainers have gotten a couple of bug
reports saying "PHP doesn't work with Bison and we don't know why" and
we'd like to get to the bottom of the problem.  If you can't help us
solve the problem, fine; but please don't discourage other people from
helping.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Zeev Suraski]

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 PHP folks prefer to use older version of
software tools if they happen to work, and that's a reasonable
approach in the short run, but as time goes on it becomes more and
more unsustainable.  The Bison maintainers have gotten a couple of bug
reports saying "PHP doesn't work with Bison and we don't know why" and
we'd like to get to the bottom of the problem.  If you can't help us
solve the problem, fine; but please don't discourage other people from
helping.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Rasmus Lerdorf]

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:
> >
> > > 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 a reasonable
> >approach in the short run, but as time goes on it becomes more and
> >more unsustainable.  The Bison maintainers have gotten a couple of bug
> >reports saying "PHP doesn't work with Bison and we don't know why" and
> >we'd like to get to the bottom of the problem.  If you can't help us
> >solve the problem, fine; but please don't discourage other people from
> >helping.
> >
> >--
> >PHP Internals - PHP Runtime Development Mailing List
> >To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Wez Furlong]

> > 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 file".

I wasn't aware that you were one of the bison people, so I was
offering you the time-saving advice of using a known-good version,
because the bison team had made it apparent in the past 
that they were not interested in fixing the problem.

If you had said something along the lines of "Hey, I'm one of the bison
guys and I'm looking into this bug you brought up in the past" that
would have identified you as a bison-clueful person (I'm sure you're
aware that there aren't many people that are), then I would not have
bothered to waste my time helping you, and not have needed to sit
here and write this email either.

--Wez.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Zeev Suraski]

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 suffers from the same problem.

Zeev

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Paul Eggert]

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.4RC1
  ./configure --prefix=/tmp/prefix
  make
  touch Zend/zend_ini_parser.y Zend/zend_language_parser.y
  make
  echo foo | ./sapi/cli/php

The last command outputs "Parse error: syntax error, unexpected
T_NUM_STRING in - on line 2".  I don't use PHP, so I don't know
whether this is the correct answer for PHP (I don't use PHP), but it's
not a core dump so I am not reproducing the exact problem.

The "touch" command causes the 2nd make to rebuild the two parsers
using Bison 1.875.

Perhaps someone who is experiencing the problem can try the above
recipe, and we can compare notes.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Rasmus Lerdorf]

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 => /etc/php.ini

Probably not /etc in your build.  

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Paul Eggert]

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 the behavior is undefined in this case.
See ,
section "Lexical Structure of the Grammar", which says "The
application shall ensure that the NUL character is not used in grammar
rules or literals."  This prohibits grammars from using '\0' tokens.

I suspect that earlier versions of Bison silently ignored any grammar
rules containing '\0' tokens, but newer versions cause them to make
the generated parser dump core.  Both behaviors conform to POSIX, but
obviously it'd be better if Bison issued a diagnostic when it sees
such tokens.  I'll install a fix to Bison to do that.

Here is a patch to PHP to fix the PHP bug.  This patch is relative to
php5, but the bug is php4 as well.  I've submitted this patch to
bugs.php.net (it's PHP bug #25770).

2003-10-06  Paul Eggert  <[EMAIL PROTECTED]>

* Zend/zend_ini_parser.y:
  This fixes PHP bugs #25770 and #21159.

Index: Zend/zend_ini_parser.y
===
RCS file: /repository/ZendEngine2/zend_ini_parser.y,v
retrieving revision 1.24
diff -p -u -r1.24 zend_ini_parser.y
--- Zend/zend_ini_parser.y  10 Jun 2003 20:03:25 -  1.24
+++ Zend/zend_ini_parser.y  7 Oct 2003 06:55:36 -
@@ -213,7 +213,6 @@ string_or_value:
|   CFG_TRUE { $$ = $1; }
|   CFG_FALSE { $$ = $1; }
|   '\n' { $$.value.str.val = strdup(""); $$.value.str.len=0; $$.type = 
IS_STRING; }
-   |   '\0' { $$.value.str.val = strdup(""); $$.value.str.len=0; $$.type = 
IS_STRING; }
 ;
 
 expr:

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Paul Eggert]

"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 recall those responses.  I don't see what Bison
skeleton files have to do with this issue, nor do I recall the Bison
team saying they didn't care about it.  At any rate, I hope we've
gotten to the bottom of the problem now that PHP bug#25770 has been
filed.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Sebastian Bergmann]

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://sebastian-bergmann.de/   http://phpOpenTracker.de/

Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php