August 2010 - Dillo-dev - lists.mailman3.com

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > On Mon, Aug 30, 2010 at 11:28 PM, corvid <corvid(a)lavabit.com> wrote: > > I wonder whether it has to do with interrupted image downloading > > when it gets all of the remote stylesheets for a page and performs > > a repush. Or, more precisely, when an image has been requested but > > hasn't started coming back from the server. > > So what you're saying is, it's trying to fetch stylesheets between > requesting an image and receiving it, and that's what's causing the > problem? When stylesheets come in, they go through Html_css_load_callback(), and when the last one has been completely received, a_UIcmd_repush() is called to start the page rendering over again. Jorge did the repush code, but it seems to me that dillo continues to receive any partially-received images, whereas for images that haven't started to arrive, the connection is closed and a new connection is made to get the image during the second rendering. So when you mention images and IO callbacks, it comes to mind as a case where something funny could happen...

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On Mon, Aug 30, 2010 at 11:28 PM, corvid <corvid(a)lavabit.com> wrote: > I wonder whether it has to do with interrupted image downloading > when it gets all of the remote stylesheets for a page and performs > a repush. Or, more precisely, when an image has been requested but > hasn't started coming back from the server. So what you're saying is, it's trying to fetch stylesheets between requesting an image and receiving it, and that's what's causing the problem? > If you turn on image loading and turn off remote stylesheets, does it > work consistently? It seems to be working so far.

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > It turns out the PNG crashes mentioned below were in IO_timeout_cb (at > FD_SET), and had nothing to do with libpng/zlib after all -- I think it's > just my stupid timeout kludge. Ironically, my homepage is one of the > crashing ones, though dillo.org is fine. On the other hand, it's quite > usable with image loading disabled. I wonder whether it has to do with interrupted image downloading when it gets all of the remote stylesheets for a page and performs a repush. Or, more precisely, when an image has been requested but hasn't started coming back from the server. If you turn on image loading and turn off remote stylesheets, does it work consistently?

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

Oops, my last e-mail went to just corvid and not the whole list. Sorry about that :-) Here's what I meant to send below, but first, my new patch page: http://dillo-win32.sourceforge.net/ The latest patch is online there, as well as a pre-compiled build for testing. It turns out the PNG crashes mentioned below were in IO_timeout_cb (at FD_SET), and had nothing to do with libpng/zlib after all -- I think it's just my stupid timeout kludge. Ironically, my homepage is one of the crashing ones, though dillo.org is fine. On the other hand, it's quite usable with image loading disabled. Thanks again for all the advice and encouragement so far. Hope it's been/will be worth it! Cheers, ~Benjamin On Mon, 30 Aug 2010 20:28:45 -0400, corvid <corvid(a)lavabit.com> wrote: > You shouldn't need both the decode.c change and the http.c change, > though. > Eventually it will be good for us to get to the very bottom of this > segfault problem... I got a few crashes loading PNG images, so I'm almost certain it's a zlib problem. I botched the install, so it's probably linked incorrectly on my machine. I'm going to leave the changes in for now, just to be on the safe side (and because re-building on MinGW can be quite a tedious process), but I'm re-building zlib/libjpeg/libpng/FLTK and doing one last test build now. If it doesn't crash, I'll assume it's safe to undo those changes. Updated patch and test build available shortly at http://dillo-win32.sourceforge.net/

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > On Mon, Aug 30, 2010 at 4:40 PM, corvid <corvid(a)lavabit.com> wrote: > > You might try undoing > > http://hg.dillo.org/dillo/rev/7447d4d53388 > > and I'll look through the zlib documentation to see whether inflate is > > supposed to do anything in particular with total_out when there's an error > > (if that's what's going on). > > See for yourself -- it's beautiful: > http://obeythepenguin.users.sourceforge.net/dillo/dillo-homepage-win32.png > > Reverting that change and disabling gzip was just the trick -- thank > you so much for that tip! Come to think of it, I had some trouble > building zlib (MinGW is always a little difficult), so it's likely a > problem with my DLL rather than Dillo or zlib per se. > > I'm just putting together a README now, and will send a link to the > updated patch (and probably a testing build, if anyone wants to play > with it) shortly. That's great! You shouldn't need both the decode.c change and the http.c change, though. Eventually it will be good for us to get to the very bottom of this segfault problem...

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On Mon, Aug 30, 2010 at 4:40 PM, corvid <corvid(a)lavabit.com> wrote: > You might try undoing > http://hg.dillo.org/dillo/rev/7447d4d53388 > and I'll look through the zlib documentation to see whether inflate is > supposed to do anything in particular with total_out when there's an error > (if that's what's going on). See for yourself -- it's beautiful: http://obeythepenguin.users.sourceforge.net/dillo/dillo-homepage-win32.png Reverting that change and disabling gzip was just the trick -- thank you so much for that tip! Come to think of it, I had some trouble building zlib (MinGW is always a little difficult), so it's likely a problem with my DLL rather than Dillo or zlib per se. I'm just putting together a README now, and will send a link to the updated patch (and probably a testing build, if anyone wants to play with it) shortly.

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

I wrote: > Benjamin wrote: > > On Mon, Aug 30, 2010 at 2:53 PM, corvid <corvid(a)lavabit.com> wrote: > > > What does the call stack look like? > > > > Here's the backtrace: > > http://obeythepenguin.users.sourceforge.net/dillo/misc/dStr_insert_l-backtr… > > Okay, so the lengths reported for dStr_append/insert_l() are -1163005939, > which is not good. > When we started in Decode_gzip(), we had 2934 bytes, which sounds normal enough. > > Looking at z_stream, total_out is a uLong and the dstr code expects an int, > but it would be hard to get a very large number there. You might try undoing http://hg.dillo.org/dillo/rev/7447d4d53388 and I'll look through the zlib documentation to see whether inflate is supposed to do anything in particular with total_out when there's an error (if that's what's going on).

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > On Mon, Aug 30, 2010 at 2:53 PM, corvid <corvid(a)lavabit.com> wrote: > > What does the call stack look like? > > Here's the backtrace: > http://obeythepenguin.users.sourceforge.net/dillo/misc/dStr_insert_l-backtr… Okay, so the lengths reported for dStr_append/insert_l() are -1163005939, which is not good. When we started in Decode_gzip(), we had 2934 bytes, which sounds normal enough. Looking at z_stream, total_out is a uLong and the dstr code expects an int, but it would be hard to get a very large number there. Does your interface allow you to inspect everything around the inflate call and see what values are good and how they go bad? PS If you like, you can take out the "Accept-Encoding: gzip\r\n" lines in src/IO/http.c to check how much of the rest of dillo is working...

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On Mon, Aug 30, 2010 at 2:53 PM, corvid <corvid(a)lavabit.com> wrote: > What does the call stack look like? Here's the backtrace: http://obeythepenguin.users.sourceforge.net/dillo/misc/dStr_insert_l-backtr… > Actually, if you saw inflate and you were coming through the decode.c > and cache.c code, I can't immediately think of a way that it would > necessarily be a dpi issue... All right, that makes sense since DPI should report a pipe error instead of segfaulting.

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > On Mon, 30 Aug 2010 13:22:52 -0400, corvid <corvid(a)lavabit.com> wrote: > >Benjamin wrote: > >>On 8/30/10, corvid <corvid(a)lavabit.com> wrote: > >>> Do you have an idea of what's wrong with the dStr_insert_l() crash? > >>I didn't get that far until late last night, since it took me a while > >>to figure out iowatch, but it looks like it happens during rendering. > >>I saw there's a zlib inflate (I think) somewhere up the call stack, > >>and that it segfaults at memcpy(), and that's about all I have so far. > > > >Does Windows let you get a meaningful backtrace? > > I have the call stack, and I'm not sure how much else. I'm using gdb via > Qt Creator, which is less than ideal, but it's the closest thing available > to a working front-end. What does the call stack look like? > >>Does Dillo use any temporary files when rendering a page? I haven't > >>adjusted paths.cc beyond mkdir() -> dMkdir(), so I wonder if that has > >>something to do with it. > > > >Nope. Although it can start trying to do dpi stuff while a page is > >coming. > > That might be it. What type of DPI stuff, specifically? I have some > conceptual understanding and I'm sure I saw it in the docs, but my > memory's a little hazy... Actually, if you saw inflate and you were coming through the decode.c and cache.c code, I can't immediately think of a way that it would necessarily be a dpi issue...

Aug. 30, 2010