November 2009 - Dillo-dev - lists.mailman3.com

weird font

by jcid＠dillo.org

Hi, On some sites I get weird fonts. Today I got to isolate the problem. See attached file. Here it displays like this: http://www.dillo.org/test/xmp2.png The embedded CSS says: pre { font-family: MS Courier New, Courier, monospace; } If I remove "MS Courier New", it works OK. Any clues? -- Cheers Jorge.-

Nov. 10, 2009

EAGAIN loop in IO_read

by Johannes.Hofmann＠gmx.de

On Tue, Nov 10, 2009 at 05:51:08PM -0300, Jorge Arellano Cid wrote: > 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). Yes, problem is gone, nice! Cheers, Johannes

Nov. 10, 2009

EAGAIN loop in IO_read

by Johannes.Hofmann＠gmx.de

On Tue, Nov 10, 2009 at 05:48:12PM -0300, Jorge Arellano Cid wrote: > 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. Understood, but I thought the body of the function could be simplified like this: static int Dpi_make_socket_fd() { return socket(AF_INET, SOCK_STREAM, 0); } Cheers, Johannes

Nov. 10, 2009

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