- Dillo-dev - lists.mailman3.com

SSL in the browser

by andreas＠kemnade.info

Hi, On Tue, 21 Oct 2014 11:29:06 -0300 Jorge Arellano Cid <jcid at dillo.org> wrote: > Hi corvid, > > On Mon, Oct 20, 2014 at 11:47:35PM +0000, eocene wrote: > > I wrote: > > > http://www.dillo.org/test/ssl_in_browser.diff > > > > Fixed a couple of bugs, added a couple of features, new version up. > > Oh, as our mailsearch doesn't work anymore, is there > and URL to the original thread (Gmane style) or something? > > I'd like to remember what the main point of having SSL inside > the browser were. I'm getting old. ;) > here is a list of subjects which contain https, maybe that helps a bit. 2003-June.txt:Subject: [Dillo-dev] HTTPS support 2003-March.txt:Subject: [Dillo-dev] https approaches? 2003-March.txt:Subject: [Dillo-dev] Re: https approaches? 2003-November.txt:Subject: [Dillo-dev] Re: https dpi 2003-November.txt:Subject: [Dillo-dev] HTTPS Patch 2003-November.txt:Subject: [Dillo-dev] tabs, https, ... 2003-November.txt:Subject: [Dillo-dev] Small bug with combined frames/tabs/https patch and gcc 2.9x 2003-November.txt:Subject: [Dillo-dev] Small bug with combined frames/tabs/https patch 2003-November.txt:Subject: [Dillo-dev] [PATCH] HTTPS version 2. 2003-October.txt:Subject: [Dillo-dev] HTTPS patch 2003-October.txt:Subject: [Dillo-dev] HTTPS Patch 2004-February.txt:Subject: [Dillo-dev] Re: https dpi 2004-January.txt:Subject: [Dillo-dev] Re: https dpi 2004-July.txt:Subject: [Dillo-dev]https 2004-July.txt:Subject: [Dillo-dev]HTTPS 2004-July.txt:Subject: [Dillo-dev]Re: HTTPS 2004-July.txt:Subject: [Dillo-dev]dpip dialog for https (and dpis in general) 2004-July.txt:Subject: [Dillo-dev]https patch 2004-July.txt:Subject: [Dillo-dev]dpip dialog for https (and dpis in general) 2004-July.txt:Subject: [Dillo-dev]More https goodness 2004-July.txt:Subject: [Dillo-dev]Replying to lists (was: dpip dialog for https (and dpis in general)) 2004-July.txt:Subject: [Dillo-dev]More https goodness 2004-July.txt:Subject: [Dillo-dev]HTTPS certificate support 2004-July.txt:Subject: [Dillo-dev]HTTPS Cleanup 2004-June.txt:Subject: [Dillo-dev]https (eg for posting to ps2 bulletin boards) 2004-March.txt:Subject: [Dillo-dev]Re: https hungs dillo up... 2004-May.txt:Subject: [Dillo-dev]https (eg for posting to ps2 bulletin boards) 2004-November.txt:Subject: [Dillo-dev]https by lynx -source 2004-September.txt:Subject: [Dillo-dev]https 2005-February.txt:Subject: [Dillo-dev]testing https plugin gave problems 2005-January.txt:Subject: [Dillo-dev]https, ssl & certificates 2005-July.txt:Subject: [Dillo-dev]cookies dpi over https and dpi framework 2005-June.txt:Subject: [Dillo-dev]cookies dpi over https and dpi framework 2007-October.txt:Subject: [Dillo-dev] https and OpenBSD 2008-April.txt:Subject: [Dillo-dev] [PATCH]: Fixing https step 1: Have a basic dpi dialog 2008-April.txt:Subject: [Dillo-dev] [PATCH]: Fixing https step 1: Have a basic dpi 2008-April.txt:Subject: [Dillo-dev] [PATCH]: Fixing https step 1: Have a basic dpi dialog 2008-April.txt:Subject: [Dillo-dev] [PATCH]: Fixing https step 1: Have a basic dpi 2008-March.txt:Subject: [Dillo-dev] https plugin status 2008-March.txt:Subject: [Dillo-dev] [PATCH]: send the https dpi plugin debug messages to the 2008-March.txt:Subject: [Dillo-dev] https plugin status 2008-March.txt:Subject: [Dillo-dev] [PATCH]: Fixing https step 1: Have a basic dpi dialog 2008-March.txt:Subject: [Dillo-dev] [PATCH]: Fixing https step 1: Have a basic dpi 2008-March.txt:Subject: [Dillo-dev] [PATCH]: Fixing https step 1: Have a basic dpi dialog 2008-March.txt:Subject: [Dillo-dev] https plugin status 2008-March.txt:Subject: [Dillo-dev] [PATCH]: Fixing https step 1: Have a basic dpi 2008-March.txt:Subject: [Dillo-dev] https plugin status 2008-March.txt:Subject: [Dillo-dev] [PATCH]: Fixing https step 1: Have a basic dpi dialog 2008-March.txt:Subject: [Dillo-dev] https plugin status 2008-November.txt:Subject: [PATCH] Update the GPL version in the OpenSSL exception clause in dpi/https.c 2008-November.txt:Subject: [Dillo-dev] A warning about HTTPS and proxies 2008-October.txt:Subject: [PATCH] https: Improve the plugin warnings when SSL is disabled. 2008-October.txt:Subject: [Dillo-dev] https error handling 2008-October.txt:Subject: [PATCH] Update the GPL version in the OpenSSL exception clause in dpi/https.c 2009-July.txt:Subject: [Dillo-dev] [patch] check for dpip_tag == NULL in https.c 2009-June.txt:Subject: patch: Re: [Dillo-dev] https through a proxy 2009-May.txt:Subject: [Dillo-dev] https through a proxy 2009-May.txt:Subject: patch: Re: [Dillo-dev] https through a proxy 2010-January.txt:Subject: [Dillo-dev] experimental patch: gnutls for the https dpi 2010-October.txt:Subject: [Dillo-dev] Https remote certificate cannot be verified 2011-December.txt:Subject: [Dillo-dev] IPv6 and HTTPS (Re: release candidate for dillo-3.0.2) 2011-December.txt:Subject: [Dillo-dev] IPv6 and HTTPS (Re: release candidate for 2012-October.txt:Subject: [Dillo-dev] https unpleasantness 2013-February.txt:Subject: [Dillo-dev] https related crash 2013-March.txt:Subject: [Dillo-dev] https related crash Greetings Andreas Kemnade

Oct. 21, 2014

SSL in the browser

by eocene＠gmx.com

Jorge wrote: > Oh, as our mailsearch doesn't work anymore, is there > and URL to the original thread (Gmane style) or something? > > I'd like to remember what the main point of having SSL inside > the browser were. I'm getting old. ;) Looking briefly, I couldn't find relevant discussion. Possibly it was off list. My recollection is that, at the time, it had to do with seeing how SSL was becoming more and more central to browsing with things like 'HTTPS Everywhere' and 'HTTP Strict Transport Security' coming along and the issue of privacy gaining increasing public awareness. As for this effort now, I started just by wondering what it would look like if I integrated Benjamin's code and took out the windows stuff. It was working pretty well very quickly. And now I like how much more respectful of servers and resources Dillo can be when HTTPS is integrated with the http_max_conns queuing and http_persistent_conns. I think Johannes mentioned something about Dillo and Tor not working together so well with HTTPS in a dpi, but I don't know the details there.

Oct. 21, 2014

SSL in the browser

by jcid＠dillo.org

Hi corvid, On Mon, Oct 20, 2014 at 11:47:35PM +0000, eocene wrote: > I wrote: > > http://www.dillo.org/test/ssl_in_browser.diff > > Fixed a couple of bugs, added a couple of features, new version up. Oh, as our mailsearch doesn't work anymore, is there and URL to the original thread (Gmane style) or something? I'd like to remember what the main point of having SSL inside the browser were. I'm getting old. ;) -- Cheers Jorge.-

Oct. 21, 2014

SSL in the browser

by eocene＠gmx.com

I wrote: > http://www.dillo.org/test/ssl_in_browser.diff Fixed a couple of bugs, added a couple of features, new version up.

Oct. 20, 2014

SSL in the browser

by eocene＠gmx.com

I wrote: > My code for SSL in the browser hasn't been giving me any problems in > recent days, so it would be nice to give it some wider use. > > http://www.dillo.org/test/ssl_in_browser.diff Found a bug :( Fixed it :) New version up.

Oct. 14, 2014

SSL in the browser

by eocene＠gmx.com

My code for SSL in the browser hasn't been giving me any problems in recent days, so it would be nice to give it some wider use. http://www.dillo.org/test/ssl_in_browser.diff

Oct. 13, 2014

subscripts and superscripts

by dennisn＠dennisn.linuxd.org

Multi-level subscripts or superscripts don't render properly -- it only renders the first level. Eg: 2<sup>2<sup>2</sup></sup> Will appear as 2^22 instead of 2^2^2 :p.

Sept. 27, 2014

Dillo and Irix

by eocene＠gmx.com

On IRIX, dpid starts but use of the dpis fails with "Dpi_get_server_port: can't read server port from dpid." Jorge, do you have any time to look into that?

Sept. 24, 2014

background images and --local/URL_SpamSafe

by Johannes.Hofmann＠gmx.de

On Sun, Sep 21, 2014 at 05:22:42PM +0000, eocene wrote: > > It looks like --local/URL_SpamSafe doesn't have any effect on > background images. Should be fixed now. Please give it a try. Cheers, Johannes

Sept. 23, 2014

background images and --local/URL_SpamSafe

by eocene＠gmx.com

It looks like --local/URL_SpamSafe doesn't have any effect on background images.

Sept. 21, 2014

Dillo and Irix

by csoren＠isd.net

I stand corrected! 0_o Thanks guys... :) > > The gcc on my machine is the nekoware gcc 4.7.1 > compiled by shadeofblue. It is the standard gcc > for Irix currently. If __sgi is true it is really > a SGI system. > > > > > eocene wrote: > > > > > > > > Chris wrote: > > > #if defined(__sgi) > > > > > > This will work with the MIPSPro compiler but > > > I'm pretty sure the GNU compilers do not > > > #define __sgi > > > > > > > On Jan's machine, > > > > ./cpp --version > > cpp (GCC) 4.7.1 > > > > ./cpp -dM |grep __sgi > > #define __sgi 1 > > #define __sgi__ 1 > >

Sept. 19, 2014

Dillo and Irix

by diegel＠work.de

The gcc on my machine is the nekoware gcc 4.7.1 compiled by shadeofblue. It is the standard gcc for Irix currently. If __sgi is true it is really a SGI system. eocene wrote: > Chris wrote: >>>> #if defined(__sgi) >>>> >> This will work with the MIPSPro compiler but I'm pretty sure >> the GNU compilers do not #define __sgi > > On Jan's machine, > > ./cpp --version > cpp (GCC) 4.7.1 > > ./cpp -dM |grep __sgi > #define __sgi 1 > #define __sgi__ 1 > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > > -- Jan Diegelmann email: diegel at work.de fon: +49 40 238 809 15 fax: +49 40 238 809 29 http://www.work.de : n at work Internet Informationssyteme GmbH Wandalenweg 5, 20097 Hamburg, Germany HR B 61668 - Amtsgericht Hamburg Gesch?ftsf?hrer: Jan Diegelmann

Sept. 19, 2014

Dillo and Irix

by eocene＠gmx.com

Chris wrote: > > > > > > #if defined(__sgi) > > > > > This will work with the MIPSPro compiler but I'm pretty sure > the GNU compilers do not #define __sgi On Jan's machine, ./cpp --version cpp (GCC) 4.7.1 ./cpp -dM |grep __sgi #define __sgi 1 #define __sgi__ 1

Sept. 19, 2014

Dillo and Irix

by csoren＠isd.net

> > > > #if defined(__sgi) > > This will work with the MIPSPro compiler but I'm pretty sure the GNU compilers do not #define __sgi

Sept. 19, 2014

Dillo and Irix

by jcid＠dillo.org

On Fri, Sep 19, 2014 at 03:00:01AM +0000, eocene wrote: > > Having thought about it probably too much over the past however many days, > I haven't thought of a good reason not to stick it all in an ifdef like > > #if defined(__sgi) > /* IRIX does not conform to C99; if the entire argument did not fit > * into the buffer, n = buffer space used (minus 1 for terminator) > */ > if (n > -1 && n + 1 < ds->sz - ds->len) { > ds->len += n; /* Success! */ > break; > } else { > n_sz = ds->sz * 2; > } > #else > if (n > -1 && n < ds->sz - ds->len) { > ds->len += n; /* Success! */ > break; > } else if (n > -1) { /* glibc >= 2.1 */ > n_sz = ds->len + n + 1; > } else { /* old glibc */ > n_sz = ds->sz * 2; > } > #endif > > and be done with it. Fair enough, and IMHO simpler than my proposal. +1 -- Cheers Jorge.-

Sept. 19, 2014

Dillo and Irix

by eocene＠gmx.com

Having thought about it probably too much over the past however many days, I haven't thought of a good reason not to stick it all in an ifdef like #if defined(__sgi) /* IRIX does not conform to C99; if the entire argument did not fit * into the buffer, n = buffer space used (minus 1 for terminator) */ if (n > -1 && n + 1 < ds->sz - ds->len) { ds->len += n; /* Success! */ break; } else { n_sz = ds->sz * 2; } #else if (n > -1 && n < ds->sz - ds->len) { ds->len += n; /* Success! */ break; } else if (n > -1) { /* glibc >= 2.1 */ n_sz = ds->len + n + 1; } else { /* old glibc */ n_sz = ds->sz * 2; } #endif and be done with it.

Sept. 19, 2014

Dillo and Irix

by jcid＠dillo.org

On Thu, Sep 18, 2014 at 12:44:33PM -0300, Jorge Arellano Cid wrote: > On Tue, Sep 16, 2014 at 06:29:27AM +0000, eocene wrote: > > > > In the typical vsnprintf() (i.e., following the c99 standard), if you > > have space for 10 bytes and you want to write 20 bytes (including '\0'), > > you return 19, whereas irix returns 9. > > > > Some options: > > > > 1. It's possible to make irix and the standard run with a change like > > > > diff -r 5f63e28334b2 dlib/dlib.c > > --- a/dlib/dlib.c Tue Sep 16 00:21:49 2014 +0000 > > +++ b/dlib/dlib.c Tue Sep 16 04:59:20 2014 +0000 > > @@ -406,11 +406,11 @@ > > va_copy(argp2, argp); > > n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp2); > > va_end(argp2); > > - if (n > -1 && n < ds->sz - ds->len) { > > + if (n > -1 && n+1 < ds->sz - ds->len) { > > ds->len += n; /* Success! */ > > break; > > } else if (n > -1) { /* glibc >= 2.1 */ > > - n_sz = ds->len + n + 1; > > + n_sz = ds->len + n + 2; > > } else { /* old glibc */ > > n_sz = ds->sz * 2; > > } > > > > ...although it would need tweaking to waste less running time. > > > > But of course even if dillo is partly about retrocomputing, it'll be > > 99% linux+bsd retrocomputing and 1% other-stuff retrocomputing, so... > > > > 2. Throw an ifdef at it. Dillo has never had many ifdefs, and I'd thought > > they were discouraged, but maybe the changes needed for all of that stuff > > at the bottom of Compatibility.html like > > > > SGI O2 running IRIX > > Tru64 (OSF1) 4.0 on Alpha > > QNX RTP 6.1/x86 (with occasional memory faults out of GTK+) > > AIX 4.3 (with some tweaks) > > Atari-based 68k-systems running MiNT > > Microsoft Windows using Cygwin > > RISC OS > > > > ...just didn't make it back into mainline dillo1? > > > > 3. We could always borrow fltk's vsnprintf(), which is about 250 lines. > > > > > > I lean toward giving it an ifdef. > > > Me too, it clearly is an IRIX issue and the #ifdef would make it > cristal clear (compared to a soln. using fltk's vsnprintf() for > instance). > > +1 A bit more elaboration: I'd add an my_vsnprintf() in dlibc and make dStr_vsprintfa() use it, and make it like: my_vsnprintf() { #if IRIX /* compute required length by using IRIX's rules */ #else /* use vsnprintf(), no problem */ #fi } To avoid autoconf, the IRIX test can be placed in the same function with a static int: static int IRIX = -1; if (IRIX == -1) { /* very simple snprintf() test here */ IRIX = test ? 1 : 0; } -- Cheers Jorge.-

Sept. 18, 2014

Dillo and Irix

by jcid＠dillo.org

On Tue, Sep 16, 2014 at 06:29:27AM +0000, eocene wrote: > > In the typical vsnprintf() (i.e., following the c99 standard), if you > have space for 10 bytes and you want to write 20 bytes (including '\0'), > you return 19, whereas irix returns 9. > > Some options: > > 1. It's possible to make irix and the standard run with a change like > > diff -r 5f63e28334b2 dlib/dlib.c > --- a/dlib/dlib.c Tue Sep 16 00:21:49 2014 +0000 > +++ b/dlib/dlib.c Tue Sep 16 04:59:20 2014 +0000 > @@ -406,11 +406,11 @@ > va_copy(argp2, argp); > n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp2); > va_end(argp2); > - if (n > -1 && n < ds->sz - ds->len) { > + if (n > -1 && n+1 < ds->sz - ds->len) { > ds->len += n; /* Success! */ > break; > } else if (n > -1) { /* glibc >= 2.1 */ > - n_sz = ds->len + n + 1; > + n_sz = ds->len + n + 2; > } else { /* old glibc */ > n_sz = ds->sz * 2; > } > > ...although it would need tweaking to waste less running time. > > But of course even if dillo is partly about retrocomputing, it'll be > 99% linux+bsd retrocomputing and 1% other-stuff retrocomputing, so... > > 2. Throw an ifdef at it. Dillo has never had many ifdefs, and I'd thought > they were discouraged, but maybe the changes needed for all of that stuff > at the bottom of Compatibility.html like > > SGI O2 running IRIX > Tru64 (OSF1) 4.0 on Alpha > QNX RTP 6.1/x86 (with occasional memory faults out of GTK+) > AIX 4.3 (with some tweaks) > Atari-based 68k-systems running MiNT > Microsoft Windows using Cygwin > RISC OS > > ...just didn't make it back into mainline dillo1? > > 3. We could always borrow fltk's vsnprintf(), which is about 250 lines. > > > I lean toward giving it an ifdef. Me too, it clearly is an IRIX issue and the #ifdef would make it cristal clear (compared to a soln. using fltk's vsnprintf() for instance). +1 -- Cheers Jorge.-

Sept. 18, 2014

Problems tackling a bug

by sgeerken＠dillo.org

Hi! FYI: For mysterious reasons, I was now able to reproduce this bug with "-O0" in gdb, so a fix was not so difficult anymore and is now in the main repository. Nevertheless, thanks for your help. Sebastian PS: (i) "-O1" still showed too much <optimized out>, and (ii) valgrind did not help, either.

Sept. 17, 2014

Dillo and Irix

by Johannes.Hofmann＠gmx.de

On Tue, Sep 16, 2014 at 05:49:26PM +0000, eocene wrote: > Johannes wrote: > > I would suggest testing for this specific (v)snprintf() behaviour in > > configure and ifdef based on the result rather than on the OS. > > I thought about that, and between > - it sounding like Irix == this behaviour > and > - relearning enough about autoconf to do anything is always somewhere > between unpleasant and painful > I felt disinclined, but I could give it some effort. > > > There might even be some builtin support for this check in autoconf > > as the issue is mentioned in [1]. > > I looked a bit yesterday and didn't get the impression that there > was anything. AX_FUNC_SNPRINTF might help. It worked on my system after I installed an autoconf-archive package. Here is some documentation: http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m… I think it will define PREFER_PORTABLE_SNPRINTF in config.h in case it detects a broken (v)snprintf().

Sept. 16, 2014

Dillo and Irix

by csoren＠isd.net

> > > > There might even be some builtin support for this check > > in autoconf as the issue is mentioned in [1]. > > > > I looked a bit yesterday and didn't get the impression > that there was anything. > There is an autoconf m4 macro for snprintf, with some IRIX specific checks, here: http://www.jhweiss.de/software/snprintf.html According to that page versions of IRIX all the way up to the present (6.5.30) don't adhere to the standard. For what it's worth this is the IRIX online manual page for snprintf(): http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fna…

Sept. 16, 2014

Browser tracking

by eocene＠gmx.com

James wrote: > If we implement configurable user-agents, will we start getting code > optimised for other people, which we can't run? There is the http_user_agent preference in dillorc. As for getting pages shaped for others, yes. If you're curious, I suppose you could check the Vary header in the HTTP response and see how often User-Agent is included there.

Sept. 16, 2014

Dillo and Irix

by eocene＠gmx.com

Johannes wrote: > I would suggest testing for this specific (v)snprintf() behaviour in > configure and ifdef based on the result rather than on the OS. I thought about that, and between - it sounding like Irix == this behaviour and - relearning enough about autoconf to do anything is always somewhere between unpleasant and painful I felt disinclined, but I could give it some effort. > There might even be some builtin support for this check in autoconf > as the issue is mentioned in [1]. I looked a bit yesterday and didn't get the impression that there was anything.

Sept. 16, 2014

Dillo and Irix

by eocene＠gmx.com

Jan wrote: > eocene wrote: > > >1. It's possible to make irix and the standard run with a change like > > dilo 3.0.4 works fine with your pach on Irix. Thank you very much > for your help! It would also be nice to deal with the other issues if possible. - You said you had to comment out a setenv, iirc? - I had to fix up src/Makefile in a small way which maybe could be avoided.

Sept. 16, 2014

Browser tracking

by james.from.wellington＠gmail.com

The browser on my not-incredibly-old ipod touch returned as unique, so people who run that configuration apparently have not found this site. Dillo currently returns one-in-~85000, with the user-agent being the lion's share of that. If we implement configurable user-agents, will we start getting code optimised for other people, which we can't run? On 9/10/14, eocene <eocene at gmx.com> wrote: > Jorge wrote: >> This site is interesting. It gives kind of a score of web browser >> trackability. [1] >> >> @corvid, I thought you'd like to give it a look (AFAIR, you have >> submitted >> some standardizing to our HTTP querying in the past). It looks like >> our HTTP_ACCEPT and "User Agent" are the most vulnerable to tracking. >> >> It looks simple to provide some less unique alternatives in dillorc. > > Yes, this site was part of the impetus to work on the headers in March to > make dillo resemble firefox more closely, and add deflate decompression > and add keepalive. > > User-agent is a little misleading in that I have a current firefox > user-agent string, and panopticlick says that's one in 2701.57 browsers, > but no doubt it's rather more common among the visitors in > September 2014 specifically. > > Somewhat related, I've been working on SSL in the browser, and > https://www.ssllabs.com/ssltest/viewMyClient.html > shows some more ways for browsers to reveal what they are. > >> DISCLAIMER: this is just on little aspect of the privacy chain. >> Most probably this is moot unless you're behind a TOR ring. YMMV. > > Indeed. > >> >> [1] https://panopticlick.eff.org/ > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 16, 2014

Patch: suppress duplicate Fl_Printer::class_id

by james.from.wellington＠gmail.com

Removing the stub on OSX 10.6.8 with fltk 1.3.2 does not make dillo grow. Sizes of dillo image; the first line counts shared libraries, and the second overestimates, perhaps consistently, the size of the to-run code: - with Fl_Printer stub without class_id: $ otool -L src/dillo | wc 14 92 1370 $ ls -l src/dillo -rwxr-xr-x 1 ... staff 2407760 15 Sep 21:21 src/dillo - without Fl_Printer stub: $ otool -L src/dillo | wc 14 92 1370 $ ls -l src/dillo -rwxr-xr-x 1 ... staff 2407760 17 Sep 00:05 src/dillo If it's purpose has been overtaken by events, and it increases the brittleness of the code, then I would be happy for it to be removed. On 9/16/14, eocene <eocene at gmx.com> wrote: > James wrote: >> Building commit 317f010 (two days ago) of dillo, I got a duplicate >> symbol on OSX 10.6.8 with gcc 4.2.1. Here is the diff that suppresses >> it. >> >> ---------------- >> $ hg diff >> diff -r c09473fb7311 dw/fltkplatform.cc >> --- a/dw/fltkplatform.cc Sat Sep 13 09:46:28 2014 +0000 >> +++ b/dw/fltkplatform.cc Sat Sep 13 23:49:26 2014 +1200 >> @@ -37,10 +37,10 @@ >> * any need for currently. This stub prevents that. */ >> class FL_EXPORT Fl_Printer : public Fl_Paged_Device { >> public: >> - static const char *class_id; >> +// static const char *class_id; >> Fl_Printer(void) {}; >> }; >> -const char *Fl_Printer::class_id = "Fl_Printer"; >> +//const char *Fl_Printer::class_id = "Fl_Printer"; > > To refresh my memory of the magnitude of what printer stuff we pull in > without the stub, I commented out the stub -- and saw nothing to do with > Fl_Printer with nm. > > I thought maybe this somehow had to do with the changes that Lauri Kasanen > made to fltk last month like > http://www.fltk.org/newsgroups.php?s10767+gfltk.commit+v10781 > http://www.fltk.org/newsgroups.php?s10787+gfltk.commit+v10787 > but I see that Manolo took out the Fl_Printer::class_id check in > Fl_Text_Display in March 2012. 1.3.2 came out in...let's see... > December 2012. > > So we should probably remove the stub altogether. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 16, 2014

Dillo and Irix

by johannes.hofmann＠gmx.de

On Tue, Sep 16, 2014 at 06:29:27AM +0000, eocene wrote: > > In the typical vsnprintf() (i.e., following the c99 standard), if you > have space for 10 bytes and you want to write 20 bytes (including '\0'), > you return 19, whereas irix returns 9. > > Some options: > > 1. It's possible to make irix and the standard run with a change like > > diff -r 5f63e28334b2 dlib/dlib.c > --- a/dlib/dlib.c Tue Sep 16 00:21:49 2014 +0000 > +++ b/dlib/dlib.c Tue Sep 16 04:59:20 2014 +0000 > @@ -406,11 +406,11 @@ > va_copy(argp2, argp); > n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp2); > va_end(argp2); > - if (n > -1 && n < ds->sz - ds->len) { > + if (n > -1 && n+1 < ds->sz - ds->len) { > ds->len += n; /* Success! */ > break; > } else if (n > -1) { /* glibc >= 2.1 */ > - n_sz = ds->len + n + 1; > + n_sz = ds->len + n + 2; > } else { /* old glibc */ > n_sz = ds->sz * 2; > } > > ...although it would need tweaking to waste less running time. > > But of course even if dillo is partly about retrocomputing, it'll be > 99% linux+bsd retrocomputing and 1% other-stuff retrocomputing, so... > > 2. Throw an ifdef at it. Dillo has never had many ifdefs, and I'd thought > they were discouraged, but maybe the changes needed for all of that stuff > at the bottom of Compatibility.html like > > SGI O2 running IRIX > Tru64 (OSF1) 4.0 on Alpha > QNX RTP 6.1/x86 (with occasional memory faults out of GTK+) > AIX 4.3 (with some tweaks) > Atari-based 68k-systems running MiNT > Microsoft Windows using Cygwin > RISC OS > > ...just didn't make it back into mainline dillo1? > > 3. We could always borrow fltk's vsnprintf(), which is about 250 lines. > > > I lean toward giving it an ifdef. I would suggest testing for this specific (v)snprintf() behaviour in configure and ifdef based on the result rather than on the OS. There might even be some builtin support for this check in autoconf as the issue is mentioned in [1]. Johannes [1] https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Functi…

Sept. 16, 2014

Dillo and Irix

by diegel＠work.de

eocene wrote: > 1. It's possible to make irix and the standard run with a change like dilo 3.0.4 works fine with your pach on Irix. Thank you very much for your help! > I lean toward giving it an ifdef. I would also be happy to maintain a patch for Irix dillo. In this case you should make some notes in the README file.

Sept. 16, 2014

Dillo and Irix

by eocene＠gmx.com

In the typical vsnprintf() (i.e., following the c99 standard), if you have space for 10 bytes and you want to write 20 bytes (including '\0'), you return 19, whereas irix returns 9. Some options: 1. It's possible to make irix and the standard run with a change like diff -r 5f63e28334b2 dlib/dlib.c --- a/dlib/dlib.c Tue Sep 16 00:21:49 2014 +0000 +++ b/dlib/dlib.c Tue Sep 16 04:59:20 2014 +0000 @@ -406,11 +406,11 @@ va_copy(argp2, argp); n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp2); va_end(argp2); - if (n > -1 && n < ds->sz - ds->len) { + if (n > -1 && n+1 < ds->sz - ds->len) { ds->len += n; /* Success! */ break; } else if (n > -1) { /* glibc >= 2.1 */ - n_sz = ds->len + n + 1; + n_sz = ds->len + n + 2; } else { /* old glibc */ n_sz = ds->sz * 2; } ...although it would need tweaking to waste less running time. But of course even if dillo is partly about retrocomputing, it'll be 99% linux+bsd retrocomputing and 1% other-stuff retrocomputing, so... 2. Throw an ifdef at it. Dillo has never had many ifdefs, and I'd thought they were discouraged, but maybe the changes needed for all of that stuff at the bottom of Compatibility.html like SGI O2 running IRIX Tru64 (OSF1) 4.0 on Alpha QNX RTP 6.1/x86 (with occasional memory faults out of GTK+) AIX 4.3 (with some tweaks) Atari-based 68k-systems running MiNT Microsoft Windows using Cygwin RISC OS ...just didn't make it back into mainline dillo1? 3. We could always borrow fltk's vsnprintf(), which is about 250 lines. I lean toward giving it an ifdef. -------------- Extra verbiage: Autoconf's manual says: The C99 standard says that if the output array isn't big enough and if no other errors occur, snprintf and vsnprintf truncate the output and return the number of bytes that ought to have been produced. Some older systems return the truncated length (e.g., GNU C Library 2.0.x or IRIX 6.5), some a negative value (e.g., earlier GNU C Library versions), and some the buffer length without truncation (e.g., 32-bit Solaris 7). Also, some buggy older systems ignore the length and overrun the buffer (e.g., 64-bit Solaris 7). glibc-2.1: 1999 solaris 7: 1998 irix 6.5: major release 1998 regular minor releases until 2005 "The last version of IRIX was 6.5.30, released in August 2006."

Sept. 16, 2014

dillo crash when dpid missing and view source used

by james.from.wellington＠gmail.com

Confirming this on OSX 10.6.8. Chmod a-x dipd is enough to exercise the fault. Here's a gdb backtrace where only html.cc is hacked, and it seems not to be relevant: --------------- (gdb) run Starting program: /Users/jamescone/buildTrees/dillo/versions/render/dillo-jfw01/src/dillo Reading symbols for shared libraries .+++++++++++++................................................................................ done Error in re-setting breakpoint 1: Function "main" not defined. paths: Cannot open file '/Users/jamescone/.dillo/keysrc': No such file or directory paths: Cannot open file '/usr/local/etc/dillo/keysrc': No such file or directory paths: Using internal defaults... Domain: Default accept. dillo_dns_init: Here we go! (threaded) Reading symbols for shared libraries . done Enabling cookies as from cookiesrc... Reading symbols for shared libraries . done ** WARNING **: preferred serif font "DejaVu Serif" not found. ** WARNING **: preferred monospace font "DejaVu Sans Mono" not found. ** WARNING **: preferred cursive font "URW Chancery L" not found. ** WARNING **: preferred fantasy font "DejaVu Sans" not found. Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Nav_open_url: new url='about:splash' a_Dicache_cleanup: length = 0 Nav_open_url: new url='dpi:/vsource/:about:splash' ** ERROR **: [Dpi_read_comm_keys] No such file or directory Dpi_start_dpid (child): Permission denied Dpi_start_dpid: can't start dpid ** ERROR **: dpi.c: can't start dpi daemon [dpid]: terminated normally (1) Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008 0x000000010001823d in a_Chain_check (FuncStr=0x1001013a0 "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:192 192 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { (gdb) bt #0 0x000000010001823d in a_Chain_check (FuncStr=0x1001013a0 "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:192 #1 0x0000000100021137 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x101914780, Data2=0x0) at capi.c:623 #2 0x0000000100021026 in a_Capi_dpi_send_data (url=0x0, bw=0x100550fa0, data=0x10192ee90 "<cmd='start_send_page' url='dpi:/vsource/:about:splash' data_size='9560' '>", data_sz=75, server=0x10010126b "vsource", flags=0) at capi.c:577 #3 0x00000001000210b3 in a_Capi_dpi_send_cmd (url=0x0, bw=0x100550fa0, cmd=0x10192ee90 "<cmd='start_send_page' url='dpi:/vsource/:about:splash' data_size='9560' '>", server=0x10010126b "vsource", flags=0) at capi.c:594 #4 0x00000001000208f9 in Capi_dpi_send_source (bw=0x100550fa0, url=0x100553e60) at capi.c:361 #5 0x0000000100020cd5 in a_Capi_open_url (web=0x100553e10, Call=0, CbData=0x0) at capi.c:440 #6 0x000000010001aad0 in Nav_open_url (bw=0x100550fa0, url=0x100551dd0, requester=0x0, offset=0) at nav.c:235 #7 0x000000010001ae74 in a_Nav_push (bw=0x100550fa0, url=0x100551dd0, requester=0x0) at nav.c:355 #8 0x000000010000b64e in UIcmd_open_url_nbw (new_bw=0x100550fa0, url=0x100551dd0) at uicmd.cc:761 #9 0x000000010000cfa8 in a_UIcmd_open_url_nt (vbw=0x101e1fe10, url=0x100551dd0, focus=1) at uicmd.cc:792 #10 0x000000010000d111 in a_UIcmd_view_page_source (bw=0x101e1fe10, url=0x101e0e680) at uicmd.cc:1214 #11 0x00000001000473fa in Menu_view_page_source_cb (user_data=0x101e0e680) at menu.cc:160 #12 0x000000010004774c in Fl_Menu_Item::do_callback (this=0x10018c7c0, o=0x10018c7c0) at Fl_Menu_Item.H:375 #13 0x0000000100046dbe in Menu_popup_cb (data=0x10018c790) at menu.cc:333 #14 0x00000001000a7db9 in do_timer () at object.cc:384 #15 0x00007fff84799bb8 in __CFRunLoopRun () #16 0x00007fff84797d8f in CFRunLoopRunSpecific () #17 0x00007fff868d374e in RunCurrentEventLoopInMode () #18 0x00007fff868d34b1 in ReceiveNextEventCommon () #19 0x00007fff868d340c in BlockUntilNextEventMatchingListInMode () #20 0x00007fff88f5deb2 in _DPSNextEvent () #21 0x00007fff88f5d801 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #22 0x00000001000a84ff in do_queued_events () at object.cc:384 #23 0x00000001000aabeb in fl_mac_flush_and_wait () at object.cc:384 #24 0x00000001000aeaa7 in Fl::run () at object.cc:384 #25 0x00000001000049f7 in main (argc=1, argv=0x7fff5fbff440) at dillo.cc:584 Current language: auto; currently c (gdb) --------- On 9/16/14, eocene <eocene at gmx.com> wrote: > > ...it happens at least as far back as 3.0.4 release. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 16, 2014

dillo crash when dpid missing and view source used

by eocene＠gmx.com

...it happens at least as far back as 3.0.4 release.

Sept. 16, 2014

Patch: suppress duplicate Fl_Printer::class_id

by eocene＠gmx.com

James wrote: > Building commit 317f010 (two days ago) of dillo, I got a duplicate > symbol on OSX 10.6.8 with gcc 4.2.1. Here is the diff that suppresses > it. > > ---------------- > $ hg diff > diff -r c09473fb7311 dw/fltkplatform.cc > --- a/dw/fltkplatform.cc Sat Sep 13 09:46:28 2014 +0000 > +++ b/dw/fltkplatform.cc Sat Sep 13 23:49:26 2014 +1200 > @@ -37,10 +37,10 @@ > * any need for currently. This stub prevents that. */ > class FL_EXPORT Fl_Printer : public Fl_Paged_Device { > public: > - static const char *class_id; > +// static const char *class_id; > Fl_Printer(void) {}; > }; > -const char *Fl_Printer::class_id = "Fl_Printer"; > +//const char *Fl_Printer::class_id = "Fl_Printer"; To refresh my memory of the magnitude of what printer stuff we pull in without the stub, I commented out the stub -- and saw nothing to do with Fl_Printer with nm. I thought maybe this somehow had to do with the changes that Lauri Kasanen made to fltk last month like http://www.fltk.org/newsgroups.php?s10767+gfltk.commit+v10781 http://www.fltk.org/newsgroups.php?s10787+gfltk.commit+v10787 but I see that Manolo took out the Fl_Printer::class_id check in Fl_Text_Display in March 2012. 1.3.2 came out in...let's see... December 2012. So we should probably remove the stub altogether.

Sept. 15, 2014

Dillo and Irix

by eocene＠gmx.com

Back in April, I wrote: > I wrote: > > Jan wrote: > > > eocene wrote: > > > >Jan wrote: > > > >>Query: {GE} > > > >>a_IO_ccc : OpSend [1B] Info=10262f30 Flags=0 > > > > > > > >"GE" is the entire query? > > > > > > Yes exactly. Any idea? > > > > Can you watch what goes wrong in a_Http_make_query_str()? > > Between this and the file path thing, I wonder whether irix > doesn't like that va_list/va_copy/vsnprintf stuff in the dStr > code in dlib/dlib.c. It did turn out to be irix's idea of vsnprintf(). Modifying dStr_vsprintfa(), I browsed around for a few minutes without problems. Now to look into how to solve this properly...

Sept. 15, 2014

Implementing </div> closing <span>, and friends

by james.from.wellington＠gmail.com

Hello all, [Sorry if this is a dup; gmail may be playing tricks on me.] This page displays, with distortions, in dillo 3.0.4, but the image does not display after commit 317f010: https://medium.com/@verynicetweets/getting-out-of-the-house-is-so-hard-thes… A partially cleaned-up and stripped version is attached, where the comment block shows a suppression of the problem. The page is illegal: two unclosed <span>s interfere with a </div> and the following <div>. There is code around html.cc:1355, which is intended to implement heuristics to close unclosed tags but, in the cases where it is triggered, no tags are closed. Here is a patch which I think implements the intent of the heuristics: ----------------- $ hg diff diff -r 26378f85c4ea src/html.cc --- a/src/html.cc Sun Sep 14 09:56:22 2014 +0000 +++ b/src/html.cc Mon Sep 15 18:13:21 2014 +1200 @@ -1355,7 +1355,9 @@ i_SELECT = a_Html_tag_index("select"), i_TEXTAREA = a_Html_tag_index("textarea"); int w3c_mode = !prefs.w3c_plus_heuristics; - int stack_idx, tag_idx, matched = 0, expected = 0; + // TODO: If there was a clean way of never having a tag index zero, + // (it's currently <a>), then expected_idx could be prettier. + int stack_idx, tag_idx, matched = 0, expected_idx = -1, skipped = 0; TagInfo new_tag = Tags[new_idx]; /* Look for the candidate tag to close */ @@ -1368,26 +1370,42 @@ break; } else if (Tags[tag_idx].EndTag == 'O') { /* skip an optional tag */ + ++skipped; continue; } else if ((new_idx == i_BUTTON && html->InFlags & IN_BUTTON) || (new_idx == i_SELECT && html->InFlags & IN_SELECT) || (new_idx == i_TEXTAREA && html->InFlags & IN_TEXTAREA)) { /* let these elements close tags inside them */ + ++skipped; continue; } else if (w3c_mode || Tags[tag_idx].TagLevel >= new_tag.TagLevel) { /* this is the tag that should have been closed */ - expected = 1; - break; + /* skip it as if it were optional, but complain */ + ++skipped; + if (-1 == expected_idx) { + // ie this is the first thing we're unwinding + expected_idx = tag_idx; + } + continue; } } + // Either or both matched and expected_idx could now be set + + // TODO: decide whether to carry line numbers in the parser state stack, + // in order to report them here. + if (matched) { + if (-1 != expected_idx) { + BUG_MSG("Unexpected closing tag: </%s> -- expected </%s>", + new_tag.name, Tags[expected_idx].name); + } + Html_tag_cleanup_to_idx(html, stack_idx); - } else if (expected) { - BUG_MSG("Unexpected closing tag: </%s> -- expected </%s>.", - new_tag.name, Tags[tag_idx].name); } else { - BUG_MSG("Unexpected closing tag: </%s>.", new_tag.name); + BUG_MSG("Unexpected closing tag: </%s>" + " -- explored %d layer(s) and not closed.", + new_tag.name, skipped); } } ----------------- Closing tags that match no opening tag (I used </area>, which is illegal) do not cause catastrophic failure. So far, it has not broken on my usual workload. Gmail is noisy, so I wonder if something's going wrong there, but it looks fairly normal. I have no good idea what a general test suite for this code looks like. If someone wants to point me toward related tests, then I will think about extending them. Regards, James.

Sept. 15, 2014

dillo can't handle strings

by mail＠gabucino.hu

On Sep 12, 2014, at 5:18 AM, Gabor Berczi wrote: > > On Sep 11, 2014, at 11:09 PM, eocene wrote: > >> I'd be interested in either, although if the build/debug process >> has some >> important differences from what a linux user would be accustomed >> to, I >> might need a quick bit of orientation... > > I've sent you the login credentials. As for IRIX only Jan can help, > since my Octane's ethernet interface developed a buffer RAM fault. eocene couldn't figure out how to use remote X instead of Quartz (he knows only linux), any other takers? -- G

Sept. 14, 2014

Patch: suppress duplicate Fl_Printer::class_id

by james.from.wellington＠gmail.com

Hello All, Building commit 317f010 (two days ago) of dillo, I got a duplicate symbol on OSX 10.6.8 with gcc 4.2.1. Here is the diff that suppresses it. ---------------- $ hg diff diff -r c09473fb7311 dw/fltkplatform.cc --- a/dw/fltkplatform.cc Sat Sep 13 09:46:28 2014 +0000 +++ b/dw/fltkplatform.cc Sat Sep 13 23:49:26 2014 +1200 @@ -37,10 +37,10 @@ * any need for currently. This stub prevents that. */ class FL_EXPORT Fl_Printer : public Fl_Paged_Device { public: - static const char *class_id; +// static const char *class_id; Fl_Printer(void) {}; }; -const char *Fl_Printer::class_id = "Fl_Printer"; +//const char *Fl_Printer::class_id = "Fl_Printer"; /* Tooltips */ static Fl_Menu_Window *tt_window = NULL; --------------- I have no idea what it will turn out that I've broken. If having this as a pull request will help, then I will try to work out how. Regards, James.

Sept. 13, 2014

Problems tackling a bug

by horape＠compendium.com.ar

Maybe valgrind could help you. On Wed, Sep 10, 2014 at 02:28:12PM +0200, Sebastian Geerken wrote: > Hi! > > I noticed that the current tip of dillo hangs in most cases when > displaying <http://www.dillo.org/>. I succeeded to reproduce this bug > in gdb, but get many "<optimized out>" values. So I tried to reduce > optimization, but unfortunately had problems reproducing this bug: > > - "-O2" (standard): reproducable both stand-alone and in gdb; > - "-O1": reproducable stand-alone, but not in gdb; > - "-O0": not reproducable at all. > > Versions envolved: > > $ gcc --version > gcc (Debian 4.7.2-5) 4.7.2 > $ gdb --version > GNU gdb (GDB) 7.4.1-debian > > Any ideas? > > Sebastian > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev -- Horacio J. Pe?a horape at compendium.com.ar horape at uninet.edu

Sept. 13, 2014

dillo can't handle strings

by mail＠gabucino.hu

On Sep 11, 2014, at 11:09 PM, eocene wrote: > I'd be interested in either, although if the build/debug process > has some > important differences from what a linux user would be accustomed to, I > might need a quick bit of orientation... I've sent you the login credentials. As for IRIX only Jan can help, since my Octane's ethernet interface developed a buffer RAM fault. -- G

Sept. 12, 2014

dillo can't handle strings

by diegel＠work.de

eocene wrote: > Jan wrote: >> Gabor Berczi wrote: >>> I seldom dabble in the minefield called "C", even less so with unknown >>> large programs. If there are any takers, send me a mail and I'll give an >>> SSH login to the host. >>> >> If the is any interest I can offer the same for the failed Irix >> build as well. Probably an endianness problem? > > I'd be interested in either, although if the build/debug process has some > important differences from what a linux user would be accustomed to, I > might need a quick bit of orientation... > The build process is straight forward, nothing special. No serious patches, just compiling with gcc (4.7), no important warnings. Debugging is more complicated, since we don't have a working gdb with Irix. I will be unavailable from tomorrow to Saturday. I have some time on Sunday to set up a system with remote login. If Gabor is faster, you should go for OS X.

Sept. 11, 2014

dillo can't handle strings

by eocene＠gmx.com

Jan wrote: > Gabor Berczi wrote: > >I seldom dabble in the minefield called "C", even less so with unknown > >large programs. If there are any takers, send me a mail and I'll give an > >SSH login to the host. > > > If the is any interest I can offer the same for the failed Irix > build as well. Probably an endianness problem? I'd be interested in either, although if the build/debug process has some important differences from what a linux user would be accustomed to, I might need a quick bit of orientation...

Sept. 11, 2014

dillo can't handle strings

by diegel＠work.de

Gabor Berczi wrote: > > On Sep 11, 2014, at 10:04 PM, eocene wrote: > >> Gabor wrote: >>> See the issue on IRIX: >>> http://lists.dillo.org/pipermail/dillo-dev/2014-April/010079.html >>> Well, the same applies to PowerPC (OS X). >>> >>> "ftp://" works, "http://" doesn't. >>> >>> Somewhere there's a huge bug. Does anybody care? >> >> Since you have access to a machine where it breaks, and there's that >> mailing list thread to provide some leads, have you dug into the problem? > > I seldom dabble in the minefield called "C", even less so with unknown > large programs. If there are any takers, send me a mail and I'll give an > SSH login to the host. > If the is any interest I can offer the same for the failed Irix build as well. Probably an endianness problem?

Sept. 11, 2014

dillo can't handle strings

by mail＠gabucino.hu

On Sep 11, 2014, at 10:04 PM, eocene wrote: > Gabor wrote: >> See the issue on IRIX: http://lists.dillo.org/pipermail/dillo-dev/ >> 2014-April/010079.html >> Well, the same applies to PowerPC (OS X). >> >> "ftp://" works, "http://" doesn't. >> >> Somewhere there's a huge bug. Does anybody care? > > Since you have access to a machine where it breaks, and there's that > mailing list thread to provide some leads, have you dug into the > problem? I seldom dabble in the minefield called "C", even less so with unknown large programs. If there are any takers, send me a mail and I'll give an SSH login to the host. -- G

Sept. 11, 2014

dillo can't handle strings

by eocene＠gmx.com

Gabor wrote: > See the issue on IRIX: http://lists.dillo.org/pipermail/dillo-dev/2014-April/010079.html > Well, the same applies to PowerPC (OS X). > > "ftp://" works, "http://" doesn't. > > Somewhere there's a huge bug. Does anybody care? Since you have access to a machine where it breaks, and there's that mailing list thread to provide some leads, have you dug into the problem?

Sept. 11, 2014

dillo can't handle strings

by mail＠gabucino.hu

See the issue on IRIX: http://lists.dillo.org/pipermail/dillo-dev/ 2014-April/010079.html Well, the same applies to PowerPC (OS X). "ftp://" works, "http://" doesn't. Somewhere there's a huge bug. Does anybody care? -- G

Sept. 11, 2014

I'd like to add you to my professional network on LinkedIn

by acassis＠gmail.com

Sorry my mistake... On 9/11/14, Alan Carvalho de Assis <acassis at gmail.com> wrote: > Hi, > > I'd like to include you in my network to share updates and stay in > touch. > > - Alan > > Accept: > http://www.linkedin.com/blink?simpleRedirect=0Ue30PdjcNej0OdPgVe3sRcjARfkh9… > > > You are receiving Invitation emails. Unsubscribe here: > http://www.linkedin.com/blink?simpleRedirect=1DsCZ5cylLr6NFp30Q9npBp2RLr6NF… > > Learn why we included this at the following link: > http://www.linkedin.com/blink?simpleRedirect=3wUdPgZp4BBr6dFt79x9DhPpnlDnSl… > © 2014, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA > 94043, USA

Sept. 11, 2014

I'd like to add you to my professional network on LinkedIn

by acassis＠gmail.com

Hi, I'd like to include you in my network to share updates and stay in touch. - Alan Accept: http://www.linkedin.com/blink?simpleRedirect=0Ue30PdjcNej0OdPgVe3sRcjARfkh9… You are receiving Invitation emails. Unsubscribe here: http://www.linkedin.com/blink?simpleRedirect=1DsCZ5cylLr6NFp30Q9npBp2RLr6NF… Learn why we included this at the following link: http://www.linkedin.com/blink?simpleRedirect=3wUdPgZp4BBr6dFt79x9DhPpnlDnSl… © 2014, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA

Sept. 11, 2014

Problems tackling a bug

by james.from.wellington＠gmail.com

So it's probably a heissenbug, depending on the timing between two events. Options: - show us the bad backtrace in GDB, in case it rings a bell for someone - hang the -O1 code, send it SIGABRT to make it dump core, backtrace the core, and see if it's any better - someone who knows the code to guess what needs to be slowed down, to make it reliably reproduceable On 9/11/14, Sebastian Geerken <sgeerken at dillo.org> wrote: > On Mi, Sep 10, 2014, eocene at gmx.com wrote: >> Sebastian wrote: >> > I noticed that the current tip of dillo hangs in most cases when >> > displaying <http://www.dillo.org/>. I succeeded to reproduce this bug >> > in gdb, but get many "<optimized out>" values. So I tried to reduce >> > optimization, but unfortunately had problems reproducing this bug: >> > >> > - "-O2" (standard): reproducable both stand-alone and in gdb; >> > - "-O1": reproducable stand-alone, but not in gdb; >> > - "-O0": not reproducable at all. >> > >> > Versions envolved: >> > >> > $ gcc --version >> > gcc (Debian 4.7.2-5) 4.7.2 >> > $ gdb --version >> > GNU gdb (GDB) 7.4.1-debian >> > >> > Any ideas? >> >> I have the same gcc and gdb, and dillo doesn't seem to want to hang >> for me. Does it depend on your dillorc options? > > Removing ~/.dillo makes no difference. > > Neither does switching to other versions (gcc and g++ 4.4). > > Sebastian > >

Sept. 10, 2014

Problems tackling a bug

by sgeerken＠dillo.org

On Mi, Sep 10, 2014, eocene at gmx.com wrote: > Sebastian wrote: > > I noticed that the current tip of dillo hangs in most cases when > > displaying <http://www.dillo.org/>. I succeeded to reproduce this bug > > in gdb, but get many "<optimized out>" values. So I tried to reduce > > optimization, but unfortunately had problems reproducing this bug: > > > > - "-O2" (standard): reproducable both stand-alone and in gdb; > > - "-O1": reproducable stand-alone, but not in gdb; > > - "-O0": not reproducable at all. > > > > Versions envolved: > > > > $ gcc --version > > gcc (Debian 4.7.2-5) 4.7.2 > > $ gdb --version > > GNU gdb (GDB) 7.4.1-debian > > > > Any ideas? > > I have the same gcc and gdb, and dillo doesn't seem to want to hang > for me. Does it depend on your dillorc options? Removing ~/.dillo makes no difference. Neither does switching to other versions (gcc and g++ 4.4). Sebastian

Sept. 10, 2014

Problems tackling a bug

by eocene＠gmx.com

Sebastian wrote: > I noticed that the current tip of dillo hangs in most cases when > displaying <http://www.dillo.org/>. I succeeded to reproduce this bug > in gdb, but get many "<optimized out>" values. So I tried to reduce > optimization, but unfortunately had problems reproducing this bug: > > - "-O2" (standard): reproducable both stand-alone and in gdb; > - "-O1": reproducable stand-alone, but not in gdb; > - "-O0": not reproducable at all. > > Versions envolved: > > $ gcc --version > gcc (Debian 4.7.2-5) 4.7.2 > $ gdb --version > GNU gdb (GDB) 7.4.1-debian > > Any ideas? I have the same gcc and gdb, and dillo doesn't seem to want to hang for me. Does it depend on your dillorc options?

Sept. 10, 2014

Problems tackling a bug

by sgeerken＠dillo.org

Hi! I noticed that the current tip of dillo hangs in most cases when displaying <http://www.dillo.org/>. I succeeded to reproduce this bug in gdb, but get many "<optimized out>" values. So I tried to reduce optimization, but unfortunately had problems reproducing this bug: - "-O2" (standard): reproducable both stand-alone and in gdb; - "-O1": reproducable stand-alone, but not in gdb; - "-O0": not reproducable at all. Versions envolved: $ gcc --version gcc (Debian 4.7.2-5) 4.7.2 $ gdb --version GNU gdb (GDB) 7.4.1-debian Any ideas? Sebastian

Sept. 10, 2014