Just to be sure, i compiled a new valgrind using
the latest stable version: valgrind-20030725

As far as i can tell, the output is identical...

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

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

I don't know if it's of any help, but i found out that the 4.3.4-dev version prints out more debug information as the 4.3.3 i initially ([21 Sep 11:21am EDT]) used (if compiled "--with-debug"), so here once again a debug output:

--- snip ---

Warning: String is not zero-terminated (Bundesland??̏*Z?̏*ZZZZZZZZZZZZZZZZZZZZZZ?̏*) (source: /var/tmp/portage/php-4.3.4/work/php-4.3.4/Zend/zend_opcode.c:159) in Unknown on line 0
[Fri Sep 26 15:14:21 2003]  Script:  'htdocs/sport/auswahl.php'
---------------------------------------
/home/develop/php-4.3.4/Zend/zend_opcode.c(159) : Block 0x424DB744 status:
/home/develop/php-4.3.4/Zend/zend_variables.c(44) : Actual location (location was relayed)
Beginning:      OK (allocated on Zend/zend_language_scanner.c:4492, 11 bytes)
      End:      Overflown (magic=0x2A8FCC83 instead of 0x2A8FCC84)
                1 byte(s) overflown
---------------------------------------

Rechecked both strings; "SetVerband" is definitely a method (theres no other usage of this string in the whole system), but "Bundesland" is a variable (i replaced all '$Bundesland' variables with '$dnalsednuB'). I'll try to identify the
offending usage of this var, but there are 146 places where
such a variable name is used. In almost all cases, $Bundesland contains a class, though..

Seems to me the same issue addressed in bug #22510. I suspect you are trying to return a value by reference that is not originated from a variable somewhere in a function. That is,

function &return_ref_a() {
    return $a + $b;
}

function &return_ref_b() {
    return @$a;
}

function &return_ref_c() {
    return -$a;
}

None of the above examples don't actually work, which are verified to cause random heap corruption. Please check if such an error is somewhere in your code.

So far i checked 600 methods, but could'nt find any
return's similar to your examples. What about these
constructs, are they known to cause heap corruption, too?

// Example 1
function &return_ref_constant() {
    return FALSE; // or "return (1<2):"
}
// Example 2
function &a() {
  return $b
}
function &return_ref_method() {
    return $this->a();
}
// Example 3
function &return_ref_array() {
    return array();
}

Yes, i know, some of them are "wrong".

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

I had to modify some minor stuff of the script (our system) to get it working with php5.

Then php complained on a couple of occasions about an illegal return value for a refercence return method ( we had some calls like the one in my "Example 2" and some methods doing "return new XYZ();).

I fixed these by first assigning the return value to a
variable, then returned this var.

After that, php5 ran the code without complaints/errors.

The same (modified) code, run by the php4 version, still throws the error.

So it is the same basic problem as in bug #22510 and is 'fixed' in PHP5. This will not be fixed in PHP 4.

OK. Thanks to you all for your help and efforts anyway.
Keep up the good work, your are doing a tremendous job.