Comment by rodarima | Hacker News Reader

Comment by rodarima | Hacker News Reader

Parent Full thread

> The default site is still dillo.org which crashed the browser when it tried to visit it. Same with duckduckgo.com (crashed). Actually the crash seems to be related to some assert failure with OpenSSL as recompiling Dillo with mbedSSL lets me visit these sites.

Thanks for testing! I need to replace that with the new website. Could you open an issue on GitHub with some details of your system and OpenSSL version so I can try to reproduce it?

> I tried to login and reply to this thread but for some reason it wouldn't login (no error or anything, after entering my username and password and clicking login, i'd remained logged out).

This is likely because the cookies are disabled. See the Cookies docs:

https://dillo-browser.github.io/old/dillo3-help.html

https://dillo-browser.github.io/old/Cookies.txt

By default, Dillo has all cookies disabled. You have to either manually enable them per site (recommended) or globally:

  $ echo "news.ycombinator.com ACCEPT" >> ~/.dillo/cookies.txt

Then reload the dpi daemon to read the cookies config again:

  $ dpidc stop

Here[0], i submitted a bug report. The issue seems to be that some OpenSSL error isn't handled elsewhere, isn't removed from the error queue and the function with the assertion assumes the queue is empty.

I put a breakpoint in ERR_put_error in the version that comes with openSUSE though there isn't much debug info there to be had so i don't know what the error is (perhaps building OpenSSL from source code with debug info and having Dillo link against it would help). I found where the error comes in Dillo's side (check the comment i made in the bug report) but i'm not sure how that'd be fixed (aside from draining the error queue :-P) as i don't know why these calls are made in the first place.

[0] https://github.com/dillo-browser/dillo/issues/51

The problem is fixed now in master. It was caused by an attempt to shutdown the SSL session (which requires sending data) in a closed file descriptor, which is handled different between OpenSSL (no thread error queued) and LibreSSL (badsectoracula was using LibreSSL, which queues a thread error), and later causes an assert to trigger as it was not expecting any error in the queue. See[1] for more details.

[1]: https://github.com/dillo-browser/dillo/pull/59

Thanks again for the report, these type of issues are hard to reproduce without using different environments.

Reply on news.ycombinator.com