- Dillo-dev - lists.mailman3.com

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

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

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. At some point I may try building with Visual C++, since its debugger is reportedly quite good, but for now I'd like to keep it simple and stick to what I have. >> 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... I should probably look at DPI next (which was my original intention anyway), then if there are still runtime issues, try to address them then. Thanks again, ~Benjamin

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

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? > 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.

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On 8/30/10, corvid <corvid(a)lavabit.com> wrote: > It looks like EAI_OVERFLOW is the one for buffer too small. Did I put the wrong constant in there? Thanks for the tip -- this is my first time working with sockets programming, so I'm sure I missed some other things as well. > 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 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.

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > - I've rewritten a_Dns_dillohost_to_string to use getnameinfo rather than > inet_ntop. From what I've seen online, getnameinfo is the preferred > function due to protocol(?) independence, among other features. More > importantly to my purposes, getnameinfo is cross-platform, whereas > inet_ntop is not. It looks like EAI_OVERFLOW is the one for buffer too small. Do you have an idea of what's wrong with the dStr_insert_l() crash?

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

Thought I should send in an update on Dillo-Win32. It still has a long ways to go before it's usable, but I believe the worst of the low-level changes are done, and if anyone can spare a moment I'd like to get some feedback on the implementation. First, the patch: http://obeythepenguin.users.sourceforge.net/dillo/dillo-r1698-win32-2010082… And now, a quick overview: - I've added two new APIs under dlib/. The first, dFcntl, wraps fcntl on Unix, and simulates it on Windows. The second, dSock, is an abstraction layer over the sockets interface (BSD sockets/Winsock). Among other things, it takes into account that on Windows, socket and file handles are not necessarily interchangeable [works to some degree on NT, but not 9x/Me]. N.B. The existing browser code has been converted to these APIs. - I've implemented an alternate iowatch mechanism using timeouts, to work around non-functioning fltk::add_fd on Windows. This kludge is only enabled when building on Windows; other platforms continue to use the existing, more efficient mechanism. Obviously a better solution in the long run would be to fix FLTK, but that's a project for another time. - I've rewritten a_Dns_dillohost_to_string to use getnameinfo rather than inet_ntop. From what I've seen online, getnameinfo is the preferred function due to protocol(?) independence, among other features. More importantly to my purposes, getnameinfo is cross-platform, whereas inet_ntop is not. - I also added a few other small portability functions and fixes, such as dMkdir in dlib.c; and more explicit relative #include paths, since MinGW seems to prefer those. There are still a few rough edges and probably a few more #ifdef's than I'd like (some deliberate, some from laziness...), but overall I've tried to keep it as clean as possible. This patch should not affect existing Unix behavior; I've been testing it in parallel on OpenBSD, though I have not tried it on others. Anyway, I've already said far too much, so at this point I'll let the code speak for itself. Apologies again for another long post. Thanks in advance for any feedback (and for all received so far), ~Benjamin

Aug. 30, 2010

[pc21820002000@yahoo.com.cn: I have ported dillo2 to a new cpu,nios2]

by jcid＠dillo.org

Hi, -- Cheers Jorge.-

Aug. 29, 2010