Hi.
I’m trying to add support for the nginx range filter in mod_wsgi but I
have found some problems.
When I try to resume a file download (using wget) I get a:
2007/12/11 22:07:55 [crit] 26054#0: *2 writev() failed (14: Bad
address), client: 127.0.0.1, server: localhost
It seems that there is a problem in mod_wsgi, but I have tested the
range filter using a standard (0.5.30, Debian Lenny) nginx server and I
have found that nginx returns a ‘\n’ as first character.
So, this seems to be a bug in Nginx.
I have used a text file containing:
abcdef
and resumed a file containing
a
obtaining:
a\nbcdef
Manlio P.
Hello!
On Tue, 11 Dec 2007, Manlio P. wrote:
a\nbcdef
Just checked this with 0.6.21 and 0.5.30 - everything is OK, wget & curl
have no problems, and nginx response looks perfectly valid:
23:19:33.084718 IP 127.0.0.1.8080 > 127.0.0.1.63650: P 1:240(239) ack
128
win 35840 <nop,nop,timestamp 6002274 6002274>
0x0000: 4500 0123 f3c8 4000 4006 480a 7f00 0001
E…#…@[email protected]…
0x0010: 7f00 0001 1f90 f8a2 595f c3c1 22ae 27ad
…Y_…".’.
0x0020: 8018 8c00 274f 0000 0101 080a 005b 9662
…'O…[.b
0x0030: 005b 9662 4854 5450 2f31 2e31 2032 3036
.[.bHTTP/1.1.206
0x0040: 2050 6172 7469 616c 2043 6f6e 7465 6e74
.Partial.Content
0x0050: 0d0a 5365 7276 6572 3a20 6e67 696e 782f
…Server:.nginx/
0x0060: 302e 352e 3330 0d0a 4461 7465 3a20 5475
0.5.30…Date:.Tu
0x0070: 652c 2031 3120 4465 6320 3230 3037 2032
e,.11.Dec.2007.2
0x0080: 303a 3139 3a33 3320 474d 540d 0a43 6f6e
0:19:33.GMT…Con
0x0090: 7465 6e74 2d54 7970 653a 2074 6578 742f
tent-Type:.text/
0x00a0: 706c 6169 6e0d 0a43 6f6e 7465 6e74 2d4c
plain…Content-L
0x00b0: 656e 6774 683a 2035 0d0a 4c61 7374 2d4d
ength:.5…Last-M
0x00c0: 6f64 6966 6965 643a 2054 7565 2c20 3131
odified:.Tue,.11
0x00d0: 2044 6563 2032 3030 3720 3230 3a30 353a
.Dec.2007.20:05:
0x00e0: 3238 2047 4d54 0d0a 436f 6e6e 6563 7469
28.GMT…Connecti
0x00f0: 6f6e 3a20 6b65 6570 2d61 6c69 7665 0d0a
on:.keep-alive…
0x0100: 436f 6e74 656e 742d 5261 6e67 653a 2062
Content-Range:.b
0x0110: 7974 6573 2031 2d35 2f36 0d0a 0d0a 6263
ytes.1-5/6…bc
0x0120: 6465 66 def
If you are sure you didn’t do something really stupid like forgetting -n
option to echo while constructing file to be resumed - could you please
provide some more info?
Maxim D.
Maxim D. ha scritto:
option to echo while constructing file to be resumed - could you please
provide some more info?
Ok, it was my fault.
The editor adds a newline at the end of the file so the resumed file
was:
a\ncdef
instead of
abcdef
Now I have to found the problem in mod_wsgi…
Maxim D.
Manlio P.
On Wed, Dec 12, 2007 at 02:22:50PM +0100, Manlio P. wrote:
Now I have to found the problem in mod_wsgi…
Ok, problem solved: I didn’t set buf->start in a memory buffer…
Strange that on Linux I get a 14: Bad address instead of a segmentation
fault.
Segmentation fault of kernel ? 
It seems that your module and nginx did not touch this memory, so the
value
was passed to kernel and it saw its invalidity.
Manlio P. ha scritto:
Ok, problem solved: I didn’t set buf->start in a memory buffer…
Strange that on Linux I get a 14: Bad address instead of a segmentation
fault.
Sorry for the noise
Manlio P.
Igor S. ha scritto:
[…]
Now I have to found the problem in mod_wsgi…
Ok, problem solved: I didn’t set buf->start in a memory buffer…
Strange that on Linux I get a 14: Bad address instead of a segmentation
fault.
Segmentation fault of kernel ? 
No, a SIGSEG signal!
It seems that your module and nginx did not touch this memory, so the value
was passed to kernel and it saw its invalidity.
Right, but why returning EFAULT instead of raising a SIGSEG?
Moreover:
Macro: int EFAULT
Bad address; an invalid pointer was detected. In the GNU system,
this error never happens; you get a signal instead.
But certainly I’m missing something ;-).
Thanks Manlio P.
On Wed, Dec 12, 2007 at 03:12:29PM +0100, Manlio P. wrote:
I have found some problems.
Macro: int EFAULT
Bad address; an invalid pointer was detected. In the GNU system,
this error never happens; you get a signal instead.
But certainly I’m missing something ;-).
I never saw SIGSEG in this case on FreeBSD.
Igor S. ha scritto:
[…]
It seems that your module and nginx did not touch this memory, so the value
was passed to kernel and it saw its invalidity.
The problem was with these lines of code in the range filter:
if (ngx_buf_in_memory(buf)) {
buf->pos = buf->start + (size_t) range->start;
buf->last = buf->start + (size_t) range->end;
}
In mod_wsgi I forgot to set buf->start (and buf->end, too), so its value
is 0 :-).
But certainly I’m missing something ;-).
I never saw SIGSEG in this case on FreeBSD.
Its strange that, within glibc-2.0.1 sources I get
$grep -rw EFAULT .
./sysdeps/mach/hurd/errnos.h: EFAULT = _HURD_ERRNO (14),
./sysdeps/mach/hurd/errnos.h:#define EFAULT HURD_ERRNO
(14)/* Bad address */
./sysdeps/gnu/errlist.c:#ifdef EFAULT
./sysdeps/gnu/errlist.c: [EFAULT] = N(“Bad address”),
./sysdeps/unix/bsd/bsd4.4/errnos.h:#define EFAULT 14
/* Bad address */
So it seems that the gnu libc does not define EFAULT for Linux.
But I’m not sure of what “GNU system” means.
Regards Manlio P.