Am wondering whether relates to IOV_MAX being quite low on Solaris (16). I perhaps was assuming the APR would deal with any limit and break it up into separate calls as generally APR is good at papering over OS differences. Checking apr_socket_sendv() code doesn't seem it does though. :-(
IOV_MAX is the maximum number of iovec array elements there can be passed into writev. Graham On Tuesday, 24 March 2015 14:19:22 UTC+11, Graham Dumpleton wrote: > > > > On Tuesday, 24 March 2015 14:08:25 UTC+11, jcea wrote: >> >> On 23/03/15 02:13, Graham Dumpleton wrote: >> > My memory is that truss allows you to specify certain system >> > functions which you want verbose display of arguments and return >> > value. >> > >> > From memory: >> > >> > -v writev >> > >> > Can you see if you can get extra information that way about the >> > arguments? >> >> [root@babylon5 /]# truss -t writev -v writev -p 29939 29940 >> >> """ >> /12: writev(10, 0x08146010, 76) Err#22 EINVAL >> /12: iov_base = 0xFE155AB8 iov_len = 4 >> /12: iov_base = 0xFE155ABC iov_len = 4 >> /12: iov_base = 0x080B3A7B iov_len = 18 >> /12: iov_base = 0x080B3A73 iov_len = 8 >> /12: iov_base = 0x080B3A8D iov_len = 16 >> /12: iov_base = 0x08144F28 iov_len = 9 >> /12: iov_base = 0x080B3A9D iov_len = 15 >> /12: iov_base = 0x08144F08 iov_len = 4 >> /12: iov_base = 0x080B3A4B iov_len = 13 >> /12: iov_base = 0x080B2628 iov_len = 1 >> /12: iov_base = 0x080B3AAC iov_len = 12 >> /12: iov_base = 0x081455C0 iov_len = 2 >> /12: iov_base = 0x080B3AB8 iov_len = 12 >> /12: iov_base = 0x081459C0 iov_len = 2 >> /12: iov_base = 0x080B3944 iov_len = 5 >> /12: iov_base = 0x08145810 iov_len = 226 >> /12: writev(9, 0xFE155E30, 2) = 750 >> /12: iov_base = 0x08148028 iov_len = 219 >> /12: iov_base = 0x08142010 iov_len = 531 >> """ >> >> Are those two first values, in the "0xFExxxxxx" range, normal?. >> > > They are integers giving a length and location is on the stack, so likely > okay. > > vec[1].iov_base = (void*)&count; > vec[1].iov_len = sizeof(count); > > total += vec[1].iov_len; > > vec[0].iov_base = (void*)&total; > vec[0].iov_len = sizeof(total); > > rv = wsgi_socket_sendv(daemon->socket, vec, (int)(vec_next-vec)); > > There shouldn't be a restriction on using stack memory. > > Thanks for the details. Will think over what this tells me. > > >> The content of those memory areas looks weird. With GDB: >> >> """ >> (gdb) x/1xw 0xFE155AB8 >> 0xfe155ab8: 0xfe155ad8 >> (gdb) x/1xw 0xFE155ABC >> 0xfe155abc: 0xfed7720b >> """ >> >> The rest of the IOVEC looks good, with content like: >> >> "GATEWAY_INTERFACE" >> "CGI/1.1" >> >> >> >> -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
