EAGAIN loop in IO_read
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
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.-
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@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@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
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.-
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
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.-
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);
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.-
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
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
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.-
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
Hi. My problem also seems to be fixed because it's very harder to reproduce the problem now. By the way, I'm a bit wondering this code and I suppose something like this. --- dillo/src/IO/dpi.c 2009-11-11 05:51:28.000000000 +0900 +++ dillo-test/src/IO/dpi.c 2009-11-11 22:05:42.000000000 +0900 @@ -793,12 +793,15 @@ char *a_Dpi_send_blocking_cmd(const char if ((sock_fd = Dpi_connect_socket(server_name, TRUE)) == -1) { MSG_ERR("[a_Dpi_send_blocking_cmd] Can't connect to server.\n"); - } else if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { - MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); - } if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { - MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); + } else { + if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { + MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); + } + if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { + MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); + } + Dpi_close_fd(sock_fd); } - Dpi_close_fd(sock_fd); return ret; } Regards, furaisanjin
On Thu, Nov 12, 2009 at 07:54:25AM +0900, furaisanjin wrote:
Hi.
My problem also seems to be fixed because it's very harder to reproduce the problem now.
Is still possible to trigger the problem (but very hard)?
By the way, I'm a bit wondering this code and I suppose something like this.
--- dillo/src/IO/dpi.c 2009-11-11 05:51:28.000000000 +0900 +++ dillo-test/src/IO/dpi.c 2009-11-11 22:05:42.000000000 +0900 @@ -793,12 +793,15 @@ char *a_Dpi_send_blocking_cmd(const char
if ((sock_fd = Dpi_connect_socket(server_name, TRUE)) == -1) { MSG_ERR("[a_Dpi_send_blocking_cmd] Can't connect to server.\n"); - } else if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { - MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); - } if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { - MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); + } else { + if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { + MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); + } + if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { + MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); + } + Dpi_close_fd(sock_fd); } - Dpi_close_fd(sock_fd);
Dpi_close_fd() checks fd != -1 so AFAIS it's OK. BTW, I chasing a very weird bug here. I can't modify a bookmark unless I comment closing a stream on an unrelated file! This is: @@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) SharedKey[i] = 0; ret = 1; } - if (In) - fclose(In); Then it works! :-P @all: The question is, is this happening only in my system or do you see the problem as well. In other words: can you modify a bookmark? -- Cheers Jorge.-
Jorge wrote:
BTW, I chasing a very weird bug here. I can't modify a bookmark unless I comment closing a stream on an unrelated file!
This is:
@@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) SharedKey[i] = 0; ret = 1; } - if (In) - fclose(In);
Then it works! :-P
@all: The question is, is this happening only in my system or do you see the problem as well. In other words: can you modify a bookmark?
I don't normally use bookmarks, but if I try it, I click submit, get Nav_open_url: new url='dpi:/bm/modify?operation=modify&submit=submit.&s0=on&url1=on' Nav_open_url: new url='dpi:/bm/modify' and...nothing else seems to happen.
On Thu, Nov 12, 2009 at 12:08:33AM +0000, corvid wrote:
Jorge wrote:
BTW, I chasing a very weird bug here. I can't modify a bookmark unless I comment closing a stream on an unrelated file!
This is:
@@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) SharedKey[i] = 0; ret = 1; } - if (In) - fclose(In);
Then it works! :-P
@all: The question is, is this happening only in my system or do you see the problem as well. In other words: can you modify a bookmark?
I don't normally use bookmarks, but if I try it, I click submit, get Nav_open_url: new url='dpi:/bm/modify?operation=modify&submit=submit.&s0=on&url1=on' Nav_open_url: new url='dpi:/bm/modify'
and...nothing else seems to happen.
Exactly as here... and if you apply the above patch? -- Cheers Jorge.-
Jorge wrote:
On Thu, Nov 12, 2009 at 12:08:33AM +0000, corvid wrote:
Jorge wrote:
BTW, I chasing a very weird bug here. I can't modify a bookmark unless I comment closing a stream on an unrelated file!
This is:
@@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) SharedKey[i] = 0; ret = 1; } - if (In) - fclose(In);
Then it works! :-P
@all: The question is, is this happening only in my system or do you see the problem as well. In other words: can you modify a bookmark?
I don't normally use bookmarks, but if I try it, I click submit, get Nav_open_url: new url='dpi:/bm/modify?operation=modify&submit=submit.&s0=on&url1=on' Nav_open_url: new url='dpi:/bm/modify'
and...nothing else seems to happen.
Exactly as here...
and if you apply the above patch?
Yup, I get a new page for updating the title.
On Thu, Nov 12, 2009 at 04:28:05AM +0000, corvid wrote:
Jorge wrote:
On Thu, Nov 12, 2009 at 12:08:33AM +0000, corvid wrote:
Jorge wrote:
BTW, I chasing a very weird bug here. I can't modify a bookmark unless I comment closing a stream on an unrelated file!
This is:
@@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) SharedKey[i] = 0; ret = 1; } - if (In) - fclose(In);
Then it works! :-P
@all: The question is, is this happening only in my system or do you see the problem as well. In other words: can you modify a bookmark?
I don't normally use bookmarks, but if I try it, I click submit, get Nav_open_url: new url='dpi:/bm/modify?operation=modify&submit=submit.&s0=on&url1=on' Nav_open_url: new url='dpi:/bm/modify'
and...nothing else seems to happen.
Exactly as here...
and if you apply the above patch?
Yup, I get a new page for updating the title.
There were two bugs in this problem: a FD leak, and an obscure bug with socket closing. I committed a workaround that makes it work. The last thing to blame is external libraries or the kernel itself, but this bug is weird enough to keep the possibility open. Not closing a completely unrelated stream (above-quoted patch) also made it work. This makes me think that something happens in the OS' FD handling code. The committed workaround is a usleep(2) before closing the socket (which shouldn't be necessary AFAIU because as from the SPEC, in that case the socket must deliver in background). I've tried with different kernels (and glibc) and the same bug shows. Corvid also reported it. The question is: Is anyone using *BSD seeing it? Note: the bug is not being able to see bookmark's "Add Section" page. Go to modify, select "add section", and submit. If you see the page, there's no bug. Note2: please test with and without the workaround patch! ;) -- Cheers Jorge.-
On Wed, Nov 18, 2009 at 09:45:26AM -0300, Jorge Arellano Cid wrote:
On Thu, Nov 12, 2009 at 04:28:05AM +0000, corvid wrote:
Jorge wrote:
On Thu, Nov 12, 2009 at 12:08:33AM +0000, corvid wrote:
Jorge wrote:
BTW, I chasing a very weird bug here. I can't modify a bookmark unless I comment closing a stream on an unrelated file!
This is:
@@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) SharedKey[i] = 0; ret = 1; } - if (In) - fclose(In);
Then it works! :-P
@all: The question is, is this happening only in my system or do you see the problem as well. In other words: can you modify a bookmark?
I don't normally use bookmarks, but if I try it, I click submit, get Nav_open_url: new url='dpi:/bm/modify?operation=modify&submit=submit.&s0=on&url1=on' Nav_open_url: new url='dpi:/bm/modify'
and...nothing else seems to happen.
Exactly as here...
and if you apply the above patch?
Yup, I get a new page for updating the title.
There were two bugs in this problem: a FD leak, and an obscure bug with socket closing. I committed a workaround that makes it work.
The last thing to blame is external libraries or the kernel itself, but this bug is weird enough to keep the possibility open.
Not closing a completely unrelated stream (above-quoted patch) also made it work. This makes me think that something happens in the OS' FD handling code. The committed workaround is a usleep(2) before closing the socket (which shouldn't be necessary AFAIU because as from the SPEC, in that case the socket must deliver in background).
I've tried with different kernels (and glibc) and the same bug shows. Corvid also reported it. The question is: Is anyone using *BSD seeing it?
Note: the bug is not being able to see bookmark's "Add Section" page. Go to modify, select "add section", and submit. If you see the page, there's no bug.
Note2: please test with and without the workaround patch! ;)
I see the bug on DragonFly BSD with and without the workaround. However it seems to work when truss-ing the bookmarks dpi... Cheers, Johannes
Hi. I see the problem on FreeBSD (6.4) as well. But if I modify dillo like this, diff -r 0a016f48a68b src/capi.c --- a/src/capi.c Sun Nov 15 13:00:56 2009 +0100 +++ b/src/capi.c Thu Nov 19 08:04:20 2009 +0900 @@ -519,7 +519,7 @@ _MSG("a_Capi_stop_client: force=%d\n", force); Client = a_Cache_client_get_if_unique(Key); - if (Client && (force || Client->BufSize == 0)) { + if (Client && force) { /* remove empty entries too */ a_Capi_conn_abort_by_url(Client->Url); } I don't see the problem. Because the original Dillo didn't work well with my local HTTP proxy, I modified like above. I didn't dig out deeper but it seems that Dillo didn't close socket connection properly so that HTTP proxy thought the connection was still opened. Regards, furaisanjin
On Thu, Nov 19, 2009 at 08:10:44AM +0900, furaisanjin wrote:
Hi.
I see the problem on FreeBSD (6.4) as well. But if I modify dillo like this,
diff -r 0a016f48a68b src/capi.c --- a/src/capi.c Sun Nov 15 13:00:56 2009 +0100 +++ b/src/capi.c Thu Nov 19 08:04:20 2009 +0900 @@ -519,7 +519,7 @@ _MSG("a_Capi_stop_client: force=%d\n", force);
Client = a_Cache_client_get_if_unique(Key); - if (Client && (force || Client->BufSize == 0)) { + if (Client && force) { /* remove empty entries too */ a_Capi_conn_abort_by_url(Client->Url); }
I don't see the problem. Because the original Dillo didn't work well with my local HTTP proxy, I modified like above. I didn't dig out deeper but it seems that Dillo didn't close socket connection properly so that HTTP proxy thought the connection was still opened.
Excellent! This explains the race condition to me. @all: please test the patch in the repo and report. The problem with HTTP proxy *may* be a different thing, but it also may be fixed now. Please check and report. -- Cheers Jorge.-
2009/11/20 Jorge Arellano Cid <jcid@dillo.org>:
?@all: please test the patch in the repo and report.
Bookmark problem is fixed on FreeBSD.
?The ?problem with HTTP proxy *may* be a different thing, but it also may be fixed now. Please check and report.
Still I need to modify for HTTP proxy, so the root cause is different. Regards, furaisanjin
2009/11/12 Jorge Arellano Cid <jcid@dillo.org>:
On Thu, Nov 12, 2009 at 07:54:25AM +0900, furaisanjin wrote:
Hi.
My problem also seems to be fixed because it's very harder to reproduce the problem now.
?Is still possible to trigger the problem (but very hard)?
I have no idea but the problem did happen in one hour but now it's very difficult to make it happen.
By the way, I'm a bit wondering this code and I suppose something like this.
--- dillo/src/IO/dpi.c ?2009-11-11 05:51:28.000000000 +0900 +++ dillo-test/src/IO/dpi.c ? ? 2009-11-11 22:05:42.000000000 +0900 @@ -793,12 +793,15 @@ char *a_Dpi_send_blocking_cmd(const char
? ? if ((sock_fd = Dpi_connect_socket(server_name, TRUE)) == -1) { ? ? ? ?MSG_ERR("[a_Dpi_send_blocking_cmd] Can't connect to server.\n"); - ? } else if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { - ? ? ?MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); - ? } if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { - ? ? ?MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); + ? } else { + ? ? if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { + ? ? ? MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); + ? ? } + ? ? if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { + ? ? ? MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); + ? ? } + ? ? Dpi_close_fd(sock_fd); ? ? } - ? Dpi_close_fd(sock_fd);
?Dpi_close_fd() checks fd != -1 so AFAIS it's OK.
I meant Dpi_blocking_read as well. Regards, furaisanjin
On Thu, Nov 12, 2009 at 09:01:03PM +0900, furaisanjin wrote:
This misleads, so I clarify.
2009/11/12 furaisanjin <furaisanjin@gmail.com>:
I have no idea but the problem did happen in one hour but now it's very difficult to make it happen.
I haven't seen it since I applied the patch.
Thanks, it's good to hear that! ;) -- Cheers Jorge.-
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.-
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.-
participants (4)
-
corvid＠lavabit.com -
furaisanjin＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de