Jorge wrote:
It doesn't look like a race condition, but a problem of handling redirections and the null_decoder in cache.c (redirections is a somewhat ad-hoc code, not well designed yet).
Attached goes a page to reproduce the segfault (without the patch in CVS). For instance:
1- save the attached page in /tmp 2- dillo-fltk /tmp 3- click on the page 4- go back 5- go forward (segfault) // you may need to repeat this 4 and 5
Perhaps along these same lines, I did manage to break my image-loading code once when I clicked a few times on an image that wanted to redirect. I couldn't get it to crash again, though.
With regard to the iconv decoder:
Please note that we may still need the original data, to be able to save verbatim. This is, if the original page is encoded in latin2 (with a <meta http-equiv charset line in the source), and it is saved translated to UTF-8 we have two problems (the misleading "meta" and that the user will get a page that's not a verbatim copy of the original).
One way to solve this is to re-encode into the original charset at save time. This is not 8bit clean but could work most of the time.
Another way is to keep a copy of the verbatim data. In this case we're 8bit clean and it would only take more memory when the original is not UTF-8.
I *feel* 8bit clean is the correct path, and here there're lots of ways to optimize. For instance, with UTF-8 pages we don't need an extra buffer. For pages that need one, we can deallocate the UTF-8 encoded one when leaving the page (and re-create it if the page is visited again).
This is just some food for thought.
You had mentioned once before that you wanted to keep the original in cache, and I agree completely.