- Dillo-dev - lists.mailman3.com

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