Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:28694 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56501 invoked by uid 1010); 5 Apr 2007 18:37:58 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 56485 invoked from network); 5 Apr 2007 18:37:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Apr 2007 18:37:58 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 204.11.219.139 mail.lerdorf.com Linux 2.5 (sometimes 2.4) (4) Received: from [204.11.219.139] ([204.11.219.139:34052] helo=lerdorf.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 87/A4-09267-40245164 for ; Thu, 05 Apr 2007 14:37:58 -0400 Received: from [207.126.233.18] (rasmus2.corp.yahoo.com [207.126.233.18]) (authenticated bits=0) by lerdorf.com (8.13.8/8.13.8/Debian-3) with ESMTP id l35IanV5008858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Apr 2007 11:37:51 -0700 Message-ID: <461541C1.4080404@lerdorf.com> Date: Thu, 05 Apr 2007 11:36:49 -0700 User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Rob Richards CC: RQuadling@googlemail.com, Ilia Alshanetsky , Matt Wilmas , internals@lists.php.net References: <007b01c77735$89410420$0201a8c0@pc1> <46148933.7030709@lerdorf.com> <646617A7-86A7-4E64-94CE-8E5D5766741A@prohost.org> <10845a340704050742n38ef04c0t7f6f2ad85e2711b5@mail.gmail.com> <46151547.6000505@lerdorf.com> <10845a340704050830p6611aa73n6f81806618d5072a@mail.gmail.com> <46153A67.3010208@ctindustries.net> In-Reply-To: <46153A67.3010208@ctindustries.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/3022/Thu Apr 5 11:04:09 2007 on colo X-Virus-Status: Clean Subject: Re: [PHP-DEV] Build failure From: rasmus@lerdorf.com (Rasmus Lerdorf) That still doesn't make sense to me. Could you try doing an sprintf() followed by an fwrite() then? Is fprintf() perhaps doing something stupid internally? I'd really like to avoid a lock here. -Rasmus Rob Richards wrote: > I can confirm that it does fail with the single fprintf call without the > lock on Win32. > Using flock() does fix the problem in my tests. > I was able to fix win build using flock() instead of php_flock() and > defining HAVE_FLOCK in win32/flock.h > > Rob > > Richard Quadling wrote: >> This test is with the multiline fprintf and no lock. >> >> Adding the php_flock() has stalled the build process for Win32 (I >> can't build on Win32 as I don't know how!). >> >> >> >> On 05/04/07, Rasmus Lerdorf wrote: >>> Yes, but again, is this test with the single fprintf call? That's the >>> real fix for this problem, not the lock. >>> >>> -Rasmus >>> >>> Richard Quadling wrote: >>> > Using PHP 5.2.2-dev (cli) (built: Mar 23 2007 07:02:57) I can >>> > replicate the problem on Windows. >>> > >>> > Using this single line command at the CMD prompt: >>> > >>> > for %x in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do >>> > start php -r >>> > >>> "ini_set('error_log','/tmp/test.log');for($i=0;$i<100;$i++)error_log(str_repeat('%x',5000));" >>> >>> > >>> > >>> > The log file has many broken lines. >>> > >>> > On 05/04/07, Ilia Alshanetsky wrote: >>> >> Rasmus, >>> >> >>> >> Sorry for the delay in the reply. According to my tests on linux >>> >> using the sample script provided by the original bug reporter having >>> >> no lock causes a problem when the error message is >4k in length. In >>> >> this case multiple buffers are used and corruption can happen (it did >>> >> on a dual cpu machine with 10 error log writing threads running), >>> >> which is why I feel the lock is needed. >>> >> >>> >> >>> >> On 5-Apr-07, at 1:29 AM, Rasmus Lerdorf wrote: >>> >> >>> >> > Matt Wilmas wrote: >>> >> >> Hi, >>> >> >> >>> >> >> Maybe just a Windows problem if it wasn't noticed yet, but I was >>> >> >> compiling >>> >> >> the latest 5.2 snapshot and got: >>> >> >> >>> >> >> main.obj : error LNK2019: unresolved external symbol _php_flock >>> >> >> referenced >>> >> >> in function _php_log_err >>> >> >> Release_TS\php5ts.dll : fatal error LNK1120: 1 unresolved >>> externals >>> >> >> >>> >> >> Caused by this recent commit, http://news.php.net/php.cvs/43683, >>> >> >> and I >>> >> >> commented the php_flock line as a workaround. The Windows 5.2 >>> >> >> snapshots >>> >> >> haven't been updated because of this either, of course. >>> >> > >>> >> > I see no reason for that lock at all as I commented when this was >>> >> > committed, but Ilia never replied. This is a single write >>> >> > operation now >>> >> > since those fprintf's are now one, so that part of the fix is good, >>> >> > but >>> >> > the lock call is not needed since single writes in append mode are >>> >> > atomic, even on Windows. >>> >> > >>> >> > So, your work around is fine and should actually be committed. >>> >> > >>> >> > -Rasmus >>> >> > >>> >> > -- >>> >> > PHP Internals - PHP Runtime Development Mailing List >>> >> > To unsubscribe, visit: http://www.php.net/unsub.php >>> >> > >>> >> >>> >> Ilia Alshanetsky >>> >> >>> >> -- >>> >> PHP Internals - PHP Runtime Development Mailing List >>> >> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >>> >> >>> > >>> > >>> >>> >> >>