December 2003 - Dillo-dev - lists.mailman3.com

*BSD and gethostbyname

by Jorge Arellano Cid

Hi, Some *BSD don't provide a reentrant gethostbyname: <q source='manpage of a BSD'> BUGS These functions use static data storage; if the data is needed for future use, it should be copied before any subsequent calls overwrite it. Only the Internet address format is currently understood. </q> The only one I know that doesn't work is openBSD >= 3.3. (produces random lookups) Does anyone know the situation better? It is for disabling threaded dns lookups at configure time. Cheers Jorge.- PS: That's it. A thread follows with other minutiae... ---------- Forwarded message ---------- Date: Sat, 13 Dec 2003 14:26:58 +0100 (MET) From: Anders Gavare <md1gavan(a)mdstud.chalmers.se> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Re: [Dillo-dev] Re: BUG#494 On Sat, 13 Dec 2003, Jorge Arellano Cid wrote: > On Sat, 13 Dec 2003, Anders Gavare wrote: > > How typical: now I found this already mentioned in dillo's README file. > > Sorry to have bothered you. :-) Still, this is something that should > > be detected and taken care of by the configure script... > > Thanks for the info. > > Can you send me a patch for configure.in? Unfortunately I don't think I'm familiar enough with neither Dillo nor the configure system to add such a functionality. It took several days for me to track down the widget bug (#494), and several hours of testing to figure out this gethostbyname() bug. > Or at least the contents of the detected $target variable on > your machine (an extra line with "echo $target" after > AC_CANONICAL_SYSTEM will tell). sparc64-unknown-openbsd3.3 The same problem should exist in other BSDs as well, but I've not actually seen the symptoms. The manpages of FreeBSD 4.5 and NetBSD-current (after 1.6.1) have the following in their gethostbyname(3) manpages: BUGS These functions use static data storage; if the data is needed for future use, it should be copied before any subsequent calls overwrite it. Only the Internet address format is currently understood. Imho, if Dillo aims for platform independance, which is one of the things I like best about Dillo, this feature (multithreaded DNS lookups) would be better off disabled _unless_ the underlying platform explicitly allows it. Not the other way around. That's my opinion, anyway. Anders

Dec. 13, 2003

Re: [Dillo-dev] Re: BUG#494

by Anders Gavare

Replying to myself... On Sat, 13 Dec 2003, Anders Gavare wrote: > Dillo's dns lookups randomly stop working. gethostbyname() isn't > reentrant on OpenBSD 3.3/sparc64. (I believe that's what causing the > random bugs.) Undefining G_DNS_THREADED in src/dns.c solved the > symptoms here. How typical: now I found this already mentioned in dillo's README file. Sorry to have bothered you. :-) Still, this is something that should be detected and taken care of by the configure script... Anders

Dec. 13, 2003

Re: [Dillo-dev] Re: BUG#494

by Anders Gavare

On Wed, 10 Dec 2003, Jorge Arellano Cid wrote: > On Wed, 10 Dec 2003, Anders Gavare wrote: ... > > entry from the bug database. I've not had any other problems on sparc64 > > yet, except possible some random lock-ups. The version in CVS as of > > 07:00 this morning seems to work just fine (that is, it still has the > > random lock-ups but the output looks nice). > > lock-ups... Can you decribe them some more, or better, run > dillo under gdb to find out where or why it locks (I haven't > seen that bug ever). Dillo's dns lookups randomly stop working. gethostbyname() isn't reentrant on OpenBSD 3.3/sparc64. (I believe that's what causing the random bugs.) Undefining G_DNS_THREADED in src/dns.c solved the symptoms here. > PS: Are you on dillo-dev? No. Anders

Dec. 13, 2003

Re: [Dillo-dev] statically linked dillo

by Madis Janson

On Fri, 12 Dec 2003, Jorge Arellano Cid wrote: > > Hi, > > ---------- Forwarded message ---------- > Date: Thu, 11 Dec 2003 23:30:05 +0000 > From: Victor M. <voremo(a)safe-mail.net> > To: jcid(a)softhome.net > Subject: dillo > > Can dillo be compiled into a static, self-contained executable > to run under X? (.i.e. that it can be pressed on and run from > a publication CD, with no need for GTK libraries on the > target computer...?) > Victor > --------------------------------------- > > > Does anyone here know/done it? > > sure, why not? mzz@alien:/z/src/dillo/dillo/src$ gcc -o dillo-static chain.o commands.o cache.o capi.o doc.o dw.o dw_aligned_page.o dw_bullet.o dw_button.o dw_container.o dw_embed_gtk.o dw_ext_iterator.o dw_gtk_scrolled_frame.o dw_gtk_scrolled_window.o dw_gtk_statuslabel.o dw_gtk_viewport.o dw_hruler.o dw_image.o dw_list_item.o dw_marshal.o dw_page.o dw_style.o dw_table.o dw_table_cell.o dw_tooltip.o dw_widget.o gtkframeset.o findtext.o selection.o focus.o web.o pagemark.o progressbar.o dillo.o bookmark.o dicache.o dns.o gif.o jpeg.o png.o html.o image.o misc.o tab.o interface.o history.o nav.o plain.o menu.o prefs.o colors.o bitvec.o klist.o strbuf.o url.o cookies.o IO/libDio.a -lpthread /usr/lib/libpng.a /usr/lib/libjpeg.a /usr/lib/libz.a /usr/lib/libgtk.a /usr/lib/libgdk.a /usr/lib/libgmodule.a /usr/lib/libglib.a /usr/X11R6/lib/libXi.a /usr/X11R6/lib/libXext.a /usr/X11R6/lib/libX11.a /usr/lib/libm.a -ldl mzz@alien:/z/src/dillo/dillo/src$ strip --strip-all dillo-static mzz@alien:/z/src/dillo/dillo/src$ ldd dillo-static libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x4000e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x4001e000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40021000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x411c2000) mzz@alien:/z/src/dillo/dillo/src$ ls -la dillo-static -rwxr-xr-x 1 mzz mzz 2063896 2003-12-12 20:13 dillo-static the libc and dl were linked dynamically, because glibc tries to read some 'modules' and crashes, when these are not compatible with the glibc version (makeing it impossible to reliable run static-glibc linked program on other host or even after upgradeing libraries on the same machine).

Dec. 12, 2003

statically linked dillo

by Jorge Arellano Cid

Hi, ---------- Forwarded message ---------- Date: Thu, 11 Dec 2003 23:30:05 +0000 From: Victor M. <voremo(a)safe-mail.net> To: jcid(a)softhome.net Subject: dillo Can dillo be compiled into a static, self-contained executable to run under X? (.i.e. that it can be pressed on and run from a publication CD, with no need for GTK libraries on the target computer...?) Victor --------------------------------------- Does anyone here know/done it? Cheers Jorge.-

Dec. 12, 2003

[PATCH] I18N

by Kiyo

Hi. I made an I18N patch for Dillo. This is simple I18N. Japanese, Chinese, Korean, Greek, etc. Only LOCALE character are displayed. Not support "complicated languages". (such as Arabic) Internal code is mainly processing by UTF-8. UTF-8 wrapper of a part of APIs of GTK+1 is included. This wrapper will be unnecessary if Dillo ports to FLTK2 or GTK+2. But, I think that others will be probably needed. A part of this patch referred to Mr. Robert Thomson's Japanese patch. It is better to also gettextize. But, it has not applied to this patch. http://teki.jpn.ph/pc/software/dillo-cvs2003121203-i18n.diff.bz2 md5sum: 5a1e0428d0e049a081dd4721d48b1de2 and... For Core team, may not be desirable... This is large patch for Dillo-0.7.3 . I18N(UTF-8 support and gettext) Xft antialiasing(multibyte support) Setting Tool(gtk+) frame&tab(ver.10 with I18N fix) gzip compression transmission SearchBox UserAgent changer Referer meta-refresh SSL BASIC authorization Fix page scroll Character entity references(Probably almost is supported. but it's dependent on LOCALE.) and some various changes. Various persons' patches are unified and an original improvement is added. http://teki.jpn.ph/pc/software/dillo-0.7.3-i18n-misc-20031208.diff.bz2 md5sum: 0d3bdf88a3e61a4659e708ac4a971c1f #I'm hoping that both user and developer can become happy :-) --- Kiyo<kiyo(a)teki.jpn.ph> http://teki.jpn.ph/

Dec. 12, 2003

Re: [Dillo-dev] wanted: CPU overhead source.

by Jorge Arellano Cid

On Fri, 5 Dec 2003, Johannes Hofmann wrote: > Hi Jorge, > > On Thu, Dec 04, 2003 at 10:43:34AM -0300, Jorge Arellano Cid wrote: > > > > I could not yet get any reproducible results from profiling, > > > > !? > > > > Doesn't it show any function usage-ratio/run-time change? > > > > Ok, I redid the profiling on my slower Linux box with utilities.html. > > Html_cleanup_tag is called more often in cvs version (16742 vs. 10749) and > seems quite a bit slower than in 0.7.3. > > See gprof output below. > > Hope that helps, > Johannes > > PS: Of course I can send you the whole gprof output, but it is quite > large, so I did not want to send the whole thing to the list. > [...] Thanks a lot! Now it's clear where's the problem. I'll review it together with another parsing issue in a few days I hope. Cheers Jorge.-

Dec. 11, 2003

latest network patch

by Jorge Arellano Cid

Hi there! A network patch that covers several aspects was just commited: + Connected the dpi stream to the cache using the CCC! + Fixed the cache API by introducing the new call a_Capi_get_buf(). + Fixed a race condition and a multiple request problem. + Enabled the https dpi (it doesn't work yet, just a development version). + Removed a cpu-hog when the network is unreachable. Besides what's stated above, it has improved a bit the network experience (for instance on sites with lots of small images. For ex. newspapers). Please test it and tell me how it works. Anders: Please try it and tell us if it also produces the locks you've seen. Does 0.7.3 also lock? Ferdi: It has the proper bindings between the cache and dpi, so HTML served over FTP works, among others! Some https sites are also viewable... Madis: This patch has the framework to implement https in a similar way than the ssl gateway. The connection between dillo and the https dpi is done by the generic dpi handler. Note that although it may be easy to add the POST method using wget to the current https dpi (wget >= 1.9.x using --post-data and the DilloUrl), making a native https plugin (avoiding wget) as in the ssl gatway is preferred. This allows for a simple way to implement connection caching. The current https dpi is a filter, not a server as it should to implement it this way. This is also easy to do. Regards Jorge.-

Dec. 11, 2003

Re: [Dillo-dev] Re: BUG#494

by Jorge Arellano Cid

On Wed, 10 Dec 2003, Anders Gavare wrote: > On Tue, 9 Dec 2003, Jorge Arellano Cid wrote: > > > Hi, > > > > Some time ago I read this bug and now the CVS has a bunch of > > fixed for signed/unsigned conflicts that may cause trouble on > > 64bit machines. Please test our CVS and tell me if the bug > > persists. > > Once I found out what the problem was, I mailed Sebastian Geerken about > it. I think that was in September. > > http://cvs.auriga.wearlab.de/cgi-bin/cvsweb.cgi/dillo/dillo/src/dw_widget.c… > > That fixed the rendering bug. OK. > I'm sorry that I forgot to remove the > entry from the bug database. I've not had any other problems on sparc64 > yet, except possible some random lock-ups. The version in CVS as of > 07:00 this morning seems to work just fine (that is, it still has the > random lock-ups but the output looks nice). lock-ups... Can you decribe them some more, or better, run dillo under gdb to find out where or why it locks (I haven't seen that bug ever). > I use dillo daily. It is very neat, especially on non-i386 platforms. > Keep up the good work :-) Thanks. Cheers Jorge.- PS: Are you on dillo-dev?

Dec. 10, 2003

BUG#494

by Andrew A. Gill

Good Ol' Jorge wrote: > > Some time ago I read this bug and now the CVS has a bunch of > fixed for signed/unsigned conflicts that may cause trouble on > 64bit machines. Please test our CVS and tell me if the bug > persists. Alpha EV56 running gcc 3.3.2 (glibc 2.3.2) reports no errors yet, sir! In fact, Slashdot now seems to be readable, thanks to something in Dillo CVS (with old Dillo it's still unreadable). -- |Andrew A. Gill |I posted to Silent-Tristero and| |<superluser(a)frontiernet.net> |all I got was this stupid sig! | |alt.tv.simpsons CBG-FAQ author | | | (Report all obscene mail to Le Maitre Pots)| |Nothing here yet: <http://www.needsfoodbadly.com> Temporary sig: -- Full speed ahead!

Dec. 10, 2003