Re: PHP SEGV bug tracing.

On Thu, 24 Feb 2000, Sascha Schumann wrote: > You should try to produce a test case (not longer than 10 > lines), so please try to reduce the length of your script. It > makes it much easier to trace down a bug, if we have a simple > script which reliable reproduces the bug. Thanks. I just wondered if it blew up on other people's boxes. It's very hard to get a small test case because it's an absurdly unstable bug - if I change a var_dump here or an if there it stops SEGVing. I understand it's hard to track down bugs like this, but I can help if I have at least some pointer as to what I should look for. The following test case blows up here on three different systems (doesn't on my FreeBSD system, alas) with different php binaries (for different databases and with different options) - I just wonder if anyone is able to run this on Linux without a SEGV. Okay, it's about 10 lines - not too small. But if I remove the eregi or the base64_decode it runs fine. Some lost pointer somewhere that surprisingly isn't causing data corruption. <? $str="[brain] =?iso-8859-1?B?RWR1Y2Hn428g4CBEaXN04m5jaWE=?="; if (eregi("=?([A-Z,0-9,-]+)?([A-Z,0-9,-]+)?([A-Z,0-9,-,=,_]+)?=", $str)) { $coded_strings = explode(' =?', $str); while ($counter < sizeof($coded_strings)) { $elements = explode('?', $coded_strings[$counter]); base64_decode(str_replace('=', '',$elements[2])); $counter++; } } ?> Better? Cheers, -- _/\ Christian Reis is sometimes kiko@radiumsystems.com.br \/~ suicide architect | free software advocate | mountain biker