Le 19/12/2017 à 02:00, Warren Young a écrit :
On Dec 18, 2017, at 6:52 AM, Olivier R. <[email protected]> wrote:
When gdb was active, Fossil didn’t answer when asking for a
webpage. It seemed blocked.
That’s exactly what happens. If you want the process to run while
GDB remains attached, say “cont” after attaching.
Here is what gdb said:
Did it say the same thing if you reattached each time?
New try:
(gdb) bt
#0 0x00007fd8ff85e873 in __select_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1 0x0000000000416162 in cgi_http_server (mnPort=mnPort@entry=8080,
mxPort=mxPort@entry=8180,
zBrowser=<optimized out>, zBrowser@entry=0x0,
zIpAddr=zIpAddr@entry=0x0, flags=flags@entry=12)
at ./src/cgi.c:1845
#2 0x000000000044f92a in cmd_webserver () at ./src/main.c:2493
#3 0x0000000000407fec in main (argc=<optimized out>, argv=<optimized
out>) at ./src/main.c:760
New try (after performing some actions):
(gdb) bt
#0 0x00007fd8ff85e873 in __select_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1 0x0000000000416162 in cgi_http_server (mnPort=mnPort@entry=8080,
mxPort=mxPort@entry=8180,
zBrowser=<optimized out>, zBrowser@entry=0x0,
zIpAddr=zIpAddr@entry=0x0, flags=flags@entry=12)
at ./src/cgi.c:1845
#2 0x000000000044f92a in cmd_webserver () at ./src/main.c:2493
#3 0x0000000000407fec in main (argc=<optimized out>, argv=<optimized
out>) at ./src/main.c:760
I also launched gdb on different subprocesses:
(gdb) bt
#0 0x00007fd8ff858ba0 in __read_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1 0x00007fd8ff7f23a0 in _IO_new_file_underflow (fp=0x7fd8ffb234e0
<_IO_2_1_stdin_>) at fileops.c:605
#2 0x00007fd8ff7f31ce in __GI__IO_default_uflow (fp=0x7fd8ffb234e0
<_IO_2_1_stdin_>) at genops.c:435
#3 0x00007fd8ff7e7f84 in __GI__IO_getline_info
(fp=fp@entry=0x7fd8ffb234e0 <_IO_2_1_stdin_>,
buf=buf@entry=0x7ffd56077bf0 "GET", n=n@entry=1999,
delim=delim@entry=10, extract_delim=extract_delim@entry=1,
eof=eof@entry=0x0) at iogetline.c:69
#4 0x00007fd8ff7e8078 in __GI__IO_getline (fp=fp@entry=0x7fd8ffb234e0
<_IO_2_1_stdin_>,
buf=buf@entry=0x7ffd56077bf0 "GET", n=n@entry=1999,
delim=delim@entry=10, extract_delim=extract_delim@entry=1)
at iogetline.c:38
#5 0x00007fd8ff7e6e96 in _IO_fgets (buf=buf@entry=0x7ffd56077bf0 "GET",
n=n@entry=2000,
fp=0x7fd8ffb234e0 <_IO_2_1_stdin_>) at iofgets.c:56
#6 0x000000000041727e in cgi_handle_http_request (zIpAddr=<optimized
out>, zIpAddr@entry=0x0) at ./src/cgi.c:1414
#7 0x000000000044f9c1 in cmd_webserver () at ./src/main.c:2511
#8 0x0000000000407fec in main (argc=<optimized out>, argv=<optimized
out>) at ./src/main.c:760
(gdb) bt
#0 0x00007fd8ff858ba0 in __read_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1 0x00007fd8ff7f23a0 in _IO_new_file_underflow (fp=0x7fd8ffb234e0
<_IO_2_1_stdin_>) at fileops.c:605
#2 0x00007fd8ff7f31ce in __GI__IO_default_uflow (fp=0x7fd8ffb234e0
<_IO_2_1_stdin_>) at genops.c:435
#3 0x00007fd8ff7e7f84 in __GI__IO_getline_info
(fp=fp@entry=0x7fd8ffb234e0 <_IO_2_1_stdin_>,
buf=buf@entry=0x7ffd56077bf0 "ut", n=n@entry=1999,
delim=delim@entry=10, extract_delim=extract_delim@entry=1,
eof=eof@entry=0x0) at iogetline.c:69
#4 0x00007fd8ff7e8078 in __GI__IO_getline (fp=fp@entry=0x7fd8ffb234e0
<_IO_2_1_stdin_>,
buf=buf@entry=0x7ffd56077bf0 "ut", n=n@entry=1999,
delim=delim@entry=10, extract_delim=extract_delim@entry=1)
at iogetline.c:38
#5 0x00007fd8ff7e6e96 in _IO_fgets (buf=buf@entry=0x7ffd56077bf0 "ut",
n=n@entry=2000,
fp=0x7fd8ffb234e0 <_IO_2_1_stdin_>) at iofgets.c:56
#6 0x0000000000417118 in cgi_handle_http_request
(zIpAddr=zIpAddr@entry=0x0) at ./src/cgi.c:1376
#7 0x000000000044f9c1 in cmd_webserver () at ./src/main.c:2511
#8 0x0000000000407fec in main (argc=<optimized out>, argv=<optimized
out>) at ./src/main.c:760
(gdb) bt
#0 0x00007fd8ff858ba0 in __read_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1 0x00007fd8ff7f23a0 in _IO_new_file_underflow (fp=0x7fd8ffb234e0
<_IO_2_1_stdin_>) at fileops.c:605
#2 0x00007fd8ff7f31ce in __GI__IO_default_uflow (fp=0x7fd8ffb234e0
<_IO_2_1_stdin_>) at genops.c:435
#3 0x00007fd8ff7e7f84 in __GI__IO_getline_info
(fp=fp@entry=0x7fd8ffb234e0 <_IO_2_1_stdin_>,
buf=buf@entry=0x7ffd56077bf0 "ut", n=n@entry=1999,
delim=delim@entry=10, extract_delim=extract_delim@entry=1,
eof=eof@entry=0x0) at iogetline.c:69
#4 0x00007fd8ff7e8078 in __GI__IO_getline (fp=fp@entry=0x7fd8ffb234e0
<_IO_2_1_stdin_>,
buf=buf@entry=0x7ffd56077bf0 "ut", n=n@entry=1999,
delim=delim@entry=10, extract_delim=extract_delim@entry=1)
at iogetline.c:38
#5 0x00007fd8ff7e6e96 in _IO_fgets (buf=buf@entry=0x7ffd56077bf0 "ut",
n=n@entry=2000,
fp=0x7fd8ffb234e0 <_IO_2_1_stdin_>) at iofgets.c:56
#6 0x0000000000417118 in cgi_handle_http_request
(zIpAddr=zIpAddr@entry=0x0) at ./src/cgi.c:1376
#7 0x000000000044f9c1 in cmd_webserver () at ./src/main.c:2511
#8 0x0000000000407fec in main (argc=<optimized out>, argv=<optimized
out>) at ./src/main.c:760
(gdb) bt
#0 0x00007fd8ff858ba0 in __read_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1 0x00007fd8ff7f23a0 in _IO_new_file_underflow (fp=0x7fd8ffb234e0
<_IO_2_1_stdin_>) at fileops.c:605
#2 0x00007fd8ff7f31ce in __GI__IO_default_uflow (fp=0x7fd8ffb234e0
<_IO_2_1_stdin_>) at genops.c:435
#3 0x00007fd8ff7e7f84 in __GI__IO_getline_info
(fp=fp@entry=0x7fd8ffb234e0 <_IO_2_1_stdin_>,
buf=buf@entry=0x7ffd56077bf0 "ut", n=n@entry=1999,
delim=delim@entry=10, extract_delim=extract_delim@entry=1,
eof=eof@entry=0x0) at iogetline.c:69
#4 0x00007fd8ff7e8078 in __GI__IO_getline (fp=fp@entry=0x7fd8ffb234e0
<_IO_2_1_stdin_>,
buf=buf@entry=0x7ffd56077bf0 "ut", n=n@entry=1999,
delim=delim@entry=10, extract_delim=extract_delim@entry=1)
at iogetline.c:38
#5 0x00007fd8ff7e6e96 in _IO_fgets (buf=buf@entry=0x7ffd56077bf0 "ut",
n=n@entry=2000,
fp=0x7fd8ffb234e0 <_IO_2_1_stdin_>) at iofgets.c:56
#6 0x0000000000417118 in cgi_handle_http_request
(zIpAddr=zIpAddr@entry=0x0) at ./src/cgi.c:1376
#7 0x000000000044f9c1 in cmd_webserver () at ./src/main.c:2511
#8 0x0000000000407fec in main (argc=<optimized out>, argv=<optimized
out>) at ./src/main.c:760
What does “fossil ver” say? I ask because line numbers are more
helpful if you also give the checkin ID they refer to.
This is fossil version 2.2 [81d7d3f43e] 2017-04-11 20:54:55 UTC
Assuming that new PIDs are higher than the previous ones, it is
interesting to notice that two of the subprocesses have a lower PID than
the main one.
It seems that only the main process (PID 17876) uses the CPU time.
top:
15143 myuser 20 0 14876 3448 2720 S 0.0 0.2 0:00.00 foss
15144 myuser 20 0 14876 3448 2720 S 0.0 0.2 0:00.00 foss
17876 myuser 20 0 14872 4248 3528 S 0.0 0.2 0:39.80 foss
20253 myuser 20 0 14876 3452 2724 S 0.0 0.2 0:00.00 foss
25581 myuser 20 0 14876 3448 2720 S 0.0 0.2 0:00.00 foss
25582 myuser 20 0 14876 3448 2720 S 0.0 0.2 0:00.00 foss
28558 myuser 20 0 14876 3448 2720 S 0.0 0.2 0:00.00 foss
28559 myuser 20 0 14876 3448 2720 S 0.0 0.2 0:00.00 foss
30076 myuser 20 0 14876 3448 2720 S 0.0 0.2 0:00.00 foss
30077 myuser 20 0 14876 3448 2720 S 0.0 0.2 0:00.00 foss
31100 myuser 20 0 14876 3452 2724 S 0.0 0.2 0:00.00 foss
Regards,
Olivier
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
