- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] freezing of dillo.0.7.0

by Jorge Arellano Cid

On Wed, 5 Mar 2003, robert w hall wrote: > In article <Pine.LNX.4.44.0303051147440.397-100000(a)infinity.cl>, Jorge > Arellano Cid <jcid(a)softhome.net> writes > > [...] > > Yes, the Linux kernel had a bug and it was fixed. > > > > Linux >= 2.4.9 => No problem. > no - see below > > > >> I originally compiled dillo0.6.6 against slack 7, kernel 2.4.5 (IIRC, or > >> even 2.2.18) with no problems. However dillo0.7.0 does freeze, > > NB > >even when > >> compiled against the headers for, and run under, kernel 2.4.19. > > so 2.4.19 + slack 7 + dillo 0.7.0 'ne marche pas' > > BUT it > >> compiles and runs ok when compiled under slack8.1, with the same headers > >> and kernel. > > There are more things in Heaven and Earth... Please test the latest CVS code and tell us how it goes. Cheers Jorge.-

March 6, 2003

Re: [Dillo-dev] More bugfixes

by Sebastian Geerken

On Tue, Mar 04, Jorge Arellano Cid wrote: > Sebastian: Please review BUG#424, Keith says it's a trivial fix. Yes, this is correct. Committed. > Ah, can anyone reproduce/not_reproduce bug 406? I can't. I've tried severals ways to circumvent the internationalization, but could not confirm this bug. Sebastian

March 5, 2003

Re: [Dillo-dev] freezing of dillo.0.7.0

by robert w hall

In article <Pine.LNX.4.44.0303051147440.397-100000(a)infinity.cl>, Jorge Arellano Cid <jcid(a)softhome.net> writes > > >On Thu, 27 Feb 2003, robert w hall wrote: > >> Is the description of the 'freezing' of dillo given in the README an >> uptodate description of the problem. This implies that it is a kernel >> version effect... > > Yes, the Linux kernel had a bug and it was fixed. > > Linux >= 2.4.9 => No problem. no - see below > >> I originally compiled dillo0.6.6 against slack 7, kernel 2.4.5 (IIRC, or >> even 2.2.18) with no problems. However dillo0.7.0 does freeze, NB >even when >> compiled against the headers for, and run under, kernel 2.4.19. so 2.4.19 + slack 7 + dillo 0.7.0 'ne marche pas' > BUT it >> compiles and runs ok when compiled under slack8.1, with the same headers >> and kernel. There are more things in Heaven and Earth... -- robert w hall

March 5, 2003

Alternative toolbar icons

by Jorge Arellano Cid

Hi there! I just updated the Icons page (the toolbar alternatives) (BUG#410). Go give it a look! Cheers Jorge.-

March 5, 2003

Re: a vulnerability in dillo

by Ivan Popov

Hello Jorge, thanks for your answer! On Wed, 5 Mar 2003, Jorge Arellano Cid wrote: > Probably (soon) socket file descriptors will reside in > /tmp/dillo and use temporary filenames, or something akin (this My first reaction is - who would be responsible for creating that /tmp/dillo? The first user? probably not. root at host startup? not a good idea to rely on the host admin to be able to run a program. May be something like /tmp/dillo-<truly-random-chars>/ per dillo instance, then you are rather safe against tampering but you have to make your bookmark server aware of possible parallel server accessing the same bookmarks. I would suggest not to rely on a common name all dillo instances of the same user would share. Then it would be 1. widely known and open to tampering 2. not working across different hosts anyway, as you need a server process per host, while bookmarks file may be shared between hosts. Just in case - I am glad you do not try to put sockets in/under homedirs. 1. the underlying filesystems may not support that 2. there is a hardcoded (in the specification) limit on the path name length of a unix socket - it breaks on some setups with homedirs deep in the filetree I mention it as it is a fairly often mistake of different software with unix sockets, to put sockets under the user's homedir. Best regards and thanks for dillo! -- Ivan

March 5, 2003

Re: [Dillo-dev] Re: hidden fields in forms broken?

by John Bradford

> > I've come across an apparent form anomaly when using dillo to test a > > separate application. > > > > If I create a html form, the data submitted differs depending on whether > > I use "text" or "hidden" input types -- specifically, the "hidden" type > > is not parsed for html entities. This causes breakage when I want to set > > the value to the four-character string x"'y, for example. > > > > The code for this is in html.c, around line 3077 (version 1.132), where > > just using the same "init_str = (value) ? value : NULL;" as most other > > types would work. > > > > >From the comment, it was clearly a deliberate decision to > > leave out entity-parsing for DILLO_HTML_INPUT_HIDDEN (and > > DILLO_HTML_INPUT_PASSWORD, around line 3049). The change appears to have > > been made between revisions 1.5 and 1.6, where the "submit" (and others) > > type explicitly had Html_parse_entities() called but the "hidden" type > > didn't. > > > > I don't see any dispensation in the HTML DTD which makes "hidden" and > > "password" immune to the entity rules. Is the exception in dillo an > > oversight that just hasn't been spotted yet? Or is there some reasoning > > that I'm missing behind the way things are? > > > > For reference, other web browsers I tried took the html fragment > > > > <form> > > <input type=text name=plain value="x"x"> > > <input type=hidden name=hide value="x"x"> > > <input type=submit> > > </form> > > > > and on submission, the URL had the same value for "plain" and "hide". > > In dillo, the query string is plain=x%22x&hide=x%26quot%3Bx > > This is quite an interesting issue! > > I digged through the historical releases and the root of the > problem is very far (before 0.3.2!). > > As I currently see it, the SGML type for those INPUT attribute > values is CDATA, so entities SHOULD/MUST be parsed!!! > > Does anyone know otherwise? I noticed problems with this when I was developing a web based regular expression editor, and thought it was a problem with my code, but checking with another browser, it seemed to be a Dillo bug. Also, note that Dillo breaks on code like this: <input type="hidden" name="foo" value="<b>bar</b>"> displaying "> when it shouldn't do. John.

March 5, 2003

Re: hidden fields in forms broken?

by Jorge Arellano Cid

Francis, > I've come across an apparent form anomaly when using dillo to test a > separate application. > > If I create a html form, the data submitted differs depending on whether > I use "text" or "hidden" input types -- specifically, the "hidden" type > is not parsed for html entities. This causes breakage when I want to set > the value to the four-character string x"'y, for example. > > The code for this is in html.c, around line 3077 (version 1.132), where > just using the same "init_str = (value) ? value : NULL;" as most other > types would work. > > >From the comment, it was clearly a deliberate decision to > leave out entity-parsing for DILLO_HTML_INPUT_HIDDEN (and > DILLO_HTML_INPUT_PASSWORD, around line 3049). The change appears to have > been made between revisions 1.5 and 1.6, where the "submit" (and others) > type explicitly had Html_parse_entities() called but the "hidden" type > didn't. > > I don't see any dispensation in the HTML DTD which makes "hidden" and > "password" immune to the entity rules. Is the exception in dillo an > oversight that just hasn't been spotted yet? Or is there some reasoning > that I'm missing behind the way things are? > > For reference, other web browsers I tried took the html fragment > > <form> > <input type=text name=plain value="x"x"> > <input type=hidden name=hide value="x"x"> > <input type=submit> > </form> > > and on submission, the URL had the same value for "plain" and "hide". > In dillo, the query string is plain=x%22x&hide=x%26quot%3Bx This is quite an interesting issue! I digged through the historical releases and the root of the problem is very far (before 0.3.2!). As I currently see it, the SGML type for those INPUT attribute values is CDATA, so entities SHOULD/MUST be parsed!!! Does anyone know otherwise? Cheers Jorge.-

March 5, 2003

Re: a vulnerability in dillo

by Jorge Arellano Cid

On Sun, 2 Mar 2003, Ivan Popov wrote: > Hello, > > having read the statement about dillo being a secure browser, It tries to be! > I want to draw your attention to the exploitable in different ways > bookmarks plugin interface. > > I submitted it as a bug and mentioned denial-of-service only, but creating > predictably named sockets in /tmp opens to other possible attacks > (e.g. spoofing your bookmarks) as well. > > I realize dillo and the plugins are evolving at fast rate, but this issue > can (and should?) be fixed even on the early stages of development. Probably (soon) socket file descriptors will reside in /tmp/dillo and use temporary filenames, or something akin (this also solves the problem of a pre-existent file with the same name). > Thanks for the great software! > I appreciate dillo - it is small, fast and functional. Thanks for your nice comments too. Cheers Jorge.-

March 5, 2003

Re: [Dillo-dev] freezing of dillo.0.7.0

by Jorge Arellano Cid

On Thu, 27 Feb 2003, robert w hall wrote: > Is the description of the 'freezing' of dillo given in the README an > uptodate description of the problem. This implies that it is a kernel > version effect... Yes, the Linux kernel had a bug and it was fixed. Linux >= 2.4.9 => No problem. > I originally compiled dillo0.6.6 against slack 7, kernel 2.4.5 (IIRC, or > even 2.2.18) with no problems. However dillo0.7.0 does freeze, even when > compiled against the headers for, and run under, kernel 2.4.19. BUT it > compiles and runs ok when compiled under slack8.1, with the same headers > and kernel. > Is this a gcc problem? (I'm using 2.91.66 with slack 7). It may be another kind of freeze! Please get the latest CVS and test it (dillo 0.7.0 freezes on Solaris because of another bug, but it's fixed on the CVS). I've used Slackware since 3.5 aprox. and never had problems with the default gcc. > (The suggested patch poll-fix-fast of course does not run in cleanly > against 0.7.0., and though the source compiles the executable still > freezes). Yes, it's quite a burden to maintain such patches, and the right fix is to upgrade the kernel. > Sorry if I've missed something on this. HTH, and as I said, it was probably another thing... Cheers Jorge.-

March 5, 2003

Re: [Dillo-dev] float implementation

by John Bradford

> I just want to announce the availability of my code to > fix bug #233 which concernes the rendering of > align=left and align=right tables. The patches and > screen shots are at > > http://home.earthlink.net/~crayne2 > > Feedback would be appreciated. :) It seems to have broken something - have a look at http://grabjohn.com The lists no longer have bullets. Also, at: http://kde.org If you use a small Dillo window, the links on the left can overlap the text to their right. For some reason, using FVWM2, maximising the Dillo window no longer makes it redraw with your patches. Having said all that, it does make some pages look a lot better. John.

March 5, 2003

float implementation

by Joe Crayne

I just want to announce the availability of my code to fix bug #233 which concernes the rendering of align=left and align=right tables. The patches and screen shots are at http://home.earthlink.net/~crayne2 Feedback would be appreciated. :)

March 5, 2003

Re: [Dillo-dev] More bugfixes

by Thorben Thuermer

On Tue, 4 Mar 2003 18:22:27 -0300 (CLST) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > Sebastian: Please review BUG#424, Keith says it's a trivial fix. for reference: BUG#: 424 Impact: soft error At: run time Type: memory leak Comments: Version 0.7.0 pixmap leak on resize. Dw_gtk_viewport_paint calls gdk_pixmap_ref instead of gdk_pixmap_unref. Fix is trivial. HTReproduce: Resize dillo repeatedly and note X server memory size increase WorkedBy: keithp(a)keithp.com this looks interesting. i noticed problems with *excessive* X resource leaks (=growth of the server's memory usage), and this might be a possible fix, i'm going to test that. diff -r1.22 dw_gtk_viewport.c 263c263 < gdk_pixmap_ref (viewport->back_pixmap); --- > gdk_pixmap_unref (viewport->back_pixmap); > Ah, can anyone reproduce/not_reproduce bug 406? i could never reproduce that... maybe you should ask people to at least include a gdb backtrace for crashes? Greetings, Thorben Thuermer

March 5, 2003

Re: [Dillo-dev] Question about dpi interface ...

by Thorben Thuermer

On Wed, 05 Mar 2003 10:07:59 +0100 Lars Segerlund <lars.segerlund(a)comsys.se> wrote: > > If I have dillo 0.7.0 with the bookmarks working through dpi, how can > I add dpi functionality ? > > Can I make a dpi server without modyfying the dillo binary ? you might want to read http://dillo.auriga.wearlab.de/dpi1.html for information on the dpi system. > / rgards, Lars Segerlund. Greetings, Thorben Thuermer

March 5, 2003

Question about dpi interface ...

by Lars Segerlund

If I have dillo 0.7.0 with the bookmarks working through dpi, how can I add dpi functionality ? Can I make a dpi server without modyfying the dillo binary ? / rgards, Lars Segerlund.

March 5, 2003

More bugfixes

by Jorge Arellano Cid

Hi there! I've been reviewing the bugtrack and receiving a lot of emails with regard to problems with solaris. There were several issues, some solved in CVS and others that escape our scope (Solaris is so inconsistent that some versions require certain libraries that others not, some fail, some work...) If someone has the patience to tweak configure.in to detect the different subversions of Solaris and add the magical options, I'd put it in. Just read the ChangeLog for a brief of the fixes. --------------------------------------------------- NOTE: There're lots of fixes, not just for Solaris. --------------------------------------------------- Please send me feedback about how it went. Sadly I just received _one_ mail report. Andreas: Please test the flock patch. It should work with *BSD as it defines flock(). Sebastian: Please review BUG#424, Keith says it's a trivial fix. Ah, can anyone reproduce/not_reproduce bug 406? Has anyone with a 64bit machine had NO trouble at all? :-) Cheers Jorge.-

March 4, 2003

Re: [Dillo-dev] Loosing bookmarks

by Sebastian Geerken

On Sat, Mar 01, Jorge Arellano Cid wrote: > The attached patch (against dillo-0.7.0) does five things: > [...] This patch is now in the CVS. Sebastian

March 2, 2003

Re: [Dillo-dev] BUGFIX set close_on_exec (FD_CLOEXEC)

by Raphael Barabas

On Sat, Mar 01, 2003 at 11:21:10PM +0100, Raphael Barabas wrote: > reason: > in IO.c, function IO_submit, filedescriptor-flag close_on_exec > is not set the right way (not at all). on solaris, as a direct > result, non-blocking io will accidentally be handled via > O_NDELAY instead of O_NONBLOCKING, resulting in an endless > loop. looks like i shot too fast. i forgot to grep the rest of the source for FD_CLOEXEC: IO/IO.c:533: O_NONBLOCK | FD_CLOEXEC | fcntl(r_io->FD, F_GETFL)); IO/http.c:267: O_NONBLOCK | FD_CLOEXEC | fcntl(S->SockFD, F_GETFL)); cookies.c:115: fcntl(fileno(F_in), F_SETFL, FD_CLOEXEC | fcntl(fileno(F_in), F_GETFL)); prefs.c:257: fcntl(fd, F_SETFL, FD_CLOEXEC | fcntl(fd, F_GETFL)); of course all of these need to be fixed. FD_CLOEXEC is set via F_SETFD, not F_SETFL. by now i also read the developer info on the webpage. i'll behave now, file a bugreport and mail a diff -pru to jcid(a)softhome.net ;) regards, raphael

March 2, 2003

patch for POSIX file lock

by yangguilong

I'm compiling dillo on Cygwin, which lacks of flock/lockf, but has support for POSIX file lock (fcntl()). To enable the cookies support, I write a patch for it. In hope that it will be useful for other platform having similar situation. diff -Nurp dillo-0.6.6/src/cookies.c dillo-0.6.6-cygwin/src/cookies.c --- dillo-0.6.6/src/cookies.c 2002-05-28 04:47:50.000000000 +0800 +++ dillo-0.6.6-cygwin/src/cookies.c 2003-03-01 10:23:56.000000000 +0800 @@ -130,6 +130,9 @@ void a_Cookies_init() GList *domain_cookies; char *filename; char line[LINE_MAXLEN]; +#ifndef HAVE_LOCKF + struct flock lck; +#endif Cookie_control_init(); @@ -145,7 +148,16 @@ void a_Cookies_init() } /* Try to get a lock from the file descriptor */ +#ifdef HAVE_LOCKF disabled = (lockf(fileno(file_stream), F_TLOCK, 0) == -1); +#else /* POSIX lock */ + lck.l_start = 0; /* start at beginning of file */ + lck.l_len = 0; /* lock entire file */ + lck.l_type = F_WRLCK; + lck.l_whence = SEEK_SET; /* absolute offset */ + + disabled = (fcntl(fileno(file_stream), F_SETLK, &lck) == -1); +#endif if (disabled) { DEBUG_MSG(10, "The cookies file has a file lock:\n" " disabling cookies in this dillo!\n"); @@ -278,6 +290,9 @@ static gboolean Cookies_freeall_cb(gpoin void a_Cookies_freeall() { int fd; +#ifndef HAVE_LOCKF + struct flock lck; +#endif if (disabled) return; @@ -288,7 +303,16 @@ void a_Cookies_freeall() g_hash_table_foreach_remove(cookies, Cookies_freeall_cb, NULL); +#ifdef HAVE_LOCKF lockf(fd, F_ULOCK, 0); +#else /* POSIX file lock */ + lck.l_start = 0; /* start at beginning of file */ + lck.l_len = 0; /* lock entire file */ + lck.l_type = F_UNLCK; + lck.l_whence = SEEK_SET; /* absolute offset */ + + fcntl(fileno(file_stream), F_SETLKW, &lck); +#endif fclose(file_stream); } --------------------------------------------- »¶Ó¹âÁÙ http://www.cmmail.com

March 2, 2003

BUGFIX set close_on_exec (FD_CLOEXEC)

by Raphael Barabas

hello, in my neverending search for the perfect browser i stumbled across dillo. it looks great and quite usable, altough it's still alpha. unfortunately dillo 0.7.0 won't run on solaris8 (ultra30), so i wrote a fix. turns out every other os is affected by this bug, too. solaris just seems to be less forgiving in this matter :) to compile on solaris you may also need some workarounds, take a look at bugreports 402, 413 and 415. problem: solaris: see bugreport 416, dillo enters endless loop on startup, repeating "IO_write: Changing io->Buf (0)" linux: no immediate effect, although some filedescriptors are in state "open" for too long. i've not really looked into it but this should have negative effects in the long run. reason: in IO.c, function IO_submit, filedescriptor-flag close_on_exec is not set the right way (not at all). on solaris, as a direct result, non-blocking io will accidentally be handled via O_NDELAY instead of O_NONBLOCKING, resulting in an endless loop. patch: *** IO.c.org Sat Mar 1 21:56:13 2003 --- IO.c Sat Mar 1 21:56:54 2003 *************** *** 530,536 **** /* Set FD to background and to close on exec. */ fcntl(r_io->FD, F_SETFL, ! O_NONBLOCK | FD_CLOEXEC | fcntl(r_io->FD, F_GETFL)); if ( r_io->Op == IORead ) { g_io_add_watch(r_io->GioCh, G_IO_IN | G_IO_ERR | G_IO_HUP, --- 530,538 ---- /* Set FD to background and to close on exec. */ fcntl(r_io->FD, F_SETFL, ! O_NONBLOCK | fcntl(r_io->FD, F_GETFL)); ! fcntl(r_io->FD, F_SETFD, ! FD_CLOEXEC | fcntl(r_io->FD, F_GETFD)); if ( r_io->Op == IORead ) { g_io_add_watch(r_io->GioCh, G_IO_IN | G_IO_ERR | G_IO_HUP, disclaimer: this bugfix has been tested briefly on debian gnu/linux 2.4.20 and solaris 8. please review my code for correctness. also note that bugreport 417 has been proven wrong by this. regards, raphael

March 1, 2003

Great work on Dillo! (fwd)

by Jorge Arellano Cid

---------- Forwarded message ---------- Date: Wed, 26 Feb 2003 10:02:07 -0500 From: Alwyn Kerr <alkerr(a)yifan.net> To: jcid(a)softhome.net Subject: Great work on Dillo! Hi there, I'm writing to express how happy I am with Dillo. I'm a HUGE fan of software that is light-weight and Dillo would have to be the smallest, functional browser I've ever used. I find that it is especially useful for browsing documentation that's saved as a stack of HTML pages on disk. I mostly use it for reading the GTK API docs. when developing GTK applications. Anyway, before I'm done I was just wondering if future versions of Dillo might make tabs available for multiple pages? Once again, keep up the good work and please extend my happiness to the rest of the development team. Owen Klan ----------------------------------------------------- http://eo.yifan.net Free POP3/Web Email, File Manager, Calendar and Address Book

March 1, 2003

Re: [Dillo-dev] Loosing bookmarks

by Jorge Arellano Cid

On Wed, 26 Feb 2003, Phillip Warner wrote: > On Wed, 26 Feb 2003 10:17:14 -0300 (CLST) > Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > > The patch: > > > > This patch does two things: > > > > 1.- Keeps a backup of the bookmarks file: bm.txt.bak > > 2.- Avoids not loading the bookmarks file by issuing a > > conditional load before any operation. > > > > Notes: > > * The backup file is made by renaming the original file, so > > if a write error happens the backup remains! > > * The backup is made when the original file has a size greater > > than 256 bytes (just in case!). > > > > > > Please test it as hard as you can. > > > > The test was successful on my end. However, if I kill the server with > -9, the pipe remains and the server will not reload. If I then remove > the pipe, the server loads and responds "Hi browser" but no bookmarks > are written. If I then try to access the bookmarks, I get a blank > page. If I then close dillo, the server also stops. > > Of course, after reloading dillo all is well. > > But, no bookmarks are lost, except the ones that were chosen after the > server was killed. > > Is there a way to overwrite the abandoned pipe (when no server is > running) when restarting the server? I know sylpheed does this. Yes, this situation is problematic. Besides the 'kill -9', a system crash can also leave the socket's filename in /tmp... and the trouble only ends when the user realizes he must remove the socket's filename manually! After some thought, I finally found a way to check these problems using connect(). I'm not sure which error code (errno number) the different OSes will return, so I included: ECONNREFUSED, EBADF, ENOTSOCK and EADDRNOTAVAIL. GNU/Linux returns ECONNREFUSED in this case. ...and I almost forgot that sometime ago (Nov 27), Ben Wolley wrote: > Hello Jorge, > > I just tried out the dpi1 bookmarks plugin, and I really like the concept. > But I started wondering if someone could take advantage of a dpi URL to do > something improper. > > <html> > <body> > <a href="dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&sub > mit=submit.">test</a> > <img src="dpi:/bm/modify?operation=add_url2&title=home2&url=http%3A%2F%2Fhome&submit=submit." > alt="test image"> > </body> > </html> > > When I load that page, not only does the image alter my bookmarks, when I > click on the link the window closes (after altering my bookmarks). This > seems to be an issue similar to what is discussed in the HTTP 1.1 spec > section 15.1.3. > > Can POST data be sent instead? Section 9.5 says that POST should be used > for "extending a database through an append operation", which is what the > plugin actually does. A hacked dpi-request using POST can also be faked, so the decision was to only allow dpi-urls from dpi-generated pages. The attached patch (against dillo-0.7.0) does five things: 1.- Keeps a backup of the bookmarks file: bm.txt.bak 2.- Avoids not loading the bookmarks file by issuing a conditional load before any operation. 3.- Takes care of EINTR while in recv(). 4.- Tests the socket's filename to be responsive and relaunchs the server if necessary. 5.- Allows dpi-requests, but only from dpi-generated pages. Most probably this will be the patch in the bug-fix release. Once again, please test it throughly! Cheers Jorge.-

March 1, 2003

Re: [Dillo-dev] Bookmarks no longer work

by Thorben Thuermer

On Sat, 1 Mar 2003 06:19:50 -0600 Albert Wagner <alwagner(a)tcac.net> wrote: > On Sat, 1 Mar 2003 20:05:25 +0200 > slymer(a)slymer.org wrote: > > <snip> > > > > Restart the bookmark server. > > > I didn't know there was one. How do I do that? "bm_srv12", dillo runs it when the bookmark dpi is first accessed, and talks to it via /tmp/bm.<user>. if it fails to create the socket (because the old one was not deleted before) that would cause your problem. Thorben

March 1, 2003

Re: [Dillo-dev] Bookmarks no longer work

by Thorben Thuermer

On Sat, 1 Mar 2003 05:15:21 -0600 Albert Wagner <alwagner(a)tcac.net> wrote: > I had some trouble with my system and had to manually kill several > processes. Ever since then Dillo bookmarks no longer work. I get the > following: > > Nav_open_url: Url=>dpi:/bm/< > [connect]: Connection refused > Not implemented > > How can I fix this? try to rm /tmp/bm.<username> (that's the unix socket of the bm server), and restart it... Thorben

March 1, 2003

Re: [Dillo-dev] Bookmarks no longer work

by slymer＠slymer.org

On Sat, 1 Mar 2003 05:15:21 -0600 Albert Wagner <alwagner(a)tcac.net> wrote: > I had some trouble with my system and had to manually kill > several processes. Ever since then Dillo bookmarks no longer > work. I get the following: > > Nav_open_url: Url=>dpi:/bm/< > [connect]: Connection refused > Not implemented > > How can I fix this? Restart the bookmark server. -- Registered Linux user #298569 Gomme's Laws: (1) A backscratcher will always find new itches. (2) Time accelerates. (3) The weather at home improves as soon as you go away.

March 1, 2003

Re: [Dillo-dev] Bookmarks no longer work

by Albert Wagner

On Sat, 1 Mar 2003 21:00:18 +0100 Thorben Thuermer <r00t(a)Informatik.Uni-Bremen.DE> wrote: <snip> > try to rm /tmp/bm.<username> (that's the unix socket of the bm > server), and restart it... > That worked. Thank you.

March 1, 2003

Re: [Dillo-dev] Bookmarks no longer work

by Albert Wagner

On Sat, 1 Mar 2003 20:05:25 +0200 slymer(a)slymer.org wrote: <snip> > > Restart the bookmark server. > I didn't know there was one. How do I do that?

March 1, 2003

Bookmarks no longer work

by Albert Wagner

I had some trouble with my system and had to manually kill several processes. Ever since then Dillo bookmarks no longer work. I get the following: Nav_open_url: Url=>dpi:/bm/< [connect]: Connection refused Not implemented How can I fix this?

March 1, 2003

freezing of dillo.0.7.0

by robert w hall

Is the description of the 'freezing' of dillo given in the README an uptodate description of the problem. This implies that it is a kernel version effect... I originally compiled dillo0.6.6 against slack 7, kernel 2.4.5 (IIRC, or even 2.2.18) with no problems. However dillo0.7.0 does freeze, even when compiled against the headers for, and run under, kernel 2.4.19. BUT it compiles and runs ok when compiled under slack8.1, with the same headers and kernel. Is this a gcc problem? (I'm using 2.91.66 with slack 7). (The suggested patch poll-fix-fast of course does not run in cleanly against 0.7.0., and though the source compiles the executable still freezes). Sorry if I've missed something on this. Bob Hall PS it all compiles fine on the playstation2 linux kit with the 2.2.21 kernel, and a real old gcc -- robert w hall

Feb. 27, 2003

Re: [Dillo-dev] Loosing bookmarks

by Phillip Warner

On Wed, 26 Feb 2003 10:17:14 -0300 (CLST) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > The patch: > > This patch does two things: > > 1.- Keeps a backup of the bookmarks file: bm.txt.bak > 2.- Avoids not loading the bookmarks file by issuing a > conditional load before any operation. > > Notes: > * The backup file is made by renaming the original file, so > if a write error happens the backup remains! > * The backup is made when the original file has a size greater > than 256 bytes (just in case!). > > > Please test it as hard as you can. > The test was successful on my end. However, if I kill the server with -9, the pipe remains and the server will not reload. If I then remove the pipe, the server loads and responds "Hi browser" but no bookmarks are written. If I then try to access the bookmarks, I get a blank page. If I then close dillo, the server also stops. Of course, after reloading dillo all is well. But, no bookmarks are lost, except the ones that were chosen after the server was killed. Is there a way to overwrite the abandoned pipe (when no server is running) when restarting the server? I know sylpheed does this. Thanks for reading. Cheers, --Phil ------------------------------ Non-Determinism is not meant to be reasonable. -- M.J. 0'Donnell

Feb. 27, 2003

Where can I find the flock->lockf patch?

by 阿贵

dillo-devHi, I'm going to build dillo on Windows, using Cygwin as porting tool and running envrionment. Guided by http://homepage.ntlworld.com/steven.obrien2/, I can build dillo-0.6.5 successfully. But there is no implmentation for lockf on Cygwin. So I'd like to know where can I find the flock->lockf patch. I want to apply a reverse patch on the new version of dillo. TIA. BTW: Please cc me, I'm not on the list. Hansom Young

Feb. 26, 2003

Re: [Dillo-dev] segmentation fault

by John Bradford

> Ah i did not know about kgcc, thanks. > I did not work either. Same problem, kgcc is gcc version egcs-2.91.66 by > the way. GCC 2.95.3 is very widely used and well tested in general. I've successfully compiled Dillo 0.6.6 and 0.7.0 with it. I wasn't able to get Dillo to compile with tcc, unfortunately, has anybody else had success with it? http://fabrice.bellard.free.fr/tcc/ John.

Feb. 26, 2003

Re: [Dillo-dev] Loosing bookmarks

by Jorge Arellano Cid

Hi There! > > This didn't help, bookmarks disappeared succesfully with this patch too. > This time file contained lastly added bookmark in section ":s0: > Unclassified" (this section didn't exist before) and i think that it > happened, when i added this bookmark. > > > > > On Sun, 23 Feb 2003, John Bradford wrote: > > > > > Since I started using using 7.0, my bookmarks have been lost on four > > > occasions, but I haven't been able to reproduce the bug at will - has > > > anybody else noticed this? Unfortunately this is a perverse bug: when you get accustomed to using the new bookmarks, the probability of it happening increases. I'm attaching a patch to fix it, but please let me explain the bug a bit: it happens when the bm server receives a modification request (add/modify/delete) before it has loaded the bookmarks file the first time. As most of these operations are accessed through the "modify" page (which loads the bookmarks file), they're safe, but "Bookmark this page", from the pop-up menu, is the exception. So why it was so hard to hunt? Because when you start dillo and it launches the bm server for the first time, it's vulnerable, but most probably your first action with the bookmarks will be to see them. After this first request, the bug can't happen again. If you close dillo, the bm server will remain sleeping, so if you run another dillo and issue a bare "Bookmark this page", the responding server will be the same you used the first time, so no bug can happen! The only way (AFAICS) to reproduce it, is to kill the server and issue a "Bookmark this page" operation before any other bookmark operation. How can this happen with "normal" use? Start dillo, surf the net and use bookmarks happily. At night, turn off your computer. Next day, start surfing, find a nice page and bookmark it before looking at your bookmarks. The patch: This patch does two things: 1.- Keeps a backup of the bookmarks file: bm.txt.bak 2.- Avoids not loading the bookmarks file by issuing a conditional load before any operation. Notes: * The backup file is made by renaming the original file, so if a write error happens the backup remains! * The backup is made when the original file has a size greater than 256 bytes (just in case!). Please test it as hard as you can. Livio: please add a warning message in the front and help pages of our site with a link to the patch and with the instructions to apply it. Please also state that a new release, fixing this bug will be done ASAP. Sebastian: Don't worry about the copy&paste work, it will not be included in this bug-fix release. Cheers Jorge.-

Feb. 26, 2003

Re: [Dillo-dev] segmentation fault

by andi

> try a "real" compiler :-) ... 2.96 is not a real release (see > also http://gcc.gnu.org/gcc-2.96.html) I think redhat has > something like kcc or kgcc which is intended for kernel > compilation, but it is an official release. Ah i did not know about kgcc, thanks. I did not work either. Same problem, kgcc is gcc version egcs-2.91.66 by the way.

Feb. 26, 2003

segmentation fault

by andi

Hi, Thanks for this great project, i love dillo. There is just one problem with the 0.7 version. I get a segmentation fault every time i click on a link. I newly compiled dillo-0.7.0 without any errors and i starts perfectly, but if i move my mouse over a link the url in the status bar is follow by "?135070228,-1073744832" without the quotes and the numbers may vary. If i click on the link dillo exits permanently. If i type in any urls in the address field, there is no problem. Everything loads happily. --Output if i run it from the console: bash-2.05a$ ./dillo Setting locale to C... HTML warning: URL has 4 illegal characters (0x00-0x1F, 0x7F or space) HTML warning: hexadecimal color lacks leading '#' HTML warning: hexadecimal color is not in RRGGBB format. HTML warning: hexadecimal color lacks leading '#' HTML warning: hexadecimal color is not in RRGGBB format. dillorc:11: unexpected string constant "text-color", expected symbol dillorc:11: error: unexpected string constant "text-color", expected symbol dillo_dns_init: Here we go! The cookies file has a file lock: disabling cookies in this dillo! Nav_open_url: Url=>about:splash< IO_write: Changing io->Buf (4096) IO_write: EAGAIN IO_write: Changing io->Buf (4096) IO_write: EAGAIN Segmentation fault --My Versions: RedHat 7.3 GNU Make version 3.79.1 gcc version 2.96

Feb. 26, 2003

Re: [Dillo-dev] present but cannot be compiled

by Akim Demaille

| Hi, | there is probably something wrong with your mailer :-) | And there is no response, just the quotation ... | Jan Yes, I forgot the following piece of text, sorry: Please, report this to the package maintainers, as it's a configure.ac problem. The Autoconf 2.57 doc says: Previous versions of Autoconf merely checked whether the header was accepted by the preprocessor. This was changed because the old test was inappropriate for typical uses. Headers are typically used to compile, not merely to preprocess, and the old behavior sometimes accepted headers that clashed at compile-time. If you need to check whether a header is preprocessable, you can use `AC_PREPROC_IFELSE' (*note Running the Preprocessor::). This scheme, which improves the robustness of the test, also requires that you make sure that headers that must be included before the HEADER-FILE be part of the INCLUDES, (*note Default Includes::). If looking for `bar.h', which requires that `foo.h' be included before if it exists, we suggest the following scheme: AC_CHECK_HEADERS([foo.h]) AC_CHECK_HEADERS([bar.h], [], [], [#if HAVE_FOO_H # include <foo.h> # endif ]) Thanks! | On Feb 26 11:30:24, Akim Demaille wrote: : :| Hi, :| is is what I get with the current CVS (viz later). :| :| know that I don't have libpng, libjpeg etc installed :| y mistake, I was compiling on machine without them), :| t I mean the 'usability ... yes ; presence ... no' problem. :| this an autoconf bug, or is configure.in written badly ? :| :| e system is: :| :| Debian unstable :| kernel 2.4.19 (self compiled) :| autoconf 2.57 :| automake 1.6.3 :| gcc/cpp 3.2.2 :| :| :| e results follow. :| :| Jan :| :| :| s co dillo && cd dillo :| autogen.sh :| configure --prefix=$HOME :| ecking for a BSD-compatible install... /usr/bin/install -c :| ecking whether build environment is sane... yes :| ecking for gawk... gawk :| ecking whether make sets $(MAKE)... yes :| ecking for gcc... gcc :| ecking for C compiler default output... a.out :| ecking whether the C compiler works... yes :| ecking whether we are cross compiling... no :| ecking for suffix of executables... :| ecking for suffix of object files... o :| ecking whether we are using the GNU C compiler... yes :| ecking whether gcc accepts -g... yes :| ecking for gcc option to accept ANSI C... none needed :| ecking for style of include used by make... GNU :| ecking dependency style of gcc... gcc3 :| ecking for gcc option to accept ANSI C... none needed :| ecking for ranlib... ranlib :| ecking for gtk-config... /usr/bin/gtk-config :| ecking for GTK - version >= 1.2.0... yes :| ecking for jpeg_destroy_decompress in -ljpeg... no :| nfigure: WARNING: *** JPEG support will not be included *** :| ecking for pthread_create in -lpthread... yes :| ecking for zlibVersion in -lz... no :| ecking for png_check_sig in -lpng... no :| ecking for ANSI C header files... no :| ecking fcntl.h usability... yes :| ecking fcntl.h presence... no :| nfigure: WARNING: fcntl.h: accepted by the compiler, rejected by the preprocessor! :| nfigure: WARNING: fcntl.h: proceeding with the preprocessor's result :| nfigure: WARNING: ## ------------------------------------ ## :| nfigure: WARNING: ## Report this to bug-autoconf(a)gnu.org. ## :| nfigure: WARNING: ## ------------------------------------ ## :| ecking for fcntl.h... no :| ecking unistd.h usability... yes :| ecking unistd.h presence... no :| nfigure: WARNING: unistd.h: accepted by the compiler, rejected by the preprocessor! :| nfigure: WARNING: unistd.h: proceeding with the preprocessor's result :| nfigure: WARNING: ## ------------------------------------ ## :| nfigure: WARNING: ## Report this to bug-autoconf(a)gnu.org. ## :| nfigure: WARNING: ## ------------------------------------ ## :| ecking for unistd.h... no :| ecking sys/uio.h usability... yes :| ecking sys/uio.h presence... no :| nfigure: WARNING: sys/uio.h: accepted by the compiler, rejected by the preprocessor! :| nfigure: WARNING: sys/uio.h: proceeding with the preprocessor's result :| nfigure: WARNING: ## ------------------------------------ ## :| nfigure: WARNING: ## Report this to bug-autoconf(a)gnu.org. ## :| nfigure: WARNING: ## ------------------------------------ ## :| ecking for sys/uio.h... no :| ecking for socket... yes :| nfigure: creating ./config.status :| nfig.status: creating Makefile :| nfig.status: creating doc/Makefile :| nfig.status: creating src/Makefile :| nfig.status: creating src/IO/Makefile :| nfig.status: creating config.h :| nfig.status: executing depfiles commands :| :| : :_______________________________________________ :Dillo-dev mailing list :Dillo-dev@lists.auriga.wearlab.de :http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 26, 2003

present but cannot be compiled (Was: configure problems)

by Akim Demaille

Feb. 26, 2003

Re: [Dillo-dev] Loosing bookmarks

by TheStar

I've been reading about these bookmarks, and I'm wondering what it is: Is it a dillo/dpi (design) problem? Or is it the bookmark server? Just curious.. ;)

Feb. 26, 2003

Re: [Dillo-dev] Loosing bookmarks

by Madis Janson

This didn't help, bookmarks disappeared succesfully with this patch too. This time file contained lastly added bookmark in section ":s0: Unclassified" (this section didn't exist before) and i think that it happened, when i added this bookmark. On Mon, 24 Feb 2003, madis wrote: > > On Sun, 23 Feb 2003, John Bradford wrote: > > > Since I started using using 7.0, my bookmarks have been lost on four > > occasions, but I haven't been able to reproduce the bug at will - has > > anybody else noticed this? > > > Yes, once (not a much help for bughunt) and resulted in zero-length > bm.txt. Although this isn't a real fix, i thought now, that saveing into > temporary file and renameing it after close may help to avoid damage > when bm_srv crashes during save. Probably some error checking should be > also added. > > --- cvs/dillo/dpi/bm_srv12.c 2003-02-16 18:45:54.000000000 +0200 > +++ dillo/dpi/bm_srv12.c 2003-02-24 04:28:59.000000000 +0200 > @@ -851,10 +851,12 @@ int Bms_save() > BmSec *sec_node; > GSList *list, *list2; > GString *gstr = g_string_new(""); > + gchar *BmTmp; > struct stat TimeStamp; > > + BmTmp = g_strconcat(BmFile, ".tmp", NULL); > /* open bm file */ > - if (!(BmTxt = fopen(BmFile, "w"))) { > + if (!(BmTxt = fopen(BmTmp, "w"))) { > perror("[fopen]"); > return 1; > } > @@ -884,6 +886,8 @@ int Bms_save() > > g_string_free(gstr, TRUE); > fclose(BmTxt); > + rename(BmTmp, BmFile); > + g_free(BmTmp); > > /* keep track of the timestamp */ > stat(BmFile, &TimeStamp); > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 25, 2003

Re: [Dillo-dev] Loosing bookmarks

by slymer＠slymer.org

On Sun, 23 Feb 2003 14:29:49 +0000 (GMT) John Bradford <john(a)grabjohn.com> wrote: > Since I started using using 7.0, my bookmarks have been lost > on four occasions, but I haven't been able to reproduce the > bug at will - has anybody else noticed this? Yep, once. Since then I wrote a quick script that does 2 backups of the bm.txt file to save me from "disaster". Sadly I have no idea why it happened to me either :/ -- Registered Linux user #298569 QOTD: "Every morning I read the obituaries; if my name's not there, I go to work."

Feb. 24, 2003

Re: [Dillo-dev] Loosing bookmarks

by Daniel Pfurtscheller

Yes, I have also noticed this. First, Dillo 7.0 imported all my old bookmarks, but then everything was lost. Dillo didn't crash nor behaved strange - it just deleted my beloved (and backup'ed - thanks god!) bookmark-collection. Although my bugreport won't be very helpfull - I still hope it made some people nervous ;)! pfu -- "Contrariwise," continued Tweedledee, "if it was so, it might be, and if it were so, it would be; but as it isn't, it ain't. That's logic!" -- Lewis Carroll

Feb. 24, 2003

Re: [Dillo-dev] Loosing bookmarks

by madis

On Sun, 23 Feb 2003, John Bradford wrote: > Since I started using using 7.0, my bookmarks have been lost on four > occasions, but I haven't been able to reproduce the bug at will - has > anybody else noticed this? > Yes, once (not a much help for bughunt) and resulted in zero-length bm.txt. Although this isn't a real fix, i thought now, that saveing into temporary file and renameing it after close may help to avoid damage when bm_srv crashes during save. Probably some error checking should be also added. --- cvs/dillo/dpi/bm_srv12.c 2003-02-16 18:45:54.000000000 +0200 +++ dillo/dpi/bm_srv12.c 2003-02-24 04:28:59.000000000 +0200 @@ -851,10 +851,12 @@ int Bms_save() BmSec *sec_node; GSList *list, *list2; GString *gstr = g_string_new(""); + gchar *BmTmp; struct stat TimeStamp; + BmTmp = g_strconcat(BmFile, ".tmp", NULL); /* open bm file */ - if (!(BmTxt = fopen(BmFile, "w"))) { + if (!(BmTxt = fopen(BmTmp, "w"))) { perror("[fopen]"); return 1; } @@ -884,6 +886,8 @@ int Bms_save() g_string_free(gstr, TRUE); fclose(BmTxt); + rename(BmTmp, BmFile); + g_free(BmTmp); /* keep track of the timestamp */ stat(BmFile, &TimeStamp);

Feb. 24, 2003

Loosing bookmarks

by John Bradford

Since I started using using 7.0, my bookmarks have been lost on four occasions, but I haven't been able to reproduce the bug at will - has anybody else noticed this? John.

Feb. 23, 2003

Re: [Dillo-dev] Website improvement / CVS page

by Sebastian Geerken

On Thu, Feb 20, Thorben Thuermer wrote: > [...] > > Maybe the "checkout without login" only works in later releases of CVS? (I > > didn't find anything in the NEWS file, though) > > After some looking at CVS source, we found that it is indeed a new > "feature" of newer CVS versions... > > I updated the Auriga CVS page with a note about logging in now. The CVS page of the dillo site (<http://dillo.auriga.wearlab.de/cvs.html>) has been updated, too. Sebastian

Feb. 22, 2003

re: ipv6 and dns threads

by Damien Couderc

Last fix about dns threads will be available in less than 2 hours on the given URL. Damien

Feb. 22, 2003

ipv6 and dns threads

by Damien Couderc

You will found at the following URL patches from the openbsd port : http://www.openbsd.org/cgi-bin/cvsweb/ports/www/dillo/patches/ Some of them fix ipv6 and threaded name resolution bugs. I've also informed jcid that display on sparc64 is fucked as the text is displayed one word per line. All comment to fix this bug is welcome even if it's just a place where to begin to find out what is going on. Regards, Damien

Feb. 22, 2003

Floats (was: bug tracking engine)

by Sebastian Geerken

On Tue, Feb 18, Joe Crayne wrote: > > > I've been thinking about it (and hacking on dw_page.c) and > > > have a partial implementation. It involved adding a pointer > > > line->last_float_line which points to the last line that has > > > a floater hanging down in the margin of the current line. > > > Dw_page_draw_line() traces that pointer and draws that line > > > too (and hence also its last_float_line and so on). > > > > Dw_page_draw_line (which is called by Dw_page_draw, the > > implementation of DwWidget::draw) just does the actual drawing > > (putting the pixels on the screen), and since you cannot > > predict that it is called for all lines (normally it will be > > called for those lines seen in the viewport), it should not > > change the state of a DwPage. > > It doesn't. Dw_page_draw_line() traces the pointer and causes > possibly other lines to be drawn other than the one it is called > for. If I have understood you correctly, you want Dw_page_draw_line to determine the positions of the floats. This will make calls to a_Dw_widget_size_allocate (for embedded child widgets) neccessary, which does change the state, at least of the widget tree. You really should put your code is Dw_page_size_request and Dw_page_size_allocate. Please read the documentations, both of Gtk+ (which is quite similar to Dw), and Dw. Especially, try to understand the implementation of "incremential resizing" (when something is unclear, I'll answer questions about it). > > - Floats may exceed the allocation of the DwPage, so they may not be > > a child widget, instead, an interaction between two DwPage's is > > necessary. > > When does a float exceed the allocation of the DwPage? > Is there a new DwPage for new paragarphs? Currently, nested DwPage's are used for: 1. any blocks with a margin different from zero (<blockqoute>, <ul> and some others): DwPage had originally the possibility to indent single blocks, but when I one redesigned DwPage (to fix a CPU lock), I decided to simplify it by removing this feature. 2. Any <li>, since this makes dealing width the hanging bullet/number much easier. (Paragraphs within list items were poorly rendered for a long time.) > > - Since a float may be defined at a point, where there is > > already a float at the respective side, you do not only need > > one pointer, but rather a list or a tree, depending on how the > > second float is positioned (below or left/right, both is > > allowed by the CSS2 spec, but from what I've thought about it, > > I believe that the second variant is simpler to implement). > > How about this: Floats are drawn in sequence just as other words > on the line. See above. > Nothing special, except that now, line->ascent and > line->descent doesnt count floats. Consequently, if the portion > of the screen being refreshed doesn't yeild the DwPageLine where > the float occurs, then that float wont get properly refreshed. That's exactly the point! Child widgets must *always* size_allocated, also when they are not visible. Sebastain

Feb. 22, 2003

Re: [Dillo-dev] if dillo is embeddable, what would it take to embed it in itself so that dillo can do frames?

by Andreas Schweitzer

On Sat, Feb 22, 2003 at 12:09:38AM -0800, John L.Utz III wrote: > > so if dillo can be embedded in sylpheed, why cant dillo be embedded in dillo? <to support frames> I have hacked dillo a bit to support frames (don't hold your breath, it's far from being usable and even further from clean code). The "dillo embedded in istelf"-idea crossed my mind, too. If you do that you spawn unnecessary processes. Also, you have to be really careful about tracking history (the back button still needs to work somehow). Also, the target tag needs to work - that would probably be only a minor problem. Those were just some ideas ... I may be wrong. But right now I hack around to put a_Interface_browser_window_new into an existing window. But, on the one hand, a_Interface_browser_window_new probably needs to be modified or cloned and on the other hand I know too little GTK I'm afraid :-) Just if anybody cares :-) ..... If I was certain I could get somewhere, I would have added myself into the bug tracking engine. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Feb. 22, 2003

if dillo is embeddable, what would it take to embed it in itself so that dillo can do frames?

by John L.Utz III

Now, i happen to hate frames, and prefer to do the 'fake frames in tables' thang (which other people hate :-) ) , but their are a lot of misguided webdevs out there who have chosen to implement their site with frames, and i actually need to get information from them every now and then. For instance, going to this one in dillo is a pathetic folly :-) : http://www5.metrokc.gov/webmaps/parcelviewer/Viewer/KingCounty/viewer.asp so if dillo can be embedded in sylpheed, why cant dillo be embedded in dillo? tnx! johnu

Feb. 22, 2003

Changing font_factor dynamically

by Gregor Hoffleit

[Please pardon me if this is the wrong forum for such feature requests.] I'm using dillo with familiar on my iPAQ. One thing I'm regularly missing is a possibility to change the font_factor setting dynamically: For the iPAQ's small display (240x320 minus a few decorations), a single font_factor just can't fit for all different pages: For some pages, I'm glad with font_factor=0.5, with others, font_factor=0.6 is readable. I guess it's a major effort to implement a dynamical switch of the font_factor (e.g. using a pull-down menu), but I would be glad if you could discuss this feature request. Thanks for your efforts, Gregor Hoffleit

Feb. 21, 2003

Re: [Dillo-dev] -l switch not working if <base href="..."> is given

by Melvin Hadasht

Oops, here are the test files... Kenavo (Breton: Goodbye) -- Melvin Hadasht

Feb. 21, 2003