- Dillo-dev - lists.mailman3.com

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 08:27:23PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > > the problem happens. There isn't any specific page either. > > > > > > > > The point is we have massive changes in the DPI area, not in > > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > > equation. If it happens with HTTPS, DPI participates. > > > > > > > > I'd expect you not being able to trigger the bug by using the > > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > > going to the bookmark page and then keep Ctrl-r pressed so that it > > > reloads continiously. After a while I get a segmentation fault, but > > > no proper stack unfortunately. > > > > Was the crash possible before the DPI changes? > > One more thing. There is a file descriptor leak you can see with > > diff -r 8535113920b1 src/IO/dpi.c > --- a/src/IO/dpi.cgiMon Nov 09 14:22:27 2009 -0300 > +++ b/src/IO/dpi.cgiMon Nov 09 20:25:34 2009 +0100 > @@ -90,7 +90,7 @@ > static void Dpi_close_fd(int fd) > { > int st; > - > +fprintf(stderr, "===> close %d\n", fd); > dReturn_if (fd < 0); > do > st = close(fd); > @@ -432,6 +432,7 @@ > if ((fd = socket(AF_INET, SOCK_STREAM, 0)) != -1) { > ret = fd; > } > +fprintf(stderr, "===> socket %d\n", fd); > return ret; > } > > > Each time one accesses the bookmarks page one fd is leaked. I think > there is also some close()'s missing in the error cases. No FD leak here, the respective FD is closed by IO, although there were a couple of FD leaks elsewhere (fixed in repo). BTW, in the process I learnt this trick (GNU/Linux): ls -l /proc/`pgrep dillo`/fd -- Cheers Jorge.-

Nov. 10, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 08:00:43PM +0100, Johannes Hofmann wrote: > > PS: While looking at the code I found that Dpi_make_socket_fd() > could be simplified to just: > > return socket(AF_INET, SOCK_STREAM, 0); Yes, it was coded that way to set socket options from a single function easily. When those proved unnecessary, the skeleton was left just in case. -- Cheers Jorge.-

Nov. 10, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > I dont't know any trigger yet. I just browse pages and occasionally > > > the problem happens. There isn't any specific page either. > > > > The point is we have massive changes in the DPI area, not in > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > equation. If it happens with HTTPS, DPI participates. > > > > I'd expect you not being able to trigger the bug by using the > > file dpi, but if you can with plain HTTP it's a surprise. > > Not 100% sure if it is the same issue, but I can crash dillo by > going to the bookmark page and then keep Ctrl-r pressed so that it > reloads continiously. After a while I get a segmentation fault, but > no proper stack unfortunately. Yes, a FD leak was responsible. -- Cheers Jorge.-

Nov. 10, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > I dont't know any trigger yet. I just browse pages and occasionally > > > the problem happens. There isn't any specific page either. > > > > The point is we have massive changes in the DPI area, not in > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > equation. If it happens with HTTPS, DPI participates. > > > > I'd expect you not being able to trigger the bug by using the > > file dpi, but if you can with plain HTTP it's a surprise. > > Not 100% sure if it is the same issue, but I can crash dillo by > going to the bookmark page and then keep Ctrl-r pressed so that it > reloads continiously. After a while I get a segmentation fault, but > no proper stack unfortunately. OK, I found the bug! Patch commit soon... -- Cheers Jorge.-

Nov. 10, 2009

EAGAIN loop in IO_read

by Johannes.Hofmann＠gmx.de

On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > the problem happens. There isn't any specific page either. > > > > > > The point is we have massive changes in the DPI area, not in > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > equation. If it happens with HTTPS, DPI participates. > > > > > > I'd expect you not being able to trigger the bug by using the > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > going to the bookmark page and then keep Ctrl-r pressed so that it > > reloads continiously. After a while I get a segmentation fault, but > > no proper stack unfortunately. > > Was the crash possible before the DPI changes? One more thing. There is a file descriptor leak you can see with diff -r 8535113920b1 src/IO/dpi.c --- a/src/IO/dpi.cgiMon Nov 09 14:22:27 2009 -0300 +++ b/src/IO/dpi.cgiMon Nov 09 20:25:34 2009 +0100 @@ -90,7 +90,7 @@ static void Dpi_close_fd(int fd) { int st; - +fprintf(stderr, "===> close %d\n", fd); dReturn_if (fd < 0); do st = close(fd); @@ -432,6 +432,7 @@ if ((fd = socket(AF_INET, SOCK_STREAM, 0)) != -1) { ret = fd; } +fprintf(stderr, "===> socket %d\n", fd); return ret; } Each time one accesses the bookmarks page one fd is leaked. I think there is also some close()'s missing in the error cases. Cheers, Johannes

Nov. 9, 2009

EAGAIN loop in IO_read

by Johannes.Hofmann＠gmx.de

On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > the problem happens. There isn't any specific page either. > > > > > > The point is we have massive changes in the DPI area, not in > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > equation. If it happens with HTTPS, DPI participates. > > > > > > I'd expect you not being able to trigger the bug by using the > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > going to the bookmark page and then keep Ctrl-r pressed so that it > > reloads continiously. After a while I get a segmentation fault, but > > no proper stack unfortunately. > > Was the crash possible before the DPI changes? No. BTW. I can now reproduce it on Linux under valgrind. Things seem to be ok for a while until suddenly: [bookmarks dpi]: (v.13): accepting connections... [bookmarks dpi]: (v.13): accepting connections... ==21677== Warning: invalid file descriptor 1019 in syscall socket() ==21677== Warning: invalid file descriptor 1019 in syscall pipe() ==21677== Invalid read of size 4 ==21677== at 0x8059D48: a_Url_str (url.c:71) ==21677== by 0x8059F22: a_Url_dup (url.c:425) ==21677== by 0x80552D7: a_Bw_add_url (bw.c:210) ==21677== by 0x805B9E0: Nav_open_url (nav.c:240) ==21677== by 0x8050AB4: UI::handle(int) (ui.cc:803) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80DEF20: fltk::TabGroup::handle(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x8054C48: CustTabGroup::handle(int) (uicmd.cc:315) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80BBAFC: fltk::Group::handle(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80F26A3: fltk::Window::handle(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) ==21677== Address 0x447a4d0 is 0 bytes inside a block of size 60 free'd ==21677== at 0x4022B8A: free (vg_replace_malloc.c:323) ==21677== by 0x805B6B2: a_Nav_cancel_expect (nav.c:252) ==21677== by 0x805F91D: a_Capi_ccc (capi.c:610) ==21677== by 0x805A352: a_Chain_fcb (chain.c:113) ==21677== by 0x8081B11: a_Dpi_ccc (dpi.c:713) ==21677== by 0x8081A3A: a_Dpi_ccc (dpi.c:689) ==21677== by 0x805A3D2: a_Chain_bcb (chain.c:136) ==21677== by 0x806012B: a_Capi_dpi_send_cmd (capi.c:493) ==21677== by 0x8060AB9: a_Capi_open_url (capi.c:365) ==21677== by 0x805B9B9: Nav_open_url (nav.c:238) ==21677== by 0x8050AB4: UI::handle(int) (ui.cc:803) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) and so on. Cheers, Johannes PS: While looking at the code I found that Dpi_make_socket_fd() could be simplified to just: return socket(AF_INET, SOCK_STREAM, 0);

Nov. 9, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > I dont't know any trigger yet. I just browse pages and occasionally > > > the problem happens. There isn't any specific page either. > > > > The point is we have massive changes in the DPI area, not in > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > equation. If it happens with HTTPS, DPI participates. > > > > I'd expect you not being able to trigger the bug by using the > > file dpi, but if you can with plain HTTP it's a surprise. > > Not 100% sure if it is the same issue, but I can crash dillo by > going to the bookmark page and then keep Ctrl-r pressed so that it > reloads continiously. After a while I get a segmentation fault, but > no proper stack unfortunately. Was the crash possible before the DPI changes? -- Cheers Jorge.-

Nov. 9, 2009

EAGAIN loop in IO_read

by Johannes.Hofmann＠gmx.de

On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > I dont't know any trigger yet. I just browse pages and occasionally > > the problem happens. There isn't any specific page either. > > The point is we have massive changes in the DPI area, not in > dillo. If you trigger it while browsing HTTP, DPI is out of the > equation. If it happens with HTTPS, DPI participates. > > I'd expect you not being able to trigger the bug by using the > file dpi, but if you can with plain HTTP it's a surprise. Not 100% sure if it is the same issue, but I can crash dillo by going to the bookmark page and then keep Ctrl-r pressed so that it reloads continiously. After a while I get a segmentation fault, but no proper stack unfortunately. Cheers, Johannes

Nov. 9, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > I dont't know any trigger yet. I just browse pages and occasionally > the problem happens. There isn't any specific page either. The point is we have massive changes in the DPI area, not in dillo. If you trigger it while browsing HTTP, DPI is out of the equation. If it happens with HTTPS, DPI participates. I'd expect you not being able to trigger the bug by using the file dpi, but if you can with plain HTTP it's a surprise. -- Cheers Jorge.-

Nov. 9, 2009

EAGAIN loop in IO_read

by furaisanjin＠gmail.com

I dont't know any trigger yet. I just browse pages and occasionally the problem happens. There isn't any specific page either. Regards, furaisanjin 2009/11/9, Jorge Arellano Cid <jcid(a)dillo.org>: > On Mon, Nov 09, 2009 at 07:59:20AM +0900, furaisanjin wrote: >> Hi all. >> >> This might be FreeBSD specific issue but I have EAGAIN loop in >> IO_read. I don't know anything yet why this happens but at some point >> read function keeps returning EAGAIN in IO_read and nothing is read. >> Do you have any idea how to investigate this further? I think this >> happens after DPI big change. > > How do you trigger the problem? > > It's possible that something weird is happening. Linux behavior > differs from BSD socket implementations. If you isolate a way to > reproduce the bug, we may ask other *BSD users to test, and I'd > have a hint of the code path. > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Nov. 9, 2009