From tim.nieradzik at gmx.de Wed Apr 1 02:52:30 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Wed Apr 1 02:53:14 2009 Subject: [Dillo-dev] Segfault on sites requiring authentication Message-ID: <20090401005230.GF11082@tux.tuxnet> Whenever I visit http://puppyisos.org/isos (puppy / linux), Dillo segfaults. The reason is that in some cases the variable Client_bw is NULL. However, some functions depend on it and access its member variables. Client_bw is initialized in Cache_process_queue() (src/cache.c). When authentication is required, this variable is passed over to Cache_auth_entry() which sets a timeout. Its callback (Cache_auth_callback()) opens up a dialog asking for the credentials and then calls a_Nav_reload() with the Client_bw as its first parameter. Finally in a_Nav_cancel_expect() Client_bw's member variable nav_expecting is used and as bw is NULL, Dillo segfaults. I came up with a small patch that removes Cache_auth_callback() and Cache_auth_entry() as I have not seen any advantages in delaying the authentication popup. The next thing I did was to show the dialog on condition that Client_bw is not NULL and that we have finished the transfer (At least I hope CA_Close is the proper flag for doing so). There were various unnecessary checks in src/nav.c. They compared bw with NULL. In my opinion the affected functions (a_Nav_expect_done, a_Nav_push and a_Nav_repush) should never be called if you cannot be sure that bw is not NUL. What is your view on this subject? Unfortunately, my approach does not solve the original problem that caused Client_bw being NULL. Furthermore, the patch introduces a new bug: The dialog pops up when reloading the site but after having entered the correct credentials or having pressed the ``Cancel'' button, it appears again. Any ideas? While digging deeper into the code, I noticed that we make heavy use of timers for popups and reloading pages? Is there any special reason for it? --Tim -------------- next part -------------- diff -r f8b1844a4fc7 src/cache.c --- a/src/cache.c Sat Mar 28 16:08:04 2009 +0100 +++ b/src/cache.c Wed Apr 01 00:51:11 2009 +0000 @@ -90,8 +90,6 @@ */ static void Cache_process_queue(CacheEntry_t *entry); static void Cache_delayed_process_queue(CacheEntry_t *entry); -static void Cache_auth_entry(CacheEntry_t *entry, BrowserWindow *bw); - /* * Determine if two cache entries are equal (used by CachedURLs) @@ -954,50 +952,6 @@ return 0; } -typedef struct { - Dlist *auth; - DilloUrl *url; - BrowserWindow *bw; -} CacheAuthData_t; - -/* - * Ask for user/password and reload the page. - */ -static void Cache_auth_callback(void *vdata) -{ - CacheAuthData_t *data = (CacheAuthData_t *)vdata; - if (a_Auth_do_auth(data->auth, data->url)) - a_Nav_reload(data->bw); - Cache_auth_free(data->auth); - a_Url_free(data->url); - dFree(data); - Cache_auth_entry(NULL, NULL); - a_Timeout_remove(); -} - -/* - * Set a timeout function to ask for user/password. - */ -static void Cache_auth_entry(CacheEntry_t *entry, BrowserWindow *bw) -{ - static int busy = 0; - CacheAuthData_t *data; - - if (!entry) { - busy = 0; - } else if (busy) { - MSG_WARN("Cache_auth_entry: caught busy!\n"); - } else if (entry->Auth) { - busy = 1; - data = dNew(CacheAuthData_t, 1); - data->auth = entry->Auth; - data->url = a_Url_dup(entry->Url); - data->bw = bw; - entry->Auth = NULL; - a_Timeout_add(0.0, Cache_auth_callback, data); - } -} - /* * Check whether a URL scheme is downloadable. * Return: 1 enabled, 0 disabled. @@ -1187,9 +1141,10 @@ a_UIcmd_save_link(Client_bw, url); } a_Url_free(url); - - } else if (entry->Auth && (entry->Flags & CA_GotData)) { - Cache_auth_entry(entry, Client_bw); + } else if (entry->Auth && (entry->Flags & CA_Close)) { + if ((Client_bw != NULL) && a_Auth_do_auth(entry->Auth, a_Url_dup(entry->Url))) { + a_Nav_reload(Client_bw); + } } /* Trigger cleanup when there are no cache clients */ diff -r f8b1844a4fc7 src/nav.c --- a/src/nav.c Sat Mar 28 16:08:04 2009 +0100 +++ b/src/nav.c Wed Apr 01 00:51:11 2009 +0000 @@ -268,8 +268,6 @@ DilloUrl *url; char *fragment = NULL; - dReturn_if_fail(bw != NULL); - if (bw->nav_expecting) { url = bw->nav_expect_url; reload = (URL_FLAGS(url) & URL_ReloadPage); @@ -334,8 +332,6 @@ */ void a_Nav_push(BrowserWindow *bw, const DilloUrl *url) { - dReturn_if_fail (bw != NULL); - if (bw->nav_expecting && !a_Url_cmp(bw->nav_expect_url, url) && !strcmp(URL_FRAGMENT(bw->nav_expect_url),URL_FRAGMENT(url))) { /* we're already expecting that url (most probably a double-click) */ @@ -383,7 +379,6 @@ */ void a_Nav_repush(BrowserWindow *bw) { - dReturn_if_fail (bw != NULL); MSG(">>> a_Nav_repush <<<<\n"); a_Timeout_add(0.0, Nav_repush_callback, (void*)bw); } From Johannes.Hofmann at gmx.de Wed Apr 1 09:47:11 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Wed Apr 1 09:48:08 2009 Subject: [Dillo-dev] [PATCH] startup window Message-ID: <20090401074711.GA927@blob.baaderstrasse.com> Hi, attached patch adds a proper startup screen for dillo. Cheers, Johannes -------------- next part -------------- diff -r f8b1844a4fc7 src/dillo.cc --- a/src/dillo.cc Sat Mar 28 16:08:04 2009 +0100 +++ b/src/dillo.cc Wed Apr 01 09:45:56 2009 +0200 @@ -24,6 +24,7 @@ #include #include +#include #include #include #include @@ -254,21 +255,122 @@ int main(int argc, char **argv) } dFree(opt_argv); + fltk::Window splash(400, 100, "Dillo Startup Screen"); + fltk::ProgressBar pb(25, 25, 350, 25, "Dillo Initialization"); + pb.maximum(13); + splash.add(pb); + fltk::Widget pbox(25, 50, 350, 25); + splash.add(pbox); + splash.show(); + // Initialize internal modules + int i = 0; + pbox.label("Initialize internal modules"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Dir_init(); + + pbox.label("Initialize preferences"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Prefs_init(); + + pbox.label("Initialize dillorc directories"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Dir_check_dillorc_directory(); /* and create if not present */ + + pbox.label("Initialize DPIs"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Dpi_init(); + + pbox.label("Initialize DNS"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Dns_init(); + + pbox.label("Initialize Web"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Web_init(); + + pbox.label("Initialize HTTP"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Http_init(); + + pbox.label("Initialize MIME"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Mime_init(); + + pbox.label("Initialize CAPI"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Capi_init(); + + pbox.label("Initialize Dicache"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Dicache_init(); + + pbox.label("Initialize Browser Window"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Bw_init(); + + pbox.label("Initialize Cookies"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Cookies_init(); + + pbox.label("Initialize Authentication"); + pbox.redraw(); + pb.position(i++); + fltk::check(); + usleep(500000); + a_Auth_init(); + splash.hide(); + /* command line options override preferences */ if (options_got & DILLO_CLI_FULLWINDOW) prefs.fullwindow_start = TRUE; From thomas-forum at orgis.org Wed Apr 1 12:32:49 2009 From: thomas-forum at orgis.org (Thomas Orgis) Date: Wed Apr 1 12:33:35 2009 Subject: [Dillo-dev] [PATCH] startup window In-Reply-To: <20090401074711.GA927@blob.baaderstrasse.com> References: <20090401074711.GA927@blob.baaderstrasse.com> Message-ID: <20090401123249.6f64dbe2@sunscreen.local> Am Wed, 1 Apr 2009 09:47:11 +0200 schrieb Hofmann Johannes : > Hi, > attached patch adds a proper startup screen for dillo. Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". I don't want to be offensive, just voice my concern... Alrighty then, Thomas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available Url : /pipermail/attachments/20090401/03f03abc/signature.pgp From corvid at lavabit.com Wed Apr 1 18:45:24 2009 From: corvid at lavabit.com (corvid) Date: Wed Apr 1 18:48:01 2009 Subject: [Dillo-dev] Segfault on sites requiring authentication In-Reply-To: <20090401005230.GF11082@tux.tuxnet> References: <20090401005230.GF11082@tux.tuxnet> Message-ID: <20090401164524.GC9874@local.gobigwest.com> Tim wrote: > Whenever I visit http://puppyisos.org/isos (puppy / linux), Dillo > segfaults. The reason is that in some cases the variable Client_bw > is NULL. However, some functions depend on it and access its member > variables. > > Client_bw is initialized in Cache_process_queue() (src/cache.c). > When authentication is required, this variable is passed over to > Cache_auth_entry() which sets a timeout. Its callback > (Cache_auth_callback()) opens up a dialog asking for the credentials > and then calls a_Nav_reload() with the Client_bw as its first > parameter. Finally in a_Nav_cancel_expect() Client_bw's member > variable nav_expecting is used and as bw is NULL, Dillo segfaults. I'm not seeing this crash. Is it going through the for loop and getting set to NULL in Client_bw = ClientWeb->bw;, or is it NULL because there weren't any clients and it didn't execute that code? > I came up with a small patch that removes Cache_auth_callback() and > Cache_auth_entry() as I have not seen any advantages in delaying the > authentication popup. The next thing I did was to show the dialog on > condition that Client_bw is not NULL and that we have finished the > transfer (At least I hope CA_Close is the proper flag for doing so). > > There were various unnecessary checks in src/nav.c. They compared bw > with NULL. In my opinion the affected functions (a_Nav_expect_done, > a_Nav_push and a_Nav_repush) should never be called if you cannot be > sure that bw is not NUL. What is your view on this subject? > > Unfortunately, my approach does not solve the original problem that > caused Client_bw being NULL. Furthermore, the patch introduces a new > bug: The dialog pops up when reloading the site but after having > entered the correct credentials or having pressed the ``Cancel'' > button, it appears again. Any ideas? > > While digging deeper into the code, I noticed that we make heavy use > of timers for popups and reloading pages? Is there any special > reason for it? If the calling code needs to go back to whatever it was doing rather than waiting around for the user to interact with a popup, a timer is used. From corvid at lavabit.com Wed Apr 1 18:49:44 2009 From: corvid at lavabit.com (corvid) Date: Wed Apr 1 18:52:18 2009 Subject: [Dillo-dev] [PATCH] startup window In-Reply-To: <20090401123249.6f64dbe2@sunscreen.local> References: <20090401074711.GA927@blob.baaderstrasse.com> <20090401123249.6f64dbe2@sunscreen.local> Message-ID: <20090401164944.GD9874@local.gobigwest.com> Thomas wrote: > Am Wed, 1 Apr 2009 09:47:11 +0200 > schrieb Hofmann Johannes : > > > Hi, > > attached patch adds a proper startup screen for dillo. > > Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? > I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. > Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... > Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". > I don't want to be offensive, just voice my concern... I agree with Thomas here. From Johannes.Hofmann at gmx.de Wed Apr 1 20:11:32 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Wed Apr 1 20:12:30 2009 Subject: [Dillo-dev] [PATCH] startup window In-Reply-To: <20090401164944.GD9874@local.gobigwest.com> References: <20090401074711.GA927@blob.baaderstrasse.com> <20090401123249.6f64dbe2@sunscreen.local> <20090401164944.GD9874@local.gobigwest.com> Message-ID: <20090401181132.GA1650@blob.baaderstrasse.com> On Wed, Apr 01, 2009 at 04:49:44PM +0000, corvid wrote: > Thomas wrote: > > Am Wed, 1 Apr 2009 09:47:11 +0200 > > schrieb Hofmann Johannes : > > > > > Hi, > > > attached patch adds a proper startup screen for dillo. > > > > Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? > > I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. > > Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... > > Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". > > I don't want to be offensive, just voice my concern... > > I agree with Thomas here. > me too - check the date :) From tim.nieradzik at gmx.de Wed Apr 1 20:20:27 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Wed Apr 1 20:21:01 2009 Subject: [Dillo-dev] Segfault on sites requiring authentication In-Reply-To: <20090401164524.GC9874@local.gobigwest.com> References: <20090401005230.GF11082@tux.tuxnet> <20090401164524.GC9874@local.gobigwest.com> Message-ID: <20090401182027.GD29830@tux.tuxnet> > I'm not seeing this crash. Is it going through the for loop and > getting set to NULL in Client_bw = ClientWeb->bw;, or is it > NULL because there weren't any clients and it didn't execute that code? Yes, it is going through the loop. Probably comparing Client->Url with entry->Url fails. As a result, ClientWeb and Client_bw do not get set. Have you also tried reloading the page? Sometimes it does not get loaded properly here. Anyway, it is odd that Dillo does not crash for you. Are you using the latest trunk? --Tim From tim.nieradzik at gmx.de Wed Apr 1 20:24:50 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Wed Apr 1 20:25:23 2009 Subject: [Dillo-dev] [PATCH] startup window In-Reply-To: <20090401181132.GA1650@blob.baaderstrasse.com> References: <20090401074711.GA927@blob.baaderstrasse.com> <20090401123249.6f64dbe2@sunscreen.local> <20090401164944.GD9874@local.gobigwest.com> <20090401181132.GA1650@blob.baaderstrasse.com> Message-ID: <20090401182450.GE29830@tux.tuxnet> Heh, that is what I had in mind all the time. However, nice idea for an April Fool's hoax. :) --Tim From corvid at lavabit.com Wed Apr 1 21:44:29 2009 From: corvid at lavabit.com (corvid) Date: Wed Apr 1 22:13:46 2009 Subject: [Dillo-dev] Segfault on sites requiring authentication In-Reply-To: <20090401182027.GD29830@tux.tuxnet> References: <20090401005230.GF11082@tux.tuxnet> <20090401164524.GC9874@local.gobigwest.com> <20090401182027.GD29830@tux.tuxnet> Message-ID: <20090401194428.GE9874@local.gobigwest.com> Tim wrote: > > I'm not seeing this crash. Is it going through the for loop and > > getting set to NULL in Client_bw = ClientWeb->bw;, or is it > > NULL because there weren't any clients and it didn't execute that code? > > Yes, it is going through the loop. Probably comparing Client->Url > with entry->Url fails. As a result, ClientWeb and Client_bw do not > get set. It would be good to find out what it's doing exactly for you. - I'd expect a client to be waiting for it in this case. - I think a client shouldn't ever have a NULL bw. - The case where there are no clients waiting for the URL does sound like a bug, although I think I'd be tempted just not to call Cache_auth_entry() if the bw was NULL. > Have you also tried reloading the page? Sometimes it does not get > loaded properly here. Anyway, it is odd that Dillo does not crash > for you. Are you using the latest trunk? Reloading doesn't crash it for me. Yes, I'm using the latest code. You mentioned the other day that you get a lot of crashes in general, and I was surprised because I've had a total of three random crashes since 2.0 was released. From Johannes.Hofmann at gmx.de Wed Apr 1 22:16:41 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Wed Apr 1 22:17:39 2009 Subject: [Dillo-dev] Warnings in src/IO/dpi.c and lout/misc.hh In-Reply-To: <20090327120714.GA3875@blob.baaderstrasse.com> References: <20090326225854.GA3151@assam> <20090327120714.GA3875@blob.baaderstrasse.com> Message-ID: <20090401201641.GA4290@blob.baaderstrasse.com> On Fri, Mar 27, 2009 at 01:07:14PM +0100, Hofmann Johannes wrote: > Hi, > > On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > > dpi.c: In function ?a_Dpi_bye_dpid?: > > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > Can you please check whether attached patches fix the warnings? Michal, do the patches fix the warnings for you? Cheers, Johannes > > @all: please have a look at the dpi.c fix. > > Cheers, > Johannes > diff -r b06377790b00 src/IO/dpi.c > --- a/src/IO/dpi.c Thu Mar 26 23:18:02 2009 +0000 > +++ b/src/IO/dpi.c Fri Mar 27 13:05:11 2009 +0100 > @@ -371,7 +371,7 @@ static char *Dpi_get_dpid_uds_dir(void) > { > FILE *in; > char *saved_name_filename; /* :) */ > - char dpid_uds_dir[256], *p = NULL; > + char buf[256], *dpid_uds_dir, *p = NULL, *p1; > > saved_name_filename = > dStrconcat(dGethomedir(), "/.dillo/dpi_socket_dir", NULL); > @@ -379,14 +379,16 @@ static char *Dpi_get_dpid_uds_dir(void) > dFree(saved_name_filename); > > if (in != NULL) { > - fgets(dpid_uds_dir, 256, in); > + dpid_uds_dir = fgets(buf, sizeof(buf), in); > fclose(in); > - if ((p = strchr(dpid_uds_dir, '\n'))) { > - *p = 0; > - } > - if (access(dpid_uds_dir, F_OK) == 0) { > - p = dStrdup(dpid_uds_dir); > - _MSG("Dpi_get_dpid_uds_dir:: %s\n", p); > + if (dpid_uds_dir) { > + if ((p1 = strchr(dpid_uds_dir, '\n'))) { > + *p1 = 0; > + } > + if (access(dpid_uds_dir, F_OK) == 0) { > + p = dStrdup(dpid_uds_dir); > + _MSG("Dpi_get_dpid_uds_dir:: %s\n", p); > + } > } > } > > @@ -730,7 +732,9 @@ void a_Dpi_bye_dpid() > MSG("%s\n", sa.sun_path); > } > DpiBye_cmd = a_Dpip_build_cmd("cmd=%s", "DpiBye"); > - (void) write(new_socket, DpiBye_cmd, strlen(DpiBye_cmd)); > + if (write(new_socket, DpiBye_cmd, strlen(DpiBye_cmd)) != > + (ssize_t) strlen(DpiBye_cmd)) > + MSG_WARN("Failed to send DpiBye\n"); > dFree(DpiBye_cmd); > Dpi_close_fd(new_socket); > } > diff -r b06377790b00 lout/misc.hh > --- a/lout/misc.hh Thu Mar 26 23:18:02 2009 +0000 > +++ b/lout/misc.hh Fri Mar 27 12:52:36 2009 +0100 > @@ -178,7 +178,7 @@ public: > */ > inline T get (int i) { > if (BOUND_CHECKING) > - assert (i >= 0 && i < this->num); > + assert (i >= 0 && this->num - i > 0); > return this->array[i]; > } > > @@ -192,7 +192,7 @@ public: > */ > inline void set (int i, T t) { > if (BOUND_CHECKING) > - assert (i >= 0 && i < this->num); > + assert (i >= 0 && this->num - i > 0); > this->array[i] = t; > } > }; From newman.x at gmail.com Wed Apr 1 23:53:29 2009 From: newman.x at gmail.com (Michal Nowak) Date: Wed Apr 1 23:54:26 2009 Subject: [Dillo-dev] Warnings in src/IO/dpi.c and lout/misc.hh In-Reply-To: <20090401201641.GA4290@blob.baaderstrasse.com> References: <20090326225854.GA3151@assam> <20090327120714.GA3875@blob.baaderstrasse.com> <20090401201641.GA4290@blob.baaderstrasse.com> Message-ID: <20090401215328.GB18892@assam.redhat.com> On Wed, Apr 01, 2009 at 10:16:41PM +0200, Hofmann Johannes wrote: > On Fri, Mar 27, 2009 at 01:07:14PM +0100, Hofmann Johannes wrote: > > Hi, > > > > On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > > > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > > > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > > > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > > > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > > > dpi.c: In function ?a_Dpi_bye_dpid?: > > > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > > > > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > > > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > > > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > > > Can you please check whether attached patches fix the warnings? > > Michal, do the patches fix the warnings for you? > > Cheers, > Johannes Yes, the mentioned warnings are fixed now, thanks Johannes! But one more emerged due to recent clean up, see follow-up email. Michal > > > > > @all: please have a look at the dpi.c fix. > > > > Cheers, > > Johannes > > > diff -r b06377790b00 src/IO/dpi.c > > --- a/src/IO/dpi.c Thu Mar 26 23:18:02 2009 +0000 > > +++ b/src/IO/dpi.c Fri Mar 27 13:05:11 2009 +0100 > > @@ -371,7 +371,7 @@ static char *Dpi_get_dpid_uds_dir(void) > > { > > FILE *in; > > char *saved_name_filename; /* :) */ > > - char dpid_uds_dir[256], *p = NULL; > > + char buf[256], *dpid_uds_dir, *p = NULL, *p1; > > > > saved_name_filename = > > dStrconcat(dGethomedir(), "/.dillo/dpi_socket_dir", NULL); > > @@ -379,14 +379,16 @@ static char *Dpi_get_dpid_uds_dir(void) > > dFree(saved_name_filename); > > > > if (in != NULL) { > > - fgets(dpid_uds_dir, 256, in); > > + dpid_uds_dir = fgets(buf, sizeof(buf), in); > > fclose(in); > > - if ((p = strchr(dpid_uds_dir, '\n'))) { > > - *p = 0; > > - } > > - if (access(dpid_uds_dir, F_OK) == 0) { > > - p = dStrdup(dpid_uds_dir); > > - _MSG("Dpi_get_dpid_uds_dir:: %s\n", p); > > + if (dpid_uds_dir) { > > + if ((p1 = strchr(dpid_uds_dir, '\n'))) { > > + *p1 = 0; > > + } > > + if (access(dpid_uds_dir, F_OK) == 0) { > > + p = dStrdup(dpid_uds_dir); > > + _MSG("Dpi_get_dpid_uds_dir:: %s\n", p); > > + } > > } > > } > > > > @@ -730,7 +732,9 @@ void a_Dpi_bye_dpid() > > MSG("%s\n", sa.sun_path); > > } > > DpiBye_cmd = a_Dpip_build_cmd("cmd=%s", "DpiBye"); > > - (void) write(new_socket, DpiBye_cmd, strlen(DpiBye_cmd)); > > + if (write(new_socket, DpiBye_cmd, strlen(DpiBye_cmd)) != > > + (ssize_t) strlen(DpiBye_cmd)) > > + MSG_WARN("Failed to send DpiBye\n"); > > dFree(DpiBye_cmd); > > Dpi_close_fd(new_socket); > > } > > > diff -r b06377790b00 lout/misc.hh > > --- a/lout/misc.hh Thu Mar 26 23:18:02 2009 +0000 > > +++ b/lout/misc.hh Fri Mar 27 12:52:36 2009 +0100 > > @@ -178,7 +178,7 @@ public: > > */ > > inline T get (int i) { > > if (BOUND_CHECKING) > > - assert (i >= 0 && i < this->num); > > + assert (i >= 0 && this->num - i > 0); > > return this->array[i]; > > } > > > > @@ -192,7 +192,7 @@ public: > > */ > > inline void set (int i, T t) { > > if (BOUND_CHECKING) > > - assert (i >= 0 && i < this->num); > > + assert (i >= 0 && this->num - i > 0); > > this->array[i] = t; > > } > > }; > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- Regards, Michal Nowak From newman.x at gmail.com Thu Apr 2 00:11:27 2009 From: newman.x at gmail.com (Michal Nowak) Date: Thu Apr 2 00:12:22 2009 Subject: [Dillo-dev] http.c:500: warning: unused =?utf-8?q?parameter_=E2=80=98Data2?= =?utf-8?b?4oCZ?= Message-ID: <20090401221126.GC18892@assam.redhat.com> gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT http.o -MD -MP -MF .deps/http.Tpo -c -o http.o http.c http.c: In function ?a_Http_ccc?: http.c:500: warning: unused parameter ?Data2? gcc-4.3.2-7.i386 Emerged in recent days. -- Regards, Michal Nowak From tim.nieradzik at gmx.de Thu Apr 2 03:26:59 2009 From: tim.nieradzik at gmx.de (Tim Nieradzik) Date: Thu Apr 2 03:27:31 2009 Subject: [Dillo-dev] Segfault on sites requiring authentication In-Reply-To: <20090401194428.GE9874@local.gobigwest.com> References: <20090401005230.GF11082@tux.tuxnet> <20090401164524.GC9874@local.gobigwest.com> <20090401182027.GD29830@tux.tuxnet> <20090401194428.GE9874@local.gobigwest.com> Message-ID: <20090402012659.GF29830@tux.tuxnet> > It would be good to find out what it's doing exactly for you. > - I'd expect a client to be waiting for it in this case. The client does not exist anymore because it has been destroyed too early. That is why I removed the timer in the previous patch. Debugging asynchronous code is difficult. I compiled Dillo with debugging symbols and added some printf()'s to see what is going on in detail. Afterwards I ran the binary through gdb. When visiting http://puppyisos.org/isos, everything looks alright in the beginning. The dialog pops up as expected. It is curious that we loop two times over ClientQueue though. Probably because the function is called every x received bytes, right? [New Thread 0xf760bb90 (LWP 14474)] [Thread 0xf760bb90 (LWP 14474) exited] Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Removing client (id=0) It seems that after confirming the authentication dialog, the page is being reloaded but without the header that is necessary for the HTTP authentication... Reloading page with authentication credentials... Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos... Found (id=0). Removing client (id=0) At least this would explain, why the client for http://puppyisos.org/isos was deleted. Now the page is reloaded again because suddenly there is a client for http://puppyisos.org/isos/ again (with id=0): Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Found (id=0). Removing client (id=0) Looping over ClientQueue... Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... Found (id=1). HTTP warning: unhandled MIME type: "text/html; charset=iso-8859-1" Looping over ClientQueue... Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... Found (id=1). Removing client (id=1) We should add support for charsets within MIME types anytime. As far as I know, Dillo only depends on meta-tags when deciding which encoding to go with. This notation is officially approved, see: http://www.w3.org/International/tutorials/tutorial-char-enc/#Slide0270 Reloading page with authentication credentials... Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Looping over ClientQueue... Looking for http://puppyisos.org/isos/... Not found! Reloading page with authentication credentials... Why was the site reloaded again? Interestingly, no new client has been created for /isos this time. I am a bit astonished how often Cache_auth_callback() is called even though the dialog only appears once. Everything looks a bit asynchronous. An evidence might be the following lines: Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... In general, there should be a "Found (id=...)." or at least a "Not found!'" but they just follow after each other. And now it crashes: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf79bf6d0 (LWP 14340)] 0x0805ba14 in a_Nav_cancel_expect (bw=0x0) at nav.c:250 250 if (bw->nav_expecting) { Here is the back trace: (gdb) bt #0 0x0805ba14 in a_Nav_cancel_expect (bw=0x0) at nav.c:250 #1 0x0805c098 in a_Nav_reload (bw=0x0) at nav.c:474 #2 0x0805dd4e in Cache_auth_callback (vdata=0x8252208) at cache.c:971 #3 0xf7f23e75 in fltk::wait () from /usr/lib/libfltk2.so #4 0xf7f23f88 in fltk::run () from /usr/lib/libfltk2.so #5 0x0804f686 in main (argc=1, argv=0xffdf7b74) at dillo.cc:333 > - I think a client shouldn't ever have a NULL bw. I agree. > - The case where there are no clients waiting for the URL > does sound like a bug, although I think I'd be tempted > just not to call Cache_auth_entry() if the bw was NULL. Unfortunately, that did not really help. Well, Dillo does not crash anymore but no images on this page are shown and it reloads several times before anything gets displayed. > Reloading doesn't crash it for me. > Yes, I'm using the latest code. In contrast to /isos, the main page (http://puppyisos.org/) is working alright here. No crashes, all images are displayed properly. There are some other directory listings on that site which are working, too even though there syntax is quite similar to /isos'. > You mentioned the other day that you get a lot of crashes in general, > and I was surprised because I've had a total of three random crashes > since 2.0 was released. The situation has improved since I am browsing with the latest trunk. Nevertheless, I still experience non-reproducible crashes sometimes: It happens frequently that dpid ``crashes'' (100% CPU consumption). This happens mostly when domain names cannot be resolved correctly. Trying to reload the page does not solve it. I have to kill the process manually. PS: Having applied the patch, the iterations of the ClientQueue loop will now stop after the URL has matched. Previously, the iteration for the same entry item was then repeated again (if AbortEntry is true). Is there a reason for keeping it as-is? --Tim -------------- next part -------------- diff -r f8b1844a4fc7 src/cache.c --- a/src/cache.c Sat Mar 28 16:08:04 2009 +0100 +++ b/src/cache.c Thu Apr 02 01:25:57 2009 +0000 @@ -966,8 +966,10 @@ static void Cache_auth_callback(void *vdata) { CacheAuthData_t *data = (CacheAuthData_t *)vdata; - if (a_Auth_do_auth(data->auth, data->url)) + if (a_Auth_do_auth(data->auth, data->url)) { + printf("Reloading page with authentication credentials...\n"); a_Nav_reload(data->bw); + } Cache_auth_free(data->auth); a_Url_free(data->url); dFree(data); @@ -1056,6 +1058,7 @@ bool_t AbortEntry = FALSE; bool_t OfferDownload = FALSE; bool_t TypeMismatch = FALSE; + bool_t found = FALSE; if (Busy) MSG_ERR("FATAL!: >>>> Cache_process_queue Caught busy!!! <<<<\n"); @@ -1077,9 +1080,18 @@ return; /* i.e., wait for more data */ } + printf("Looping over ClientQueue...\n"); Busy = TRUE; for (i = 0; (Client = dList_nth_data(ClientQueue, i)); ++i) { + AbortEntry = FALSE; + OfferDownload = FALSE; + TypeMismatch = FALSE; + + printf("Looking for %s...\n", Client->Url->url_string->str); + if (Client->Url == entry->Url) { + printf("Found (id=%d).\n", i); + found = TRUE; ClientWeb = Client->Web; /* It was a (void*) */ Client_bw = ClientWeb->bw; /* 'bw' in a local var */ @@ -1139,8 +1151,7 @@ if (AbortEntry) { a_Bw_remove_client(Client_bw, Client->Key); Cache_client_dequeue(Client, NULLKey); - --i; /* Keep the index value in the next iteration */ - continue; + break; } } @@ -1162,6 +1173,7 @@ /* Remove client when done */ if (entry->Flags & CA_GotData) { + printf("Removing client (id=%d)\n", i); /* Copy flags to a local var */ int flags = ClientWeb->flags; /* We finished sending data, let the client know */ @@ -1169,15 +1181,20 @@ if (ClientWeb->flags & WEB_RootUrl) a_UIcmd_set_page_prog(Client_bw, 0, 0); Cache_client_dequeue(Client, NULLKey); - --i; /* Keep the index value in the next iteration */ /* within CA_GotData, we assert just one redirect call */ if (entry->Flags & CA_Redirect) Cache_redirect(entry, flags, Client_bw); } + + break; } } /* for */ + if (!found) { + printf("Not found!\n"); + } + if (AbortEntry) { /* Abort the entry, remove it from cache, and maybe offer download. */ DilloUrl *url = a_Url_dup(entry->Url); diff -r f8b1844a4fc7 src/nav.c --- a/src/nav.c Sat Mar 28 16:08:04 2009 +0100 +++ b/src/nav.c Thu Apr 02 01:25:57 2009 +0000 @@ -268,8 +268,6 @@ DilloUrl *url; char *fragment = NULL; - dReturn_if_fail(bw != NULL); - if (bw->nav_expecting) { url = bw->nav_expect_url; reload = (URL_FLAGS(url) & URL_ReloadPage); @@ -334,8 +332,6 @@ */ void a_Nav_push(BrowserWindow *bw, const DilloUrl *url) { - dReturn_if_fail (bw != NULL); - if (bw->nav_expecting && !a_Url_cmp(bw->nav_expect_url, url) && !strcmp(URL_FRAGMENT(bw->nav_expect_url),URL_FRAGMENT(url))) { /* we're already expecting that url (most probably a double-click) */ @@ -383,7 +379,6 @@ */ void a_Nav_repush(BrowserWindow *bw) { - dReturn_if_fail (bw != NULL); MSG(">>> a_Nav_repush <<<<\n"); a_Timeout_add(0.0, Nav_repush_callback, (void*)bw); } From corvid at lavabit.com Thu Apr 2 08:09:30 2009 From: corvid at lavabit.com (corvid) Date: Thu Apr 2 08:12:10 2009 Subject: [Dillo-dev] Segfault on sites requiring authentication In-Reply-To: <20090402012659.GF29830@tux.tuxnet> References: <20090401005230.GF11082@tux.tuxnet> <20090401164524.GC9874@local.gobigwest.com> <20090401182027.GD29830@tux.tuxnet> <20090401194428.GE9874@local.gobigwest.com> <20090402012659.GF29830@tux.tuxnet> Message-ID: <20090402060930.GA17730@local.gobigwest.com> Tim wrote: > It is curious that we > loop two times over ClientQueue though. Probably because the > function is called every x received bytes, right? a_Cache_process_dbuf calls Cache_process_queue once for each packet and once when it's done (IOClose). > Looking for http://puppyisos.org/miniicons/kfm_home.png... > Looking for http://puppyisos.org/miniicons/ark.png... > Found (id=1). > HTTP warning: unhandled MIME type: "text/html; charset=iso-8859-1" > Looping over ClientQueue... > Looking for http://puppyisos.org/miniicons/kfm_home.png... > Looking for http://puppyisos.org/miniicons/ark.png... > Found (id=1). > Removing client (id=1) > > We should add support for charsets within MIME types anytime. As far > as I know, Dillo only depends on meta-tags when deciding which > encoding to go with. This notation is officially approved, see: > http://www.w3.org/International/tutorials/tutorial-char-enc/#Slide0270 Charsets in MIME types are supported. It's probably complaining because it expected an image/png and got the text/html; charset=iso-8859-1 401 Auth page which can't be displayed as an image. > PS: Having applied the patch, the iterations of the ClientQueue loop > will now stop after the URL has matched. Previously, the iteration > for the same entry item was then repeated again (if AbortEntry is > true). Is there a reason for keeping it as-is? In case multiple clients were waiting for this data. Now I _am_ getting the crash. Maybe I accidentally typed in the main page instead. Don't think I did, but...whatever...anyway... in Cache_auth_callback(), a_Nav_reload(data->bw) does not sound at all like what we want for images on a page. We'd want something more along the lines of Cache_entry_remove() on the image and a_Nav_repush() on the page, but I think in either case that would remove clients for other images while we're trying to get their data, causing...what we're seeing. (Is dillo turning into a snarled knot?) If the last image comes in while there's no client, I wouldn't know what bw to repush. From jcid at dillo.org Thu Apr 2 14:50:34 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Apr 2 14:48:51 2009 Subject: [Dillo-dev] [PATCH] startup window In-Reply-To: <20090401164944.GD9874@local.gobigwest.com> References: <20090401074711.GA927@blob.baaderstrasse.com> <20090401123249.6f64dbe2@sunscreen.local> <20090401164944.GD9874@local.gobigwest.com> Message-ID: <20090402125034.GC6239@dillo.org> On Wed, Apr 01, 2009 at 04:49:44PM +0000, corvid wrote: > Thomas wrote: > > Am Wed, 1 Apr 2009 09:47:11 +0200 > > schrieb Hofmann Johannes : > > > > > Hi, > > > attached patch adds a proper startup screen for dillo. > > > > Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? > > I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. > > Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... > > Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". > > I don't want to be offensive, just voice my concern... > > I agree with Thomas here. Me too. -- Cheers Jorge.- From jcid at dillo.org Thu Apr 2 14:53:29 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Apr 2 14:51:47 2009 Subject: [Dillo-dev] [PATCH] startup window In-Reply-To: <20090401181132.GA1650@blob.baaderstrasse.com> References: <20090401074711.GA927@blob.baaderstrasse.com> <20090401123249.6f64dbe2@sunscreen.local> <20090401164944.GD9874@local.gobigwest.com> <20090401181132.GA1650@blob.baaderstrasse.com> Message-ID: <20090402125329.GD6239@dillo.org> On Wed, Apr 01, 2009 at 08:11:32PM +0200, Hofmann Johannes wrote: > On Wed, Apr 01, 2009 at 04:49:44PM +0000, corvid wrote: > > Thomas wrote: > > > Am Wed, 1 Apr 2009 09:47:11 +0200 > > > schrieb Hofmann Johannes : > > > > > > > Hi, > > > > attached patch adds a proper startup screen for dillo. > > > > > > Oh, is dillo slow enough now that it needs a splash screen distracting the user while waiting for startup? > > > I sort of like the "instant startup" behaviour. A splash startup screen reminds you of the startup _not_ being instant. > > > Especially opening an extra window wastes CPU cycles, even in X11, that could be used on doing the actual work... > > > Of course I'll have to check out a current dillo2 to see how eminent the issue really is. But when we reach the startup speed of e.g. the GIMP with it's endless loading of plugins etc., one can safely declare dillo "just another bloated browser". > > > I don't want to be offensive, just voice my concern... > > > > I agree with Thomas here. > > > > me too - check the date :) Good one! I should have suggested using Gecko... :-) -- Cheers Jorge.- From jcid at dillo.org Thu Apr 2 14:56:25 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Apr 2 14:54:40 2009 Subject: [Dillo-dev] http.c:500: warning: unused parameter ???Data2??? In-Reply-To: <20090401221126.GC18892@assam.redhat.com> References: <20090401221126.GC18892@assam.redhat.com> Message-ID: <20090402125625.GE6239@dillo.org> On Thu, Apr 02, 2009 at 12:11:27AM +0200, Michal Nowak wrote: > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT http.o -MD -MP -MF .deps/http.Tpo -c -o http.o http.c > http.c: In function ???a_Http_ccc???: > http.c:500: warning: unused parameter ???Data2??? > > gcc-4.3.2-7.i386 > > Emerged in recent days. Yes, it's visible since the addition of the "-W" flag. Data2 is a generic parameter used with CCC that is not used by http.c. No real problem here. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Thu Apr 2 17:10:16 2009 From: Johannes.Hofmann at gmx.de (Hofmann Johannes) Date: Thu Apr 2 17:11:13 2009 Subject: [Dillo-dev] Warnings in src/IO/dpi.c and lout/misc.hh In-Reply-To: <20090401215328.GB18892@assam.redhat.com> References: <20090326225854.GA3151@assam> <20090327120714.GA3875@blob.baaderstrasse.com> <20090401201641.GA4290@blob.baaderstrasse.com> <20090401215328.GB18892@assam.redhat.com> Message-ID: <20090402151016.GA2425@blob.baaderstrasse.com> On Wed, Apr 01, 2009 at 11:53:29PM +0200, Michal Nowak wrote: > On Wed, Apr 01, 2009 at 10:16:41PM +0200, Hofmann Johannes wrote: > > On Fri, Mar 27, 2009 at 01:07:14PM +0100, Hofmann Johannes wrote: > > > Hi, > > > > > > On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > > > > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > > > > > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > > > > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > > > > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > > > > dpi.c: In function ?a_Dpi_bye_dpid?: > > > > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > > > > > > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > > > > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > > > > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > > > > > Can you please check whether attached patches fix the warnings? > > > > Michal, do the patches fix the warnings for you? > > > > Cheers, > > Johannes > > Yes, the mentioned warnings are fixed now, thanks Johannes! Ok, also committed the second part now. Cheers, Johannes From iveqy at iveqy.com Fri Apr 3 21:41:00 2009 From: iveqy at iveqy.com (Fredrik Gustafsson) Date: Fri Apr 3 21:44:19 2009 Subject: [Dillo-dev] bugg 903, correcting problems Message-ID: <20090403194100.GA18276@paksenarrion.gulon> Hi, after submitting bug 903 I started to work an a solution. (bugg desc. added below for your convinience). 903 Impact: feature fault At: run time Type: misbehaviour Comments: