Hi, Here's a prototype patch that does the work. It's not yet optimized nor polished nor throughly tested, and it leaks Web structures, but it illustrates very well the idea, and finishing it shouldn't be hard. As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-) -- Cheers Jorge.-
On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote:
As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-)
Good news. I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :) Bottom line: don't waste much time with the CCC and its docs in current repo, most probably they will be replaced soon. -- Cheers Jorge.-
Jorge wrote:
On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote:
As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-)
Good news.
I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :)
Something isn't working right in the new code for Abort. If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault. (interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.)
On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote:
Jorge wrote:
On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote:
As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-)
Good news.
I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :)
Something isn't working right in the new code for Abort.
If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault.
(interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.)
Good! This will hopefully help me clean some old ad-hoc bindings. A simple way to avoid the segfault is to comment the line at http.c:497 (i.e. leave it as it was). Now, my idea is to standardize OpAbort, and have a uniform way to call it and thus avoid ad-hoc calls/non-calls that nobody understands. This may take some time or just a bit (we'll see..). The plan is to include the empty-cache-entry removal feature and improve OpStop once things are uniform. Stay tuned... -- Cheers Jorge.-
On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote:
Jorge wrote:
On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote:
As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-)
Good news.
I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :)
Something isn't working right in the new code for Abort.
If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault.
(interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.)
[...] Now after dns resolution times out, retrying in a new window/tab doesn't seem to work.
Please try the current tip. It's not definitive, but it looks like with some API polish it may be. -- Cheers Jorge.-
Jorge wrote:
On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote:
Jorge wrote:
On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote:
As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-)
Good news.
I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :)
Something isn't working right in the new code for Abort.
If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault.
(interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.)
[...] Now after dns resolution times out, retrying in a new window/tab doesn't seem to work.
Please try the current tip. It's not definitive, but it looks like with some API polish it may be.
Oh, there still is a bug after all. If I'm not connected and I try to go to a host that I have listed in /etc/hosts, then ^Q gives me a segfault.
On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote:
Jorge wrote:
On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote:
Jorge wrote:
On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote:
As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-)
Good news.
I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :)
Something isn't working right in the new code for Abort.
If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault.
(interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.)
[...] Now after dns resolution times out, retrying in a new window/tab doesn't seem to work.
Please try the current tip. It's not definitive, but it looks like with some API polish it may be.
Oh, there still is a bug after all.
Yes, it's the same bug BTW. I added a new function call to the CCC API (wrapping the trick of the previous patch) and used it in three parts of the code. Please check the tip.
If I'm not connected and I try to go to a host that I have listed in /etc/hosts, then ^Q gives me a segfault.
Another SEGFAULT path was: load dillo home disconnect Internet click 9years press stop All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks. -- Cheers Jorge.-
Jorge wrote:
On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote:
Jorge wrote:
On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote:
Jorge wrote:
On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote:
As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-)
Good news.
I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :)
Something isn't working right in the new code for Abort.
If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault.
(interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.)
[...] Now after dns resolution times out, retrying in a new window/tab doesn't seem to work.
Please try the current tip. It's not definitive, but it looks like with some API polish it may be.
Oh, there still is a bug after all.
Yes, it's the same bug BTW.
I added a new function call to the CCC API (wrapping the trick of the previous patch) and used it in three parts of the code. Please check the tip.
If I'm not connected and I try to go to a host that I have listed in /etc/hosts, then ^Q gives me a segfault.
Another SEGFAULT path was: load dillo home disconnect Internet click 9years press stop
All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks.
I don't know whether it's a problem, but I just noticed a difference in behaviour in that my form testcase that submits to localhost (there's no server listening) only prints "submitting multipart/form-data!" and I have to press stop to get '** WARNING **: IO_write, closing with pending data not sent' and see the query.
On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote:
Jorge wrote:
[...] All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks.
I don't know whether it's a problem, but I just noticed a difference in behaviour in that my form testcase that submits to localhost (there's no server listening) only prints "submitting multipart/form-data!" and I have to press stop to get '** WARNING **: IO_write, closing with pending data not sent' and see the query.
Yes, I'm yet to look into it. BTW, just committed a patch for an elusive bug. Now it's possible to browse (& populate DNS cache), disconnect, click a link, have the abort operation on no network condition, reconnect and click it again (and it will work!). The only bit missing is how to make the link return to its normal color. a_Nav_repush() can do it easily but looks like an overkill. Maybe Johannes has a good idea on this? -- Cheers Jorge.-
On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote:
On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote:
Jorge wrote:
[...] All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks.
I don't know whether it's a problem, but I just noticed a difference in behaviour in that my form testcase that submits to localhost (there's no server listening) only prints "submitting multipart/form-data!" and I have to press stop to get '** WARNING **: IO_write, closing with pending data not sent' and see the query.
Yes, I'm yet to look into it.
BTW, just committed a patch for an elusive bug. Now it's possible to browse (& populate DNS cache), disconnect, click a link, have the abort operation on no network condition, reconnect and click it again (and it will work!).
The only bit missing is how to make the link return to its normal color. a_Nav_repush() can do it easily but looks like an overkill. Maybe Johannes has a good idea on this?
Not sure why it should change it's color. It's still a visited link after all. Or does the link color have another semantics (like page is in cache) in dillo? Anyway, the real solution would need the DOM-tree which is currently not available. The DOM-tree would also be needed for :hover, :active, and for Javascript. However we could add a hack similar to the one to compute html->visited_color in Html_tag_open_body(). It assumes that there is just one visited_color in the whole page. Cheers, Johannes
On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote:
On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote:
On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote:
Jorge wrote:
[...] All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks.
I don't know whether it's a problem, but I just noticed a difference in behaviour in that my form testcase that submits to localhost (there's no server listening) only prints "submitting multipart/form-data!" and I have to press stop to get '** WARNING **: IO_write, closing with pending data not sent' and see the query.
Yes, I'm yet to look into it.
BTW, just committed a patch for an elusive bug. Now it's possible to browse (& populate DNS cache), disconnect, click a link, have the abort operation on no network condition, reconnect and click it again (and it will work!).
The only bit missing is how to make the link return to its normal color. a_Nav_repush() can do it easily but looks like an overkill. Maybe Johannes has a good idea on this?
Not sure why it should change it's color. It's still a visited link after all.
AFAIS: clicked, not visited! (it was clicked and aborted before the data stream came in).
Or does the link color have another semantics (like page is in cache) in dillo?
Currently, it means exactly that: "page is in cache". That's why our FAQ links appear in visited color: http://www.dillo.org/FAQ.html If there's a good reason to change it, it should be simple. I see little difference for broadband users; dialup users may like the hint of what's available without connection. No strong feelings on this.
Anyway, the real solution would need the DOM-tree which is currently not available. The DOM-tree would also be needed for :hover, :active, and for Javascript. However we could add a hack similar to the one to compute html->visited_color in Html_tag_open_body(). It assumes that there is just one visited_color in the whole page.
Maybe a repush is not as bad a solution after all. ;) BTW, I hope you're comfortable in your new flat. -- Cheers Jorge.-
Jorge wrote:
On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote:
On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote:
BTW, just committed a patch for an elusive bug. Now it's possible to browse (& populate DNS cache), disconnect, click a link, have the abort operation on no network condition, reconnect and click it again (and it will work!).
The only bit missing is how to make the link return to its normal color. a_Nav_repush() can do it easily but looks like an overkill. Maybe Johannes has a good idea on this?
Not sure why it should change it's color. It's still a visited link after all.
AFAIS: clicked, not visited! (it was clicked and aborted before the data stream came in).
Or does the link color have another semantics (like page is in cache) in dillo?
Currently, it means exactly that: "page is in cache". That's why our FAQ links appear in visited color: http://www.dillo.org/FAQ.html
If there's a good reason to change it, it should be simple. I see little difference for broadband users; dialup users may like the hint of what's available without connection. No strong feelings on this.
If we really care, I guess there's always alink/active:
On Wed, Aug 19, 2009 at 03:37:17AM +0000, corvid wrote:
Jorge wrote:
On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote:
On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote:
BTW, just committed a patch for an elusive bug. Now it's possible to browse (& populate DNS cache), disconnect, click a link, have the abort operation on no network condition, reconnect and click it again (and it will work!).
The only bit missing is how to make the link return to its normal color. a_Nav_repush() can do it easily but looks like an overkill. Maybe Johannes has a good idea on this?
Not sure why it should change it's color. It's still a visited link after all.
AFAIS: clicked, not visited! (it was clicked and aborted before the data stream came in).
Or does the link color have another semantics (like page is in cache) in dillo?
Currently, it means exactly that: "page is in cache". That's why our FAQ links appear in visited color: http://www.dillo.org/FAQ.html
If there's a good reason to change it, it should be simple. I see little difference for broadband users; dialup users may like the hint of what's available without connection. No strong feelings on this.
If we really care, I guess there's always alink/active:
I think the point is: do we follow Firefox and present links in "visited" color only once the user's been there? Is there any advantage of one scheme over the other? Is expected behaviour (FF) more relevant? If users would like to keep dillo's behaviour. Is it worth a preference? (dialup or for any other reason) -- Cheers Jorge.-
On Tue, Aug 18, 2009 at 08:42:28PM -0400, Jorge Arellano Cid wrote:
On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote:
On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote:
On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote:
Jorge wrote:
[...] All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks.
I don't know whether it's a problem, but I just noticed a difference in behaviour in that my form testcase that submits to localhost (there's no server listening) only prints "submitting multipart/form-data!" and I have to press stop to get '** WARNING **: IO_write, closing with pending data not sent' and see the query.
Yes, I'm yet to look into it.
BTW, just committed a patch for an elusive bug. Now it's possible to browse (& populate DNS cache), disconnect, click a link, have the abort operation on no network condition, reconnect and click it again (and it will work!).
The only bit missing is how to make the link return to its normal color. a_Nav_repush() can do it easily but looks like an overkill. Maybe Johannes has a good idea on this?
Not sure why it should change it's color. It's still a visited link after all.
AFAIS: clicked, not visited! (it was clicked and aborted before the data stream came in).
True. Perhaps we could change the link color to "visited" only after first data has arrived? Then we would not need to undo it on abort.
Or does the link color have another semantics (like page is in cache) in dillo?
Currently, it means exactly that: "page is in cache". That's why our FAQ links appear in visited color: http://www.dillo.org/FAQ.html
If there's a good reason to change it, it should be simple. I see little difference for broadband users; dialup users may like the hint of what's available without connection. No strong feelings on this.
Anyway, the real solution would need the DOM-tree which is currently not available. The DOM-tree would also be needed for :hover, :active, and for Javascript. However we could add a hack similar to the one to compute html->visited_color in Html_tag_open_body(). It assumes that there is just one visited_color in the whole page.
Maybe a repush is not as bad a solution after all. ;)
I'd like to try the DOM-thing. It's not very complicated, but it will use some memory on large pages.
BTW, I hope you're comfortable in your new flat.
Yes, thanks. We're slowly getting back to normal :) Cheers, Johannes
Jorge wrote:
On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote:
Jorge wrote:
On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote:
Jorge wrote:
On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote:
As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-)
Good news.
I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :)
Something isn't working right in the new code for Abort.
If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault.
(interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.)
[...] Now after dns resolution times out, retrying in a new window/tab doesn't seem to work.
Please try the current tip. It's not definitive, but it looks like with some API polish it may be.
Oh, there still is a bug after all.
Yes, it's the same bug BTW.
I added a new function call to the CCC API (wrapping the trick of the previous patch) and used it in three parts of the code. Please check the tip.
If I'm not connected and I try to go to a host that I have listed in /etc/hosts, then ^Q gives me a segfault.
Another SEGFAULT path was: load dillo home disconnect Internet click 9years press stop
All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks.
I just got a segfault on NULL Info when going to the https url for the uclinux page: #0 0x0805cde1 in a_Chain_check (FuncStr=0x8118363 "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x08063c72 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x83e5ab0, Data2=0x0) at capi.c:522 #2 0x08063028 in Capi_conn_resume () at capi.c:172 #3 0x08063f10 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x8cd2728, Data1=0x0, Data2=0x8122730) at capi.c:577 #4 0x0805cc80 in a_Chain_fcb (Op=2, Info=0x88224c0, Data1=0x0, Data2=0x8122730) at chain.c:113 #5 0x08086d95 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x88224c0, Data1=0x8b8d260, Data2=0x0) at dpi.c:625 #6 0x0805cd07 in a_Chain_bcb (Op=1, Info=0x8cd2728, Data1=0x8b8d260, Data2=0x0) at chain.c:136 #7 0x08063d6d in a_Capi_ccc (Op=1, Branch=1, Dir=2, Info=0x8cd2728, Data1=0x8936478, Data2=0x8b8d260) at capi.c:539 #8 0x08063b62 in a_Capi_dpi_send_cmd (url=0x8f1ef08, bw=0x81df6e8, cmd=0x8ee2400 "<cmd='open_url' url='https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=ForumMessageBrowse&thread_id=35676&action=ForumBrowse&forum_id=39' query='GET /gf/project/uclinux-dist/fo"..., server=0x8b8d260 "proto.https", flags=1) at capi.c:482 [snip]
On Wed, Aug 12, 2009 at 11:45:27PM +0000, corvid wrote:
Jorge wrote:
On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote:
Jorge wrote:
I added a new function call to the CCC API (wrapping the trick of the previous patch) and used it in three parts of the code. Please check the tip.
If I'm not connected and I try to go to a host that I have listed in /etc/hosts, then ^Q gives me a segfault.
Another SEGFAULT path was: load dillo home disconnect Internet click 9years press stop
All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks.
I just got a segfault on NULL Info when going to the https url for the uclinux page:
#0 0x0805cde1 in a_Chain_check (FuncStr=0x8118363 "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x08063c72 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x83e5ab0, Data2=0x0) at capi.c:522 #2 0x08063028 in Capi_conn_resume () at capi.c:172 #3 0x08063f10 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x8cd2728, Data1=0x0, Data2=0x8122730) at capi.c:577 #4 0x0805cc80 in a_Chain_fcb (Op=2, Info=0x88224c0, Data1=0x0, Data2=0x8122730) at chain.c:113 #5 0x08086d95 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x88224c0, Data1=0x8b8d260, Data2=0x0) at dpi.c:625 #6 0x0805cd07 in a_Chain_bcb (Op=1, Info=0x8cd2728, Data1=0x8b8d260, Data2=0x0) at chain.c:136 #7 0x08063d6d in a_Capi_ccc (Op=1, Branch=1, Dir=2, Info=0x8cd2728, Data1=0x8936478, Data2=0x8b8d260) at capi.c:539 #8 0x08063b62 in a_Capi_dpi_send_cmd (url=0x8f1ef08, bw=0x81df6e8, cmd=0x8ee2400 "<cmd='open_url' url='https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=ForumMessageBrowse&thread_id=35676&action=ForumBrowse&forum_id=39' query='GET /gf/project/uclinux-dist/fo"..., server=0x8b8d260 "proto.https", flags=1) at capi.c:482 [snip]
Just committed a patch that's being a delight to test! :) It's the long waited for "empty cache entries removal". Now it's done automatically on clicking a new link, and manually with the Stop button. It doesn't sound impressive, but for instance, if you hit a blog site full of heavy images, hitting the Stop button will abort all the empty connections (not only stop rendering as in the past). This allows for much faster browsing, especially with low bandwidth, as the bandwidth is "rescued" from unwanted contents. Another gain happens when a requested link takes a long time to start flowing (e.g. ignored request by a busy browser). Just press stop, click the link again and there you are. Please test, and enjoy! BTW: I don't remember whether a fix for the uClinux URL above was already committed. It didn't SEGFAULT when testing tip. -- Cheers Jorge.-
On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote:
On Wed, Aug 12, 2009 at 11:45:27PM +0000, corvid wrote:
Jorge wrote:
On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote:
Jorge wrote:
I added a new function call to the CCC API (wrapping the trick of the previous patch) and used it in three parts of the code. Please check the tip.
If I'm not connected and I try to go to a host that I have listed in /etc/hosts, then ^Q gives me a segfault.
Another SEGFAULT path was: load dillo home disconnect Internet click 9years press stop
All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks.
I just got a segfault on NULL Info when going to the https url for the uclinux page:
#0 0x0805cde1 in a_Chain_check (FuncStr=0x8118363 "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x08063c72 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x83e5ab0, Data2=0x0) at capi.c:522 #2 0x08063028 in Capi_conn_resume () at capi.c:172 #3 0x08063f10 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x8cd2728, Data1=0x0, Data2=0x8122730) at capi.c:577 #4 0x0805cc80 in a_Chain_fcb (Op=2, Info=0x88224c0, Data1=0x0, Data2=0x8122730) at chain.c:113 #5 0x08086d95 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x88224c0, Data1=0x8b8d260, Data2=0x0) at dpi.c:625 #6 0x0805cd07 in a_Chain_bcb (Op=1, Info=0x8cd2728, Data1=0x8b8d260, Data2=0x0) at chain.c:136 #7 0x08063d6d in a_Capi_ccc (Op=1, Branch=1, Dir=2, Info=0x8cd2728, Data1=0x8936478, Data2=0x8b8d260) at capi.c:539 #8 0x08063b62 in a_Capi_dpi_send_cmd (url=0x8f1ef08, bw=0x81df6e8, cmd=0x8ee2400 "<cmd='open_url' url='https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=ForumMessageBrowse&thread_id=35676&action=ForumBrowse&forum_id=39' query='GET /gf/project/uclinux-dist/fo"..., server=0x8b8d260 "proto.https", flags=1) at capi.c:482 [snip]
Just committed a patch that's being a delight to test! :)
It's the long waited for "empty cache entries removal". Now it's done automatically on clicking a new link, and manually with the Stop button.
It doesn't sound impressive, but for instance, if you hit a blog site full of heavy images, hitting the Stop button will abort all the empty connections (not only stop rendering as in the past). This allows for much faster browsing, especially with low bandwidth, as the bandwidth is "rescued" from unwanted contents.
Another gain happens when a requested link takes a long time to start flowing (e.g. ignored request by a busy browser). Just press stop, click the link again and there you are.
Please test, and enjoy!
Excellent! Especially as I have a slow internet connection atm.
BTW: I don't remember whether a fix for the uClinux URL above was already committed. It didn't SEGFAULT when testing tip.
I got some segfaults recently. I will try to get a proper stack trace. Cheers, Johannes
On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote:
On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote:
BTW: I don't remember whether a fix for the uClinux URL above was already committed. It didn't SEGFAULT when testing tip.
I got some segfaults recently. I will try to get a proper stack trace.
Ok here it is. It happend after a couple of hours: Core was generated by `dillo'. Program terminated with signal 11, Segmentation fault. #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { (gdb) bt #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) at capi.c:537 #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, Data2=0x80f7669) at capi.c:178 #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, Data2=0x0) at dpi.c:625 #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, cmd=0x86cf328 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", flags=<value optimized out>) at capi.c:493 #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 #10 0x080e22dc in fltk::Widget::send () #11 0x080d3935 in fltk::TabGroup::handle () #12 0x08054538 in CustTabGroup::handle (this=<value optimized out>, e=<value optimized out>) at uicmd.cc:312 #13 0x080e22dc in fltk::Widget::send () #14 0x080b2c0f in fltk::Group::handle () #15 0x080e4439 in fltk::Window::handle () #16 0x080e22dc in fltk::Widget::send () #17 0x080c7749 in fltk::handle () #18 0x080cac10 in fltk::handle () #19 0x080cc32d in do_queued_events () #20 0x080cc5a8 in fltk::wait () #21 0x080cc784 in fltk::run () #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 Current language: auto; currently c (gdb) Cheers, Johannes
On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote:
On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote:
On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote:
BTW: I don't remember whether a fix for the uClinux URL above was already committed. It didn't SEGFAULT when testing tip.
I got some segfaults recently. I will try to get a proper stack trace.
Ok here it is. It happend after a couple of hours:
Core was generated by `dillo'. Program terminated with signal 11, Segmentation fault. #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { (gdb) bt #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) at capi.c:537 #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, Data2=0x80f7669) at capi.c:178 #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, Data2=0x0) at dpi.c:625 #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, cmd=0x86cf328 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", flags=<value optimized out>) at capi.c:493 #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 #10 0x080e22dc in fltk::Widget::send () #11 0x080d3935 in fltk::TabGroup::handle () #12 0x08054538 in CustTabGroup::handle (this=<value optimized out>, e=<value optimized out>) at uicmd.cc:312 #13 0x080e22dc in fltk::Widget::send () #14 0x080b2c0f in fltk::Group::handle () #15 0x080e4439 in fltk::Window::handle () #16 0x080e22dc in fltk::Widget::send () #17 0x080c7749 in fltk::handle () #18 0x080cac10 in fltk::handle () #19 0x080cc32d in do_queued_events () #20 0x080cc5a8 in fltk::wait () #21 0x080cc784 in fltk::run () #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 Current language: auto; currently c (gdb)
Good. This is hard to track and I spent a lot of time trying to figure a way for it to happen. I don't yet find it, but at least saw there may be a small race window while the conn is unref'ed twice. Protection committed. Please test. -- Cheers Jorge.-
On Sun, Aug 23, 2009 at 09:43:26AM -0400, Jorge Arellano Cid wrote:
On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote:
On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote:
On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote:
BTW: I don't remember whether a fix for the uClinux URL above was already committed. It didn't SEGFAULT when testing tip.
I got some segfaults recently. I will try to get a proper stack trace.
Ok here it is. It happend after a couple of hours:
Core was generated by `dillo'. Program terminated with signal 11, Segmentation fault. #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { (gdb) bt #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) at capi.c:537 #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, Data2=0x80f7669) at capi.c:178 #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, Data2=0x0) at dpi.c:625 #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, cmd=0x86cf328 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", flags=<value optimized out>) at capi.c:493 #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 #10 0x080e22dc in fltk::Widget::send () #11 0x080d3935 in fltk::TabGroup::handle () #12 0x08054538 in CustTabGroup::handle (this=<value optimized out>, e=<value optimized out>) at uicmd.cc:312 #13 0x080e22dc in fltk::Widget::send () #14 0x080b2c0f in fltk::Group::handle () #15 0x080e4439 in fltk::Window::handle () #16 0x080e22dc in fltk::Widget::send () #17 0x080c7749 in fltk::handle () #18 0x080cac10 in fltk::handle () #19 0x080cc32d in do_queued_events () #20 0x080cc5a8 in fltk::wait () #21 0x080cc784 in fltk::run () #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 Current language: auto; currently c (gdb)
Good.
This is hard to track and I spent a lot of time trying to figure a way for it to happen. I don't yet find it, but at least saw there may be a small race window while the conn is unref'ed twice.
Protection committed. Please test.
No crash so far! I will keep testing. Thanks, Johannes
On Mon, Aug 24, 2009 at 11:29:45PM +0200, Johannes Hofmann wrote:
On Sun, Aug 23, 2009 at 09:43:26AM -0400, Jorge Arellano Cid wrote:
On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote:
On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote:
On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote:
BTW: I don't remember whether a fix for the uClinux URL above was already committed. It didn't SEGFAULT when testing tip.
I got some segfaults recently. I will try to get a proper stack trace.
Ok here it is. It happend after a couple of hours:
Core was generated by `dillo'. Program terminated with signal 11, Segmentation fault. #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { (gdb) bt #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) at capi.c:537 #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, Data2=0x80f7669) at capi.c:178 #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, Data2=0x0) at dpi.c:625 #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, cmd=0x86cf328 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", flags=<value optimized out>) at capi.c:493 #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 #10 0x080e22dc in fltk::Widget::send () #11 0x080d3935 in fltk::TabGroup::handle () #12 0x08054538 in CustTabGroup::handle (this=<value optimized out>, e=<value optimized out>) at uicmd.cc:312 #13 0x080e22dc in fltk::Widget::send () #14 0x080b2c0f in fltk::Group::handle () #15 0x080e4439 in fltk::Window::handle () #16 0x080e22dc in fltk::Widget::send () #17 0x080c7749 in fltk::handle () #18 0x080cac10 in fltk::handle () #19 0x080cc32d in do_queued_events () #20 0x080cc5a8 in fltk::wait () #21 0x080cc784 in fltk::run () #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 Current language: auto; currently c (gdb)
Good.
This is hard to track and I spent a lot of time trying to figure a way for it to happen. I don't yet find it, but at least saw there may be a small race window while the conn is unref'ed twice.
Protection committed. Please test.
No crash so far! I will keep testing.
I can't crash it anymore. I guess we can consider this fixed :) BTW, is the CCC simplification related to the connection limit patch? Cheers, Johannes
On Fri, Aug 28, 2009 at 09:06:06PM +0200, Johannes Hofmann wrote:
On Mon, Aug 24, 2009 at 11:29:45PM +0200, Johannes Hofmann wrote:
On Sun, Aug 23, 2009 at 09:43:26AM -0400, Jorge Arellano Cid wrote:
On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote:
On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote:
On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote:
BTW: I don't remember whether a fix for the uClinux URL above was already committed. It didn't SEGFAULT when testing tip.
I got some segfaults recently. I will try to get a proper stack trace.
Ok here it is. It happend after a couple of hours:
Core was generated by `dillo'. Program terminated with signal 11, Segmentation fault. #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { (gdb) bt #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) at capi.c:537 #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, Data2=0x80f7669) at capi.c:178 #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, Data2=0x0) at dpi.c:625 #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, cmd=0x86cf328 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", flags=<value optimized out>) at capi.c:493 #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 #10 0x080e22dc in fltk::Widget::send () #11 0x080d3935 in fltk::TabGroup::handle () #12 0x08054538 in CustTabGroup::handle (this=<value optimized out>, e=<value optimized out>) at uicmd.cc:312 #13 0x080e22dc in fltk::Widget::send () #14 0x080b2c0f in fltk::Group::handle () #15 0x080e4439 in fltk::Window::handle () #16 0x080e22dc in fltk::Widget::send () #17 0x080c7749 in fltk::handle () #18 0x080cac10 in fltk::handle () #19 0x080cc32d in do_queued_events () #20 0x080cc5a8 in fltk::wait () #21 0x080cc784 in fltk::run () #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 Current language: auto; currently c (gdb)
Good.
This is hard to track and I spent a lot of time trying to figure a way for it to happen. I don't yet find it, but at least saw there may be a small race window while the conn is unref'ed twice.
Protection committed. Please test.
No crash so far! I will keep testing.
I can't crash it anymore. I guess we can consider this fixed :)
Good.
BTW, is the CCC simplification related to the connection limit patch?
Yes and no. Yes: it may help with memory handling. No : the simplification was originally meant to help with stop. (and it has served to iron and clean other bugs too). -- Cheers Jorge.-
Jorge wrote:
Just committed a patch that's being a delight to test! :)
It's the long waited for "empty cache entries removal". Now it's done automatically on clicking a new link, and manually with the Stop button.
It doesn't sound impressive, but for instance, if you hit a blog site full of heavy images, hitting the Stop button will abort all the empty connections (not only stop rendering as in the past). This allows for much faster browsing, especially with low bandwidth, as the bandwidth is "rescued" from unwanted contents.
Another gain happens when a requested link takes a long time to start flowing (e.g. ignored request by a busy browser). Just press stop, click the link again and there you are.
Please test, and enjoy!
I just noticed that if I press Stop when an image is partly loaded, leave the page, and return, the image is gone. I wanted the image to stay because it was an image map and the part I cared about had already been received.
On Wed, Aug 26, 2009 at 04:55:05AM +0000, corvid wrote:
Jorge wrote:
Just committed a patch that's being a delight to test! :)
It's the long waited for "empty cache entries removal". Now it's done automatically on clicking a new link, and manually with the Stop button.
It doesn't sound impressive, but for instance, if you hit a blog site full of heavy images, hitting the Stop button will abort all the empty connections (not only stop rendering as in the past). This allows for much faster browsing, especially with low bandwidth, as the bandwidth is "rescued" from unwanted contents.
Another gain happens when a requested link takes a long time to start flowing (e.g. ignored request by a busy browser). Just press stop, click the link again and there you are.
Please test, and enjoy!
I just noticed that if I press Stop when an image is partly loaded, leave the page, and return, the image is gone. I wanted the image to stay because it was an image map and the part I cared about had already been received.
Yes, that's the expected behaviour. Resume on HTTP connections is not implemented. This case is the only downside of the patch I've found. It's not a common case and the workaround is simple (just let the images you care for load before stopping or simply stop and keep the tab/page open). OTOH implementing HTTP resume is big work for just this bug. -- Cheers Jorge.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de