- Dillo-dev - lists.mailman3.com

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

EAGAIN loop in IO_read

by jcid＠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.-

Nov. 9, 2009

EAGAIN loop in IO_read

by furaisanjin＠gmail.com

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. Regards, furaisanjin

Nov. 9, 2009

Big changes in DPI framework and API

by Johannes.Hofmann＠gmx.de

On Sun, Nov 08, 2009 at 10:15:43AM -0300, Jorge Arellano Cid wrote: > On Sat, Nov 07, 2009 at 07:23:43PM +0100, Johannes Hofmann wrote: > > On Sun, Nov 01, 2009 at 06:24:18PM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > Today the big work on DPI/DPIP was committed! > > > > > > The new framework and API is easier to use and more powerful. > > > Lots of bugs and constraints were removed in the process. It was > > > a lot of work but now is easier to fix and implement new things. > > > After all the DPI framework was growing as new needs arose and it > > > needed a rewrite since long ago. > > > > > > There're still pending patches and docs. Details are in the > > > Changelog and Mercurial repo (hg log -v|less). > > > > > > One of them is the new select() based file dpi. It should be > > > faster and use less resources (all happens in a single process > > > now). > > > > > > Note: currently the code uses Internet Domain sockets instead > > > of Unix domain sockets. This was initially meant for MINIX, but > > > in the process several bugs were fixed, the code restructured, > > > added more error handling and improved in general. In the future > > > we may go back to UDS, but the cleanup gains will remain. > > > > > > Please test and enjoy. > > > > For now I can just confirm that it works nice on DragonFly :-) > > Excellent. > > > Do you think it would be a good time now, to look into the view > > source dpi thing again? > > The buffer size constraint and atomicity transfer hope (left to > the OS) were removed. DPIP implementation handles it internally > now. > > I was planning to work on the view source dpi a bit and at > least advance it until the dpi gets the whole file so you can > do the funny part. I can't but feel a bit guilty by the work you > have put on it only to discover the framework was not up to the > task. The DPIP framework grew by extending it to each new dpi > needs, and there were constraints. This rewrite was necessary to > make it more reliable in the concept, and not ad-hoc to the task. No problem at all. I'm glad if things get simpler. > > BTW, I still have to turn https into a server dpi to remove the > dialog-storm bug, and to give a look into the cookies dpi to make > it distinguish among different instances of dillo. View source is > the first on the list, so if I were you I'd keep working on the > scrolling patch and wait until Jorge commits. :) Or at your own > choice let him finish the whole view source thing! I have updated the scrolling patch, but came to the conclusion, that it is not a good idea - at least not in the way I did it originally: I have made the scrollbars part of the UI and ripped out the code that deals with scrollbar widths in layout.cc. But then I thought about frames, and there we potentially need scrollbars for every frame. So for now will leave things as they are and focus on fixing real bugs. Cheers, Johannes

Nov. 8, 2009

Big changes in DPI framework and API

by jcid＠dillo.org

On Sat, Nov 07, 2009 at 07:23:43PM +0100, Johannes Hofmann wrote: > On Sun, Nov 01, 2009 at 06:24:18PM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > Today the big work on DPI/DPIP was committed! > > > > The new framework and API is easier to use and more powerful. > > Lots of bugs and constraints were removed in the process. It was > > a lot of work but now is easier to fix and implement new things. > > After all the DPI framework was growing as new needs arose and it > > needed a rewrite since long ago. > > > > There're still pending patches and docs. Details are in the > > Changelog and Mercurial repo (hg log -v|less). > > > > One of them is the new select() based file dpi. It should be > > faster and use less resources (all happens in a single process > > now). > > > > Note: currently the code uses Internet Domain sockets instead > > of Unix domain sockets. This was initially meant for MINIX, but > > in the process several bugs were fixed, the code restructured, > > added more error handling and improved in general. In the future > > we may go back to UDS, but the cleanup gains will remain. > > > > Please test and enjoy. > > For now I can just confirm that it works nice on DragonFly :-) Excellent. > Do you think it would be a good time now, to look into the view > source dpi thing again? The buffer size constraint and atomicity transfer hope (left to the OS) were removed. DPIP implementation handles it internally now. I was planning to work on the view source dpi a bit and at least advance it until the dpi gets the whole file so you can do the funny part. I can't but feel a bit guilty by the work you have put on it only to discover the framework was not up to the task. The DPIP framework grew by extending it to each new dpi needs, and there were constraints. This rewrite was necessary to make it more reliable in the concept, and not ad-hoc to the task. BTW, I still have to turn https into a server dpi to remove the dialog-storm bug, and to give a look into the cookies dpi to make it distinguish among different instances of dillo. View source is the first on the list, so if I were you I'd keep working on the scrolling patch and wait until Jorge commits. :) Or at your own choice let him finish the whole view source thing! -- Cheers Jorge.-

Nov. 8, 2009