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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
