Jeremy wrote:
Now the bad news: this HTML almost invariably crashes Dillo:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" /> </head> <body> </body> </html>
The culprit is the <meta...> tag. Dillo always crashes in one of two ways: segmentation fault or glibc detecting memory corruption and aborting. In each case the backtrace from gdb is the same (verified by running Dillo 100 times (it only failed to crash twice)). The backtraces show that the Cache_* functions are freeing things they should not. Valgrind confirms this. I'm attaching backtraces and a valgrind log.
That's not bad news. Getting to fix a bug is a good thing. Try the attached patch. Meta causes a repush, which eventually finds its way to Cache_delayed_process_queue_callback(). In Cache_process_queue(), the fact that the content type is not viewable causes an abort and the cache entry is removed. This is bad for my subsequent Cache_unref_data(entry). (The entries currently have reference counting so that I know when I can get rid of the UTF8-ized data.) If you put some text above the meta tag, you still have some text visible that you can right-click to pop up the page menu. Trying the menu options doesn't crash anything, but...hmmm...are there are implications to not having a cache entry backing the page? (BTW, I have begun to wonder whether UTF-8 text/* decoding and dicache/imgbuf image/* decoding should develop similarities. Haven't thought about it in any detail, though.)