|
From: 周旭 <zho...@gm...> - 2012-06-07 02:35:02
|
Hi, I encounter a problem of running Apache httpd server using Valgrind. Valgrind seems to decrease the performance of Apache server too much that the client always report a timeout error. I am also not sure if I used the correct command line option. I just type "Valgrind --tool=xxx ./httpd start". I don't know what is wrong, so I ask for your help. Thanks. --- Xu Zhou |
|
From: John R. <jr...@bi...> - 2012-06-07 03:57:36
|
> I encounter a problem of running Apache httpd server using Valgrind. > Valgrind seems to decrease the performance of Apache server too much that > the client always report a timeout error. I am also not sure if I used the > correct command line option. I just type "Valgrind --tool=xxx ./httpd > start". I don't know what is wrong, so I ask for your help. The first thing to try is "--tool=none". What slowdown do you observe? A slowdown by a factor of 20 to 30 would not be unusual for "--tool=memcheck". If the Apache httpd server itself is the process which complains about timeout, then you can try dilating the allowed time, by modifying the source of either httpd or memcheck. For example, I did this with 'wine' some years ago: http://bugs.winehq.org/show_bug.cgi?id=14370 This code just multiplies the delay argument to setitimer() by the value of an environment variable. Sometimes this works. Or, you can find the valgrind subroutine PRE(sys_setitimer) and modify the delay value there. If the _client_ (and not the Apache httpd server) is the process that complains of timeout (because of slow service when Apache httpd is run under memcheck), then you must try to extend the timeout of the client. Which client is complaining? Is it 'firefox'? You might consider export LD_PRELOAD=/path/to/wrapper/for/setitimer.so where setitimer.so intercepts all calls to setitimer, multiplies the delay argument by 50, then calls the next setitimer in the global symbol table. See the documentation "man 3 dlsym" and look for RTLD_NEXT; also search for an example which "wraps" a system call using RTLD_NEXT. -- |
|
From: John R. <jr...@bi...> - 2012-06-07 04:33:48
|
Sometimes these crude techniques (not using valgrind) work well enough anyway. Typically the overhead is a few percent or less. 1) # http://udrepper.livejournal.com/11429.html export MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) echo 1>&2 MALLOC_PERTURB_=$MALLOC_PERTURB_ " # $HOME/.bash_profile" 2) export MALLOC_CHECK_=1 # 0: off; 1: announce on stderr; 2: abort echo 1>&2 MALLOC_CHECK_=$MALLOC_CHECK_ " # $HOME/.bash_profile" which handles double free(), single-byte overruns, etc. [Search the 'net for more documentation.] -- |
|
From: 周旭 <zho...@gm...> - 2012-06-09 07:43:14
|
Hi, Thanks for your help. I tried to run Valgrind with "--tool=none" option, but the problem remains. And I also found that the http server did not corrected start up under Valgrind. When I execute the command "valgrind --tool=none ./bin/httpd -k start", the server reports an error: "unhandled syscall: 330". Then the server keeps reporting a warning: "Warning: unhandled socketcall 0x12". Meanwhile, the daemon processes are missing(in the normal execution, there will be 5 daemon processes of httpd). So I think maybe it is the unhandled syscall or the unhandled socketcall that fails the starting up of http server, which in turn causes the timeout problem. Is that true and how to fix them? Thank you very much! --- zhouxu |
|
From: John R. <jr...@bi...> - 2012-06-09 14:05:21
|
> Thanks for your help. I tried to run Valgrind with "--tool=none" > option, but the problem remains. And I also found that the http server > did not corrected start up under Valgrind. > > When I execute the command "valgrind --tool=none ./bin/httpd -k > start", the server reports an error: "unhandled syscall: 330". Then > the server keeps reporting a warning: "Warning: unhandled socketcall > 0x12". Meanwhile, the daemon processes are missing(in the normal > execution, there will be 5 daemon processes of httpd). Please tell us complete details. The information "syscall: 330" is ambiguous, because system call numbers depend on the hardware and on the operating system. 1) Which version of valgrind are you running? Report the output from running "valgrind --version". 2) Which hardware and operating system (and version) are you using? If Linux, then report the output from running "uname -a". > So I think maybe it is the unhandled syscall or the unhandled > socketcall that fails the starting up of http server, which in turn > causes the timeout problem. Is that true and how to fix them? Unhandled syscall definitely is a problem. Telling us the complete details will make it much easier to suggest how to fix the problem(s). -- |
|
From: Manuel D. <ma...@de...> - 2012-06-10 22:26:05
|
On Sat, Jun 9, 2012 at 4:06 PM, John Reiser <jr...@bi...> wrote: > Please tell us complete details. The information "syscall: 330" > is ambiguous, because system call numbers depend on the hardware > and on the operating system. > > 1) Which version of valgrind are you running? > Report the output from running "valgrind --version". > > 2) Which hardware and operating system (and version) are you using? > If Linux, then report the output from running "uname -a". > >> So I think maybe it is the unhandled syscall or the unhandled >> socketcall that fails the starting up of http server, which in turn >> causes the timeout problem. Is that true and how to fix them? > > Unhandled syscall definitely is a problem. Telling us the complete > details will make it much easier to suggest how to fix the problem(s). Also, if not for the analysis then maybe for documentation for later reference, how are you starting apache httpd as a userland process ? I can't seem to do so. I am only able to control it via init.d start/stop scripts. I understand that you are able to run your web server normally, and that it works well, or even much faster, but how do you start it then ? Can you run the server by "./bin/httpd -k start" ? ~lImbus |
|
From: 周旭 <zho...@gm...> - 2012-06-11 03:35:01
|
> Please tell us complete details. The information "syscall: 330" > is ambiguous, because system call numbers depend on the hardware > and on the operating system. > > 1) Which version of valgrind are you running? > Report the output from running "valgrind --version". The version I use is valgrind-3.7.0.SVN. > 2) Which hardware and operating system (and version) are you using? > If Linux, then report the output from running "uname -a". The operation system is Fedora 12. The output of "uname -a" is the following: Linux localhost.localdomain 2.6.31.5-127.fc12.i686.PAE #1 SMP Sat Nov 7 21:25:57 EST >> So I think maybe it is the unhandled syscall or the unhandled >> socketcall that fails the starting up of http server, which in turn >> causes the timeout problem. Is that true and how to fix them? > > Unhandled syscall definitely is a problem. Telling us the complete > details will make it much easier to suggest how to fix the problem(s). The output of my command "sudo valgrind --tool=none ./bin/httpd -k start" in my platform is the following: [zhouxu@localhost httpd-prefork]$ sudo valgrind --tool=none ./bin/httpd -k start ==3777== Nulgrind, the minimal Valgrind tool ==3777== Copyright (C) 2002-2009, and GNU GPL'd, by Nicholas Nethercote. ==3777== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==3777== Command: ./bin/httpd -k start ==3777== httpd: Could not reliably determine the server's fully qualified domain name, using localhost.localdomain for ServerName --3777-- WARNING: unhandled syscall: 330 --3777-- You may be able to write your own handler. --3777-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --3777-- Nevertheless we consider this a bug. Please report --3777-- it at http://valgrind.org/support/bug_reports.html. ==3777== [zhouxu@localhost httpd-prefork]$ --3777-- WARNING: unhandled syscall: 330 --3777-- You may be able to write your own handler. --3777-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --3777-- Nevertheless we consider this a bug. Please report --3777-- it at http://valgrind.org/support/bug_reports.html. --3777-- Warning: unhandled socketcall 0x12 --3777-- Warning: unhandled socketcall 0x12 --3777-- Warning: unhandled socketcall 0x12 --3777-- Warning: unhandled socketcall 0x12 Thanks for your patient. --- zhouxu |
|
From: John R. <jr...@bi...> - 2012-06-11 04:48:26
|
> The version I use is valgrind-3.7.0.SVN.
> The operation system is Fedora 12. The output of "uname -a" is the following:
> Linux localhost.localdomain 2.6.31.5-127.fc12.i686.PAE #1 SMP Sat Nov
> 7 21:25:57 EST
Thank you for supplying those details. On Fedora 12 i686, syscall 330 is dup3:
----- /usr/include/asm/unistd.h ==> unistd_32.h:
#define __NR_dup3 330
So running valgrind on the following complete program should give the same error
as running valgrind on your httpd:
----- dup3.c
#include <unistd.h>
int main()
{
return dup3(0, 5, 0);
}
-----
[This follows the general debugging principle of trying to reproduce
the error using a test program that is a short and simple as possible.]
However it works for me on Fedora 14 with valgrind-3.8.0.SVN; see below.
Does it work for you on Fedora 12 with valgrind-3.7.0.SVN ?
-----
$ gcc -m32 -g -o ./dup3 dup3.c
$ valgrind --tool=none ./dup3
==10750== Nulgrind, the minimal Valgrind tool
==10750== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote.
==10750== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==10750== Command: .../dup3
==10750==
==10750==
$
-----
Please try the valgrind option "--trace-syscalls=yes", which prints out
system calls onto stderr as it executes:
valgrind --tool=none --trace-syscalls=yes ./bin/httpd -k start
What are the last few syscalls printed by the above command?
Using the dup3 program, I see:
----- valgrind --tool=none --trace-syscalls=yes ./dup3
[snip]
SYSCALL[10752,1](243) sys_set_thread_area ( 0xfea750a0 ) --> [pre-success] Success(0x0:0x0)
SYSCALL[10752,1](125) sys_mprotect ( 0x4c1ca000, 8192, 1 )[sync] --> Success(0x0:0x0)
SYSCALL[10752,1](125) sys_mprotect ( 0x4c042000, 4096, 1 )[sync] --> Success(0x0:0x0)
SYSCALL[10752,1]( 91) sys_munmap ( 0x400d000, 101301 )[sync] --> Success(0x0:0x0)
SYSCALL[10752,1](330) sys_dup3 ( 0, 5, 0 )[sync] --> Success(0x0:0x5)
SYSCALL[10752,1](252) exit_group( 5 ) --> [pre-success] Success(0x0:0x0)
==10752==
$
-----
For independent confirmation that syscall 330 is dup3, you can use strace:
strace -o strace.out valgrind --trace-syscalls=yes ./dup3
Then look in file strace.out, and compare the sequence of system calls
with what valgrind reports on stderr.
--
|
|
From: John R. <jr...@bi...> - 2012-06-11 16:00:00
|
> So running valgrind on the following complete program should give the same error
> as running valgrind on your httpd:
> ----- dup3.c
> #include <unistd.h>
>
> int main()
> {
> return dup3(0, 5, 0);
> }
> -----
> [This follows the general debugging principle of trying to reproduce
> the error using a test program that is a short and simple as possible.]
>
> However it works for me on Fedora 14 with valgrind-3.8.0.SVN; see below.
> Does it work for you on Fedora 12 with valgrind-3.7.0.SVN ?
valgrinding ./dup3 also works for me on Fedora 12 i686 using valgrind-3.5.0-14
which was installed from .rpm via "yum install valgrind" [yes, even today
from a Fedora mirror.]
--
|
|
From: 周旭 <zho...@gm...> - 2012-06-13 13:27:46
|
Hi,
I think I found my problem. Both Valgrind-3.7.0-SVN and
Valgrind-3.6.0 works well for syscall 330 and the dup3 program on my
platform. It was Valgrind-3.5.0 which causes the problem. Here is the
story of this problem:
Valgrind-3.5.0 was distributed with Fedora12, so I installed the
software in /usr/bin when the Operating System was installed. Latter,
I installed the new version(3.7.0) in /usr/local/valgrind, I just add
the location to the user's $PATH envrionment so that I could find the
command easily. The problem is when I use the command "sudo valgrind
...", it switch the current user to the root, and the environment
variables change. So each time when I typed "valgrind --version",
which prints "valgrind-3.7.0", I thought I was using the new version.
However, when I add "sudo" in the front, I switched to the old version
again.
Thanks for your help.
2012/6/12 John Reiser <jr...@bi...>:
>> So running valgrind on the following complete program should give the same error
>> as running valgrind on your httpd:
>> ----- dup3.c
>> #include <unistd.h>
>>
>> int main()
>> {
>> return dup3(0, 5, 0);
>> }
>> -----
>> [This follows the general debugging principle of trying to reproduce
>> the error using a test program that is a short and simple as possible.]
>>
>> However it works for me on Fedora 14 with valgrind-3.8.0.SVN; see below.
>> Does it work for you on Fedora 12 with valgrind-3.7.0.SVN ?
>
> valgrinding ./dup3 also works for me on Fedora 12 i686 using valgrind-3.5.0-14
> which was installed from .rpm via "yum install valgrind" [yes, even today
> from a Fedora mirror.]
>
> --
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|