No difference using sprintf()/fwrite() instead of fprintf().
I did come across a similar issue from apache:
http://mail-archives.apache.org/mod_mbox/httpd-dev/199503.mbox/[EMAIL PROTECTED]
Changing to use VCWD_OPEN_MODE, write() and close() seems to work.
Rob
Rasmus Lerdorf wrote:
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
