Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Build failure »

Build failure

php.internals

Matt W

19 years ago
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. Matt

Rasmus Lerdorf

19 years ago
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

Richard Quadling

19 years ago
http://rquadling.php1h.com/main.c.diff.txt for HEAD. I don't know how to patch a specific version. On 05/04/07, Rasmus Lerdorf <rasmus@lerdorf.com> 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 > >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Ilia A.

19 years ago
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

Richard Quadling

19 years ago
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 <ilia@prohost.org> 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 > >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Richard Quadling

19 years ago
Using ProcMon on WinXP, you can see that the different processes interleave the writes but in blocks of 4096 bytes. The remaining 929 bytes will sometimes be written after another processes 4096/929 bytes. Locking IS required here. On 05/04/07, Richard Quadling <rquadling@googlemail.com> 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 <ilia@prohost.org> 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 > > > > > > > -- > ----- > Richard Quadling > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > "Standing on the shoulders of some very clever giants!" >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Rasmus Lerdorf

19 years ago
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:

Richard Quadling

19 years ago
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 <rasmus@lerdorf.com> 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 <ilia@prohost.org> 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 > >> > >> > > > > > >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Rob Richards

19 years ago
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:

Rasmus Lerdorf

19 years ago
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:

Rob Richards

19 years ago
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/%3C9502272049.aa02036@paris.ics.uci.edu%3E Changing to use VCWD_OPEN_MODE, write() and close() seems to work. Rob Rasmus Lerdorf wrote:

Richard Quadling

19 years ago
On 05/04/07, Rob Richards <rrichards@ctindustries.net> wrote:
> 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/%3C9502272049.aa02036@paris.ics.uci.edu%3E > > Changing to use VCWD_OPEN_MODE, write() and close() seems to work. > > Rob >
Using PHP 5.2.2RC2-dev (cli) (built: Apr 13 2007 04:03:02) on Windows with 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<1000;$i++)error_log(str_repeat('%x',5000));"`; And then doing some analysis of the log file I'm finding that not all the data has been written. Array ( [A] => 4965993 [B] => 4590918 [C] => 4525905 [D] => 4695939 [E] => 4495899 [F] => 4710942 [G] => 4495899 [H] => 4645929 [I] => 4540908 [J] => 4580916 [K] => 4535907 [L] => 4470894 [M] => 4480896 [N] => 4550910 [O] => 4610922 [P] => 4500900 [Q] => 4630926 [R] => 4480896 [S] => 4500900 [T] => 4535907 [U] => 4630926 [V] => 4470894 [W] => 4645929 [X] => 4825965 [Y] => 4845969 [Z] => 4920984 ) Lines (Should be 26 * 1000) : 23973 Longest (Should be 5024) : 5024 Shortest (Should be 5024) : 5024 Out of the 26,000 lines expected we are missing 2027 lines. So no corruption of the lines, just missing ones. The only explanation I can think of is that the locking is working, but nothing is waiting for the lock to become available. Richard.
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Rasmus Lerdorf

19 years ago
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.
Did you do this test before or after you condensed the fprintf calls into a single call? With multiple fprintf calls there would be a problem, but with a single one I don't see how it could possibly screw it up. -Rasmus

Richard Quadling

19 years ago
Is it possible that at the lowest layer within the C library that 4K blocking is performed? On 05/04/07, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> 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. > > Did you do this test before or after you condensed the fprintf calls > into a single call? With multiple fprintf calls there would be a > problem, but with a single one I don't see how it could possibly screw > it up. > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"