It would be good to find out what it's doing exactly for you. - I'd expect a client to be waiting for it in this case.
The client does not exist anymore because it has been destroyed too early. That is why I removed the timer in the previous patch. Debugging asynchronous code is difficult. I compiled Dillo with debugging symbols and added some printf()'s to see what is going on in detail. Afterwards I ran the binary through gdb. When visiting http://puppyisos.org/isos, everything looks alright in the beginning. The dialog pops up as expected. It is curious that we loop two times over ClientQueue though. Probably because the function is called every x received bytes, right? [New Thread 0xf760bb90 (LWP 14474)] [Thread 0xf760bb90 (LWP 14474) exited] Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Removing client (id=0) It seems that after confirming the authentication dialog, the page is being reloaded but without the header that is necessary for the HTTP authentication... Reloading page with authentication credentials... Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Removing client (id=0) At least this would explain, why the client for http://puppyisos.org/isos was deleted. Now the page is reloaded again because suddenly there is a client for http://puppyisos.org/isos/ again (with id=0): Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Removing client (id=0) Looping over ClientQueue... Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... Found (id=1). HTTP warning: unhandled MIME type: "text/html; charset=iso-8859-1" Looping over ClientQueue... Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... Found (id=1). Removing client (id=1) We should add support for charsets within MIME types anytime. As far as I know, Dillo only depends on meta-tags when deciding which encoding to go with. This notation is officially approved, see: http://www.w3.org/International/tutorials/tutorial-char-enc/#Slide0270 Reloading page with authentication credentials... Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Reloading page with authentication credentials... Why was the site reloaded again? Interestingly, no new client has been created for /isos this time. I am a bit astonished how often Cache_auth_callback() is called even though the dialog only appears once. Everything looks a bit asynchronous. An evidence might be the following lines: Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... In general, there should be a "Found (id=...)." or at least a "Not found!'" but they just follow after each other. And now it crashes: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf79bf6d0 (LWP 14340)] 0x0805ba14 in a_Nav_cancel_expect (bw=0x0) at nav.c:250 250 if (bw->nav_expecting) { Here is the back trace: (gdb) bt #0 0x0805ba14 in a_Nav_cancel_expect (bw=0x0) at nav.c:250 #1 0x0805c098 in a_Nav_reload (bw=0x0) at nav.c:474 #2 0x0805dd4e in Cache_auth_callback (vdata=0x8252208) at cache.c:971 #3 0xf7f23e75 in fltk::wait () from /usr/lib/libfltk2.so #4 0xf7f23f88 in fltk::run () from /usr/lib/libfltk2.so #5 0x0804f686 in main (argc=1, argv=0xffdf7b74) at dillo.cc:333
- I think a client shouldn't ever have a NULL bw.
I agree.
- The case where there are no clients waiting for the URL does sound like a bug, although I think I'd be tempted just not to call Cache_auth_entry() if the bw was NULL.
Unfortunately, that did not really help. Well, Dillo does not crash anymore but no images on this page are shown and it reloads several times before anything gets displayed.
Reloading doesn't crash it for me. Yes, I'm using the latest code.
In contrast to /isos, the main page (http://puppyisos.org/) is working alright here. No crashes, all images are displayed properly. There are some other directory listings on that site which are working, too even though there syntax is quite similar to /isos'.
You mentioned the other day that you get a lot of crashes in general, and I was surprised because I've had a total of three random crashes since 2.0 was released.
The situation has improved since I am browsing with the latest trunk. Nevertheless, I still experience non-reproducible crashes sometimes: It happens frequently that dpid ``crashes'' (100% CPU consumption). This happens mostly when domain names cannot be resolved correctly. Trying to reload the page does not solve it. I have to kill the process manually. PS: Having applied the patch, the iterations of the ClientQueue loop will now stop after the URL has matched. Previously, the iteration for the same entry item was then repeated again (if AbortEntry is true). Is there a reason for keeping it as-is? --Tim