ID:               25620
 User updated by:  xris at farcaster dot net
 Reported By:      xris at farcaster dot net
-Status:           Feedback
+Status:           Open
 Bug Type:         Scripting Engine problem
 Operating System: GNU/Linux 2.4.20
 PHP Version:      4.3.4-dev
 New Comment:

- valgrind-1.9.6
- PHP (4.3.x-dev) snapshot from Sep 23, 2003 09:30 (as in all of my
latest tests), CLI version


Previous Comments:
------------------------------------------------------------------------

[2003-09-26 07:20:35] [EMAIL PROTECTED]

With what PHP version are you getting those valgrind outputs?
And are you using the latest valgrind?


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

[2003-09-25 17:45:26] xris at farcaster dot net

BTW: i don't know if this might help, but here are two
valgrind traces:

1) valgrind --run-libc-freeres=yes ;# SEGFAULT
http://farcaster.net/valgrind-err.log

1) valgrind --run-libc-freeres=no ;# NO SEGFAULT
http://farcaster.net/valgrind-noerr.log

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

[2003-09-25 16:43:59] xris at farcaster dot net

> Please provide a short example script which can be used to reproduce
this.

i'll try- but i fear i'll fast get to a state like [21 Sep 2:50pm EDT]
... isn't there any other way to trace this?
possibly using some kind of memory debugger?

> And don't mix any Zend extensions in this mess, such as debuggers,
optimizers or caches.

I didn't mean to; i was just curious about being possibly
able to figure out what actually led to this problem.

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

[2003-09-25 14:39:45] [EMAIL PROTECTED]

Please provide a short example script which can be used to reproduce
this. (yes, it's hard, but we can't do anything without it). And don't
mix any Zend extensions in this mess, such as debuggers, optimizers or
caches.


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

[2003-09-25 14:06:05] xris at farcaster dot net

I have been too fast declaring my last config was working, as i
obviously missed a sideeffect from the DB usage.

But I have spent the last two days extensively testing dozens of php
builds and now i'm fairly sure i have gotten to a minimalistic config
and _still_ being able to reproduce the error (really..):

'--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc'
'--localstatedir=/var/lib' '--disable-all' '--with-pcre-regex'
'--without-pear' '--without-gd' '--disable-cgi' '--enable-cli'
'--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--with-config-file-path=/etc/php/cli-php4'

I'm still getting the same backtrace as in my [22 Sep 3:56pm EDT]
post.

Using gdb it's segfaulting regardless of having register_globals "on"
or "off") - if i just use the CLI from the bash prompt directly, it
segfaults only using a "register_globals=on" php.ini ..... ahrgl.

BTW: i experimented with using the APD (debugger), strangely
enough: when i load the apd extension, the error does
not appear, the script works just fine...

Maybe its some problem wit the memory management after all
(since the error does not seem to be linked to specific
extension .. but thats just speculation)?

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

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/25620

-- 
Edit this bug report at http://bugs.php.net/?id=25620&edit=1

Reply via email to