Ubuntu 9.10 (64) linking/building issues
François Battail
the build process is like playing with nitroglycerin ;-)
Some issues I have with Ubuntu 9.10 (64 bits):
Almost all libs were compiled and installed into /usr/local/lib
(libevent, icu, libmbfl, boost...), old versions were *not* present
in /usr/lib.
- libmbfl was compiled and installed into /usr/local/lib but Makefile
makes reference to $HPHP_HOME/bin/libmbfl.a (of course I've done [many
time] rm CMakeCache.txt && cmake . to ensure a complete rebuild)
- libexpat is not present in the Makefile so linking the runtime or
the HPHP application fails (just need to put -lexpat in the good
files),
- I've an error in the build process of Wordpress (with the hphp
patch):
fb@rangiroa:/tmp/hphp_0Blizv$ make
make[2]: *** Pas de règle pour fabriquer la cible « cls/
services_json_error$0.h », nécessaire pour « CMakeFiles/program.dir/
php/wp-includes/class-json.cpp.o ». Arrêt.
(Translation: No rule to make target "cls/services_json_error$0.h"
needed for "CMakeFiles/program.dir/php/wp-includes/class-json.cpp.o".
Halt.)
The file present is named "service_json_error$$0.h" (two $). I believe
it's an escaping character problem between CMake / make or whatever
but so far I'm stuck on this...
Best regards and thank you for your help
Haiping Zhao
needed for "CMakeFiles/program.dir/php/wp-includes/class-json.cpp.o
The $$ is our separator for redeclaring classes or functions. So, you have
two Service_json_error classes in your PHP files, then one is called
service_json_error$$0 and another one service_json_error$$1.
I have never run into this problem myself, so I can only guess. Try "make
clean and make" from that tmp directory to see if it helps. If not, see if
you can come up with a small repro and send it to me.
Thanks! I'll have to let Scott answer other questions.
-Haiping
François Battail
New installation following this document:
http://wiki.github.com/facebook/hiphop-php/building-and-installing-on-ubuntu-910
(Thanks to serphen)
I've also applied these patches:
http://github.com/facebook/hiphop-php/commit/aec0f563bcb2216ca3c7b8dc03b10a2c063bd2e0
http://github.com/facebook/hiphop-php/commit/d1d06549de983ab225bc31c753e664fcda55cf5a
(Thanks to carsonmcdonald)
Build went nicely (but slowly ;-) ).
Still have an issue with Wordpress (patched for HPHP) when accessing
index.php: "Error establishing a database connection". libmysqlclient-
dev was installed, mysql is running, wp-config.php is OK and it's the
same file I'm using with Apache without any problem. The server was
invoked with the following command:
fb@rangiroa:~/hiphop-php/src/hphp/wordpress$ test/program -m server -p
8081 -v "Server.SourceRoot=`pwd`" -v
"Server.DefaultDocument=index.php" -c $HPHP_HOME/bin/mime.hdf -v
"Log.Level=Verbose" -v "Log.NoSilencer=on"
Compilation was done using:
fb@rangiroa:~/hiphop-php/src/hphp/wordpress$ ../hphp --log=3 -k 1 --
force=1 --input-list=files.list --cluster-count=50 --output-dir=test
A warning was issued, but I don't think it's a problem right now
(maybe later):
CMake Warning at CMakeLists.txt:39 (add_executable):\n Cannot
generate a safe runtime search path for target program because files
\n in some directories may conflict with libraries in implicit
directories:\n\n runtime library [libonig.so.2] in /usr/lib may be
hidden by files in:\n /usr/local/lib\n\n Some of these libraries
may not be found correctly.\n\n\n
Any hint for investigating this database connection problem?
Best regards
roberto chessa
I've the same problem with a centos 5.4 x64.
Everything during compilation was ok, but when i access index.php from
browser the error is "Error establishing a database connection".
regards,
Roberto
Mickey Shine
database connection". Everything else seems to be fine.
Ivan Jovanovic
I had the same problem with database connection but managed to
overcome it by using IP of the
loopback interface 127.0.0.1 instead of localhost as host address in
wp-config.php
ji
On Feb 25, 7:56 am, Mickey Shine <bluefl...@gmail.com> wrote:
> I am using CentOS 5.3 and I got the same "Error establishing adatabaseconnection". Everything else seems to be fine.
Arnaud Granal
> Hi,
>
> I had the same problem with database connection but managed to
> overcome it by using IP of the
> loopback interface 127.0.0.1 instead of localhost as host address in
> wp-config.php
>
Two ideas about this issue, however someone needs to confirm:
- When you enter localhost, PHP uses mysql.sock instead of TCP/IP.
or - localhost tries to connect ::1 in IPv6 but doesn't work.
I think the first thingy is probable, someone may look at it.
Arnaud.
Marcel Esser
just type 'localhost'. It has caused a lot of confusion and anger in
the past.
- M.
google-...@enfinity.hu
> database connection". Everything else seems to be fine.
Try to use IP address instead of domain or set domain in your DNS
server.
HipHop doesn't use hosts file, it lookups in DNS for IP addresses.
ivan
Rasmus Lerdorf
the MySQL client library. However, hphp is doing something odd here.
Try this simple PHP script:
<?php
$res1 = mysql_connect('127.0.0.1','root','',true);
var_dump($res1);
$res2 = mysql_connect('localhost','root','',true);
var_dump($res2);
$res3 = fopen('/tmp/foo','w+');
var_dump($res3);
You should get:
resource(4) of type (mysql link)
resource(5) of type (mysql link)
resource(7) of type (stream)
Assuming, of course, your MySQL is listening on both the unix domain
socket and tcp and your credentials are ok. But, run the same thing
under hphp and you will find that $res2 is blank. Looking through
ext_mysql.cpp I don't see an obvious reason for this, but I haven't
pointed a debugger at it yet to figure it out.
The other weirdness I have noticed is that hphp will fail on the 72nd
consecutive "else if". 71 is fine, but 72 breaks. Weird limit.
Try compiling this: http://codepad.org/0RgWGp4G
Then remove an "else if" and try again.
-Rasmus
Haiping Zhao
I "fixed" the 72-else problem, but I ran into some minor problems with my
fix that I haven't got a chance to fix the fix yet. But basically it's from
the fact yacc doesn't generate C++ non-POD stack resizing function, so
generated code overflows the stack and gives an error.
As to mysql_connect, I'm fixing that right now. Scott already figured out
what's going on. This is something we can fix really quickly. From Scott:
"Most systems run MySQL in socket mode rather than TCP. When this is the
case port 3306 is actually closed.
The C API mysql_real_connect() function does some slight magic here, when
the host has a value of "localhost" and the socket parameter is provided it
silently switches to that and ignores the localhost value.
At the moment there is no default value provided for GetDefaultSocket() so
when we call mysql_real_connect this value is an empty string and an error
occurs since the MySQL server is really running in socket only mode."
-Haiping
Scott MacVicar
> The PHP mysql driver has nothing to do with this. This is a feature of
> the MySQL client library. However, hphp is doing something odd here.
> Try this simple PHP script:
>
> <?php
> $res1 = mysql_connect('127.0.0.1','root','',true);
> var_dump($res1);
> $res2 = mysql_connect('localhost','root','',true);
> var_dump($res2);
> $res3 = fopen('/tmp/foo','w+');
> var_dump($res3);
>
> You should get:
>
> resource(4) of type (mysql link)
> resource(5) of type (mysql link)
> resource(7) of type (stream)
>
> Assuming, of course, your MySQL is listening on both the unix domain
> socket and tcp and your credentials are ok. But, run the same thing
> under hphp and you will find that $res2 is blank. Looking through
> ext_mysql.cpp I don't see an obvious reason for this, but I haven't
> pointed a debugger at it yet to figure it out.
It's the magic in mysql_real_connect() when localhost is used as a value for host and socket is a non NULL value, mysql_real_connect will use the socket instead, at the moment we return "" as the default socket value rather than NULL so its trying to connect with that which it obviously can't do.
I'll look into getting this fixed soonish.
>
> The other weirdness I have noticed is that hphp will fail on the 72nd
> consecutive "else if". 71 is fine, but 72 breaks. Weird limit.
>
> Try compiling this: http://codepad.org/0RgWGp4G
> Then remove an "else if" and try again.
This is fixed internally, looking to sync up the trees again shortly after we move to git internally.
Scott
Rasmus Lerdorf
> Hey, Rasmus, definitely glad to "meet" you here :-)
>
> I "fixed" the 72-else problem, but I ran into some minor problems with my
> fix that I haven't got a chance to fix the fix yet. But basically it's from
> the fact yacc doesn't generate C++ non-POD stack resizing function, so
> generated code overflows the stack and gives an error.
>
> As to mysql_connect, I'm fixing that right now. Scott already figured out
> what's going on. This is something we can fix really quickly. From Scott:
>
> "Most systems run MySQL in socket mode rather than TCP. When this is the
> case port 3306 is actually closed.
>
> The C API mysql_real_connect() function does some slight magic here, when
> the host has a value of "localhost" and the socket parameter is provided it
> silently switches to that and ignores the localhost value.
>
> At the moment there is no default value provided for GetDefaultSocket() so
> when we call mysql_real_connect this value is an empty string and an error
> occurs since the MySQL server is really running in socket only mode."
Yes, I know all about that magic. Seems like you need the cmake
equivalent of the PHP_MYSQL_SOCKET_SEARCH macro from ext/mysql/config.m4
or just provide a way to specify it, I guess.
By the way, is there any known issue that would cause an initial request
to work, but all subsequent requests to generate a 500 error without any
useful log messages. I'm running with
-v "Log.Level=Verbose" -v "Log.NoSilencer=on" -v "Log.Header=on"
and the first php request works, but then all subsequent requests, even
static .css files don't. If I hit a static .css file first, then that
will work repeatedly until I hit the php page. My first guess was
something related to register_shutdown_function() but that doesn't
appeat to be the case.
-Rasmus
Scott MacVicar
On 4 Mar 2010, at 01:03, Rasmus Lerdorf wrote:
> On 03/03/2010 11:53 PM, Haiping Zhao wrote:
>> Hey, Rasmus, definitely glad to "meet" you here :-)
>>
>> I "fixed" the 72-else problem, but I ran into some minor problems with my
>> fix that I haven't got a chance to fix the fix yet. But basically it's from
>> the fact yacc doesn't generate C++ non-POD stack resizing function, so
>> generated code overflows the stack and gives an error.
>>
>> As to mysql_connect, I'm fixing that right now. Scott already figured out
>> what's going on. This is something we can fix really quickly. From Scott:
>>
>> "Most systems run MySQL in socket mode rather than TCP. When this is the
>> case port 3306 is actually closed.
>>
>> The C API mysql_real_connect() function does some slight magic here, when
>> the host has a value of "localhost" and the socket parameter is provided it
>> silently switches to that and ignores the localhost value.
>>
>> At the moment there is no default value provided for GetDefaultSocket() so
>> when we call mysql_real_connect this value is an empty string and an error
>> occurs since the MySQL server is really running in socket only mode."
>
> Yes, I know all about that magic. Seems like you need the cmake
> equivalent of the PHP_MYSQL_SOCKET_SEARCH macro from ext/mysql/config.m4
> or just provide a way to specify it, I guess.
Pushed the CMake macro into the github now, will hopefully sync the entire tree tomorrow which will hook this up.
>
> By the way, is there any known issue that would cause an initial request
> to work, but all subsequent requests to generate a 500 error without any
> useful log messages. I'm running with
> -v "Log.Level=Verbose" -v "Log.NoSilencer=on" -v "Log.Header=on"
> and the first php request works, but then all subsequent requests, even
> static .css files don't. If I hit a static .css file first, then that
> will work repeatedly until I hit the php page. My first guess was
> something related to register_shutdown_function() but that doesn't
> appeat to be the case.
>
Just a simple hello world app or something more complex?
Scott
Rasmus Lerdorf
>> By the way, is there any known issue that would cause an initial request
>> to work, but all subsequent requests to generate a 500 error without any
>> useful log messages. I'm running with
>> -v "Log.Level=Verbose" -v "Log.NoSilencer=on" -v "Log.Header=on"
>> and the first php request works, but then all subsequent requests, even
>> static .css files don't. If I hit a static .css file first, then that
>> will work repeatedly until I hit the php page. My first guess was
>> something related to register_shutdown_function() but that doesn't
>> appeat to be the case.
>>
>
> Just a simple hello world app or something more complex?
No, Hello World works fine. Trying to get the current Wordpress-svn to
work reliably on it. I have been ripping stuff out to try to identify
what is tripping it up, but so far no luck. The initial request for
index.php is fine. Then I get:
[Thu Mar 4 01:50:08 2010] [hphp] [24111:7f934fcaf910:1:000001]
[2039d93:20443bd:2049841:1992835:7f93584eaa04:7f935644880d] receiving
wp-content/themes/default/style.css
[Thu Mar 4 01:50:08 2010] [hphp] [24111:7f9347fff910:1:000001]
[2039d93:20443bd:2049841:1992835:7f93584eaa04:7f935644880d] receiving
wp-content/themes/default/images/kubrickbg-ltr.jpg
That trace translates to:
# 0 HPHP::HttpRequestHandler::handleRequest(HPHP::Transport*) at
/tmp/hphp_Zt1KvI/program:0
# 1 HPHP::LibEventWorker::doJob(boost::shared_ptr<HPHP::LibEventJob>)
at /tmp/hphp_Zt1KvI/program:0
# 2 HPHP::JobQueueWorker<boost::shared_ptr<HPHP::LibEventJob>,
true>::start() at /tmp/hphp_Zt1KvI/program:0
# 3 HPHP::AsyncFuncImpl::ThreadFunc(void*) at /tmp/hphp_Zt1KvI/program:0
# 4 ?? at ??:0
# 5 ?? at ??:0
And trying to hit the URL directly gives me the same thing, as does
trying to reload index.php or anything else.
-Rasmus
Haiping Zhao
Sent from my iPhone
Ivan Jovanovic
Ubuntu 9.10 32bit.
I tried with MemoryManager param but it doesn't work.
Wordpress is newest from their SVN.
One warning that I get when running the server is
Could not get mlockall
Cheers,
Ivan
Rasmus Lerdorf
complete output from a run: http://codepad.org/HXBrEPuD
You can see that the initial request for index.php works nicely. All
the MySQL queries are executed and the browser knows it also needs to
fetch wp-content/themes/default/style.css and
wp-content/themes/default/images/kubrickbg-ltr.jpg but these are never
delivered. And then a shift-reload doesn't work to try to get index.php
to run again. And a direct request for
wp-content/themes/default/style.css fails too. If my first request
after starting the server is for wp-content/themes/default/style.css
then I can fetch that as many times as I like and it works every time
until I load index.php again. EnableMemoryManager=1 doesn't change
this. Also, index.php doesn't always load the first time either. About
half the time I start the server the initial request for index.php fails.
-Rasmus
Haiping Zhao
-Haiping
Rasmus Lerdorf
> Hmm, weird, any errors from the error log/output?
No, that is the annoying part. It gives a 500 response without a single
hint as to what went wrong.
-Rasmus
Arnaud Granal
Could you please push somewhere a tarball of the source directory
(even if some elems are stripped) and the commandline you are using to
build the HipHop server ?
So we can try to reproduce the exact bug (I setuped a 64 bits Ubuntu
9.10 box for your debug) and fix it.
I have checked out the latest WP sources from SVN but I can't
reproduce your bug (after fixing some issues like "wp-admin/includes/
class-ftp.php:require_once "class-ftp-".
($mod_sockets?"sockets":"pure").".php";")
Thanks,
Arnaud.
Haiping Zhao
sending 500, and let me know the stacktrace? That may help me understand the
code path. Thanks.
-Haiping
Ryan Biesemeyer
itself after a runtime error in one of the "php" pages:
Invalid operand type was used: array_merge expects array(s)
In this case, I'm running a compiled wordpress from svn trunk
(currently rev 13433). I'm running the server verbose with headers,
translated to get this trace:
# 0 HPHP::throw_bad_type_exception(char const*, ...) at /tmp/
hphp_8shnap/program:0
# 1 HPHP::f_array_merge(int, HPHP::Variant const&, HPHP::Array
const&) at /tmp/hphp_8shnap/program:0
# 2 HPHP::f_wp_get_schedules() at /tmp/hphp_8shnap/program:0
# 3 HPHP::f_wp_cron() at /tmp/hphp_8shnap/program:0
# 4 HPHP::i_wp_cron(char const*, HPHP::Array const&, long long, bool)
at /tmp/hphp_8shnap/program:0
# 5 HPHP::invoke(char const*, HPHP::Array const&, long long, bool,
bool) at /tmp/hphp_8shnap/program:0
# 6 HPHP::f_call_user_func_array(HPHP::Variant const&, HPHP::Array
const&) at /tmp/hphp_8shnap/program:0
# 7 HPHP::f_do_action(int, HPHP::Variant const&, HPHP::Variant,
HPHP::Array) at /tmp/hphp_8shnap/program:0
# 8 HPHP::pm_php$wp_settings_php(bool, HPHP::LVariableTable*) at /tmp/
hphp_8shnap/program:0
# 9 HPHP::invoke_file(HPHP::String const&, bool,
HPHP::LVariableTable*, char const*) at /tmp/hphp_8shnap/program:0
# 10 HPHP::include_impl(HPHP::String const&, bool,
HPHP::LVariableTable*, char const*, bool) at builtin_functions.cpp:0
# 11 HPHP::require(HPHP::String const&, bool, HPHP::LVariableTable*,
char const*) at /tmp/hphp_8shnap/program:0
# 12 HPHP::pm_php$wp_config_php(bool, HPHP::LVariableTable*) at /tmp/
hphp_8shnap/program:0
# 13 HPHP::invoke_file(HPHP::String const&, bool,
HPHP::LVariableTable*, char const*) at /tmp/hphp_8shnap/program:0
# 14 HPHP::include_impl(HPHP::String const&, bool,
HPHP::LVariableTable*, char const*, bool) at builtin_functions.cpp:0
# 15 HPHP::require(HPHP::String const&, bool, HPHP::LVariableTable*,
char const*) at /tmp/hphp_8shnap/program:0
# 16 HPHP::pm_php$wp_load_php(bool, HPHP::LVariableTable*) at /tmp/
hphp_8shnap/program:0
# 17 HPHP::invoke_file(HPHP::String const&, bool,
HPHP::LVariableTable*, char const*) at /tmp/hphp_8shnap/program:0
# 18 HPHP::include_impl(HPHP::String const&, bool,
HPHP::LVariableTable*, char const*, bool) at builtin_functions.cpp:0
# 19 HPHP::require(HPHP::String const&, bool, HPHP::LVariableTable*,
char const*) at /tmp/hphp_8shnap/program:0
# 20 HPHP::pm_php$wp_blog_header_php(bool, HPHP::LVariableTable*) at /
tmp/hphp_8shnap/program:0
# 21 HPHP::pm_php$index_php(bool, HPHP::LVariableTable*) at /tmp/
hphp_8shnap/program:0
# 22 HPHP::invoke_file(HPHP::String const&, bool,
HPHP::LVariableTable*, char const*) at /tmp/hphp_8shnap/program:0
# 23 HPHP::hphp_invoke(HPHP::ExecutionContext*,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, bool, HPHP::Array const&, HPHP::Variant,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, bool&, std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&) at /tmp/hphp_8shnap/
program:0
# 24 HPHP::HttpRequestHandler::executePHPRequest(HPHP::Transport*,
HPHP::RequestURI&, HPHP::SourceRootInfo&, bool) at /tmp/hphp_8shnap/
program:0
# 25 HPHP::HttpRequestHandler::handleRequest(HPHP::Transport*) at /tmp/
hphp_8shnap/program:0
# 26 HPHP::LibEventWorker::doJob(boost::shared_ptr<HPHP::LibEventJob>)
at /tmp/hphp_8shnap/program:0
# 27 HPHP::JobQueueWorker<boost::shared_ptr<HPHP::LibEventJob>,
true>::start() at /tmp/hphp_8shnap/program:0
# 28 HPHP::AsyncFuncImpl::ThreadFunc(void*) at /tmp/hphp_8shnap/
program:0
# 29 ?? at ??:0
# 30 ?? at ??:0
Rasmus Lerdorf
Right, there are quite a few other fixes, some probably not necessary,
but see my diff here:
That's the diff against svn, the build command, files.list, and just in
case, my hphp directory containing the binary, but I'd be surprised if
the binary was somehow at fault.
-Rasmus
Rasmus Lerdorf
> Hmmm. Would you set a breakpoint on LibEventTransport::sendImpl() when
> sending 500, and let me know the stacktrace? That may help me understand the
> code path. Thanks.
Doesn't seem very helpful, but here it is:
[Thu Mar 4 19:01:39 2010] [hphp] [15477:7fffd37de910:1:000001]
[2039983:2043fad:2049431:1992425:7ffff5cb2a04:7ffff3c1080d] receiving
wp-content/themes/default/style.css
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7fffd37de910 (LWP 15539)]
0x000000000217c182 in HPHP::LibEventTransport::sendImpl(void const*,
int, int, bool) ()
(gdb) bt
#0 0x000000000217c182 in HPHP::LibEventTransport::sendImpl(void const*,
int, int, bool) ()
#1 0x00000000019799b0 in HPHP::Transport::sendRaw(void*, int, int,
bool, bool) ()
#2 0x00000000020441ad in
HPHP::LibEventWorker::doJob(boost::shared_ptr<HPHP::LibEventJob>) ()
#3 0x0000000002049431 in
HPHP::JobQueueWorker<boost::shared_ptr<HPHP::LibEventJob>, true>::start() ()
#4 0x0000000001992425 in HPHP::AsyncFuncImpl::ThreadFunc(void*) ()
#5 0x00007ffff5cb2a04 in start_thread (arg=<value optimized out>) at
pthread_create.c:300
#6 0x00007ffff3c1080d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7 0x0000000000000000 in ?? ()
-Rasmus
Haiping Zhao
There is a switch called "Log.AlwaysLogUnhandledExceptions". Please set this
to true as well. Hopefully we can see why 500 errors.
I'm attaching the documentation on RuntimeOptions. Hopefully it can help
setting those flags. Thanks!
-Haiping
Rasmus Lerdorf
> No :-) I suspect WordPress has some error handler, swallowing some errors?
> There is a switch called "Log.AlwaysLogUnhandledExceptions". Please set this
> to true as well. Hopefully we can see why 500 errors.
But, the 500 is also coming from requests for static files, so it would
seem that whatever Wordpress is doing is putting hphp into some weird
state where it can no longer serve anything. I'll try to the option you
suggest, but I have to wait for a rebuild to remove some debug stuff on
my slow box here.
-Rasmus
Arnaud Granal
> On 03/04/2010 12:16 PM, Haiping Zhao wrote:
>
> > Hmmm. Would you set a breakpoint on LibEventTransport::sendImpl() when
> > sending 500, and let me know the stacktrace? That may help me understand the
> > code path. Thanks.
>
> Doesn't seem very helpful, but here it is:
>
>
>
>
Everything looks right there.
Can you run the server with -v "Debug.ServerErrorMessage=true" ?
This should make the 500 error more verbose.
Mmmhh, these features really need to be documented.
Someone wants a Wiki page about all secret parameters ?
Arnaud.
Rasmus Lerdorf
> Everything looks right there.
>
> Can you run the server with -v "Debug.ServerErrorMessage=true" ?
Aha, that helped:
Fatal error: request has exceeded memory limit.
# 0 HPHP::Exception::Exception() at /tmp/hphp_CI24YN/program:0
# 1 HPHP::ExtendedException::ExtendedException() at
/tmp/hphp_CI24YN/program:0
# 2 HPHP::FatalErrorException::FatalErrorException(char const*, ...) at
/tmp/hphp_CI24YN/program:0
# 3 HPHP::SmartAllocatorImpl::alloc() at /tmp/hphp_CI24YN/program:0
# 4 HPHP::String::String(char const*, HPHP::StringDataMode) at
/tmp/hphp_CI24YN/program:0
# 5 HPHP::RequestURI::splitURL(HPHP::String, HPHP::String&,
HPHP::String&) at /tmp/hphp_CI24YN/program:0
# 6 HPHP::RequestURI::process(HPHP::VirtualHost const*,
HPHP::Transport*, std::basic_string<char, std::char_traits><char>,
std::allocator<char> > const&, std::basic_string<char,
std::char_traits><char>, std::allocator<char> > const&, char const*) at
/tmp/hphp_CI24YN/program:0
# 7 HPHP::RequestURI::RequestURI(HPHP::VirtualHost const*,
HPHP::Transport*, std::basic_string<char, std::char_traits><char>,
std::allocator<char> > const&, std::basic_string<char,
std::char_traits><char>, std::allocator<char> > const&) at
/tmp/hphp_CI24YN/program:0
# 8 HPHP::HttpRequestHandler::handleRequest(HPHP::Transport*) at
/tmp/hphp_CI24YN/program:0
# 9 HPHP::LibEventWorker::doJob(boost::shared_ptr<HPHP::LibEventJob>)
at /tmp/hphp_CI24YN/program:0
# 10 HPHP::JobQueueWorker<boost::shared_ptr><HPHP::LibEventJob>,
true>::start() at /tmp/hphp_CI24YN/program:0
# 11 HPHP::AsyncFuncImpl::ThreadFunc(void*) at /tmp/hphp_CI24YN/program:0
# 12 start_thread at /build/buildd/eglibc-2.10.1/nptl/pthread_create.c:300
# 13 __clone at
/build/buildd/eglibc-2.10.1/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:114
So, after getting that memory limit error, all requests from then on get
the same error.
-Rasmus
Arnaud Granal
> On 03/04/2010 08:09 PM, Arnaud Granal wrote:
>
> > Everything looks right there.
>
> > Can you run the server with -v "Debug.ServerErrorMessage=true" ?
>
> Aha, that helped:
>
> Fatal error: request has exceeded memory limit.
>
Great!
I am going to investigate (in a few hours however) where the leak
comes from except if somebody goes faster than me.
This is SmartAllocator, not SmartGC :o)
Arnaud.
Haiping Zhao
really need to merge quicker :-)
1. ini_set("memory_limit", "100MB") will actually set memory limit to 100
bytes.
2. The code in smart_allocator.cpp should read like this with some extra
checking to make sure it doesn't get triggered all the time.
if (m_stats) {
m_stats->usage += m_itemSize;
if (m_stats->usage > m_stats->peakUsage) {
int64 prevPeakUsage = m_stats->peakUsage;
m_stats->peakUsage = m_stats->usage;
int64 maxBytes = g_context->getRequestMemoryMaxBytes(); // this was
RuntimeOption::RequestMemoryMaxBytes
if (maxBytes > 0 && m_stats->peakUsage > maxBytes &&
prevPeakUsage <= maxBytes) {
throw FatalErrorException("request has exceeded memory limit");
}
}
}
-Haiping
Haiping Zhao
cpp/base/smart_allocator.cpp. It should work for you before we merge.
BTW, when we merge, you will find we moved directories around with new
names. Hopefully better names,
cpp => runtime
lib => compiler
lib/system => system
-Haiping
Haiping Zhao
Rasmus Lerdorf
> For now, the easiest for you is to comment out the "throw" line in
> cpp/base/smart_allocator.cpp. It should work for you before we merge.
Yup, thanks guys. I now have it running reliably it seems.
-Rasmus
Ivan Jovanovic
I tried to install Wordpress from scratch now and I get following
error when I turned on "Debug.ServerErrorMessage=true"
It appears in the moment when I submit final form in the installation
process, probably starting to populate DB tables since they are empty
afterwards.
Error88201b0:8820292:881c7b3:82b0f45:82c28e2:8b68804:8b46324:824177a:
88cbc0e:8abde5d:858e0f7:87030a8:823202d:88fd743:8904b7e:890e76f:
88fe10f:8905639:890802b:88fd67c:8904b7e:890e76f:88fe10f:
8905639:890802b:88fd67c:8904b7e:890e76f:88fe10f:890b8af:
890bf47:88fe10f:8905639:890802b:88fd67c:891540d:88fe10f:
8905639:890802b:88fd67c:8904b7e:890e76f:890aa09:88fe10f:
8905639:8906c57:88fb262:8b46c39:8b44fd7:891c1ff:82ec5ca:8231d6e:
891001f:8904b7e:890e76f:88fe10f:8905639:890802b:88fd67c:8904b7e:
890e76f:88fe10f:890aa09:88fe10f:890b8af:890bf47:88fe10f:
8b4ae89:88ed47b:82ec4aa:8236031:82903bd:887af1e:
887bf48:8897f32:889d132:889aa3c:
8817cb6:ffffffffb70f780e:ffffffffb6cbd8de Bad type conversion:
WP_Error::__toString() was not defined.
Can I convert the errors to something more useful. I saw some param
that enables that but can not find it now.
Thanks for great work,
Ivan
Ivan Jovanovic
through hphpi.