- Dillo-dev - lists.mailman3.com

Re: Dillo-dev digest, Vol 1 #100 - 6 msgs

by linux seaq

> Onto another topic: > > A last minute leak fix (iterators) left dillo a bit unstable. > We knew the iterators had a leak and it's great to have found it. > Now it will take some extra time to try to fix the problem and, > after that, stress-test the Copy&Paste code again. > > We haven't got an accurate procedure to reproduce the crash > (yet). This explanation may help: > > <q> > I think I have found a relatively new segfault bug : > You need some sort of thumbtags like the screenshots on > http://www.incagold.com/products/Speed/speedthief.php > > Now you have to move down the mouse and at the same time click > on one image (i.e. click while still aiming for the image). > If the button-push occures outside the image and the button-release > inside the image, chances are high to get a segfault. This > is a bit hard to reproduce, but I couldn't get an older version > with selection to behave like that. It also happened a few > times to me last night (after the last 'cvs up') but never before. > </q> > HI i'm having that problem when the page is not entirely downloaded and i'm scrolling down the page and selecting some text, it segfaults.. it happens sometimes not always, so the conditions may vary.. i`m using the cvs from 06/04 when i used an earlier cvs update (just after select cvs commit) it ocurred*a lot more times* than now. --- Andres Mauricio Mujica SEAQ SERVICIOS CIA LTDA www.seaq.com.co

April 28, 2003

Re: [Dillo-dev] Copy&Paste bug BINGO!!!

by Jorge Arellano Cid

Hi there, > > [...] > > I believe the functions that may have side effects on their > > arguments should use an API that somehow reflects that. For > > instance: > > > > DwExtIterator* a_Dw_ext_iterator_new (DwIterator *it); > > Should be > > DwExtIterator* a_Dw_ext_iterator_new (DwIterator **it); > ^^ Yeah, just a typo. > Another possibility would be to define wrapper macros: > > #define a_Dw_ext_iterator_new(it) _a_Dw_ext_iterator_new(&it) > > DwExtIterator* _a_Dw_ext_iterator_new (DwIterator **it); > > but that's a bit kludgy for my taste. Yep. > > The same applies for a_Dw_iterator_free() and friends. > > It should be quite obvious that functions ending on "_free", > "_destroy" etc. have a side-effect of their argument, so I'd keep this > and regard it as an exception. a_Dw_ext_iterator_new is another case, > and very confusing, so this one should be fixed. Hem, that's what I meant (rush writing). > > BTW, the > > first approach I wrote was to force a_Dw_iterator_free to make > > NULL its argument). > > Very useful for debugging! :-) That was the idea! > > Well, that's it. As I don't know the iterators code as well as > > Sebastian, I'll let him make the decisions. > > Well, first I'd use this change for the release, and fix it for > 0.7.3. A grep for "a_Dw_ext_iterator_new" shows that this is handled > correctly elsewhere. OK guys, please give Copy&Paste some hard testing. If it shows no problems, I'll probably make the final touches this Monday and try to make a release on Tuesday. > Perhaps it is cleaner to remove the side-effect completely, That sounds good and clean. > by letting > a_Dw_ext_iterator_new putting a clone on top of the stack, so that the > callers must free the simple iterator. This would be a bit slower, but > compared to that, a_Dw_ext_iterator_new creates anyway quite a couple > of DwIterator's. Has to be tested. Yes, probably 0.7.3 will require some profiling and tunning. > (Thorben: As far as I can say from a first gprof run, this is not the > critical code, so the problem is not made worse.) This problem certainly is worth an investigation. Let it be on 0.7.3. Cheers Jorge.-

April 26, 2003

Re: [Dillo-dev] Copy&Paste bug BINGO!!!

by Sebastian Geerken

On Fri, Apr 25, Jorge Arellano Cid wrote: > After some hard code revisions, I decided to "eat" Valgrind's > manual, install it and BINGO!: > > [...] > > What does this mean? > > As a_Dw_ext_iterator_new(it) may _free_ 'it', 'it' should no > longer be used after that call. That was the case with the page > (right-click test case). > > I commited a short _code_change_ that avoids the problem. It is > not a "patch" but just illustrative code. > > I believe the functions that may have side effects on their > arguments should use an API that somehow reflects that. For > instance: > > DwExtIterator* a_Dw_ext_iterator_new (DwIterator *it); Should be DwExtIterator* a_Dw_ext_iterator_new (DwIterator **it); ^^ > and be used like: > > a_Dw_ext_iterator_new(&it); > > so 'it' can be NULL at return time. Another possibility would be to define wrapper macros: #define a_Dw_ext_iterator_new(it) _a_Dw_ext_iterator_new(&it) DwExtIterator* _a_Dw_ext_iterator_new (DwIterator **it); but that's a bit kludgy for my taste. > The same applies for a_Dw_iterator_free() and friends. It should be quite obvious that functions ending on "_free", "_destroy" etc. have a side-effect of their argument, so I'd keep this and regard it as an exception. a_Dw_ext_iterator_new is another case, and very confusing, so this one should be fixed. > BTW, the > first approach I wrote was to force a_Dw_iterator_free to make > NULL its argument). Very useful for debugging! :-) > Well, that's it. As I don't know the iterators code as well as > Sebastian, I'll let him make the decisions. Well, first I'd use this change for the release, and fix it for 0.7.3. A grep for "a_Dw_ext_iterator_new" shows that this is handled correctly elsewhere. Perhaps it is cleaner to remove the side-effect completely, by letting a_Dw_ext_iterator_new putting a clone on top of the stack, so that the callers must free the simple iterator. This would be a bit slower, but compared to that, a_Dw_ext_iterator_new creates anyway quite a couple of DwIterator's. Has to be tested. (Thorben: As far as I can say from a first gprof run, this is not the critical code, so the problem is not made worse.) Sebastian

April 26, 2003

Copy&Paste bug BINGO!!!

by Jorge Arellano Cid

Hi there, After some hard code revisions, I decided to "eat" Valgrind's manual, install it and BINGO!: <q> ==6797== ==6797== Invalid memory access of size 4 ==6797== at 0x80662B3: a_Selection_button_press (selection.c:142) ==6797== by 0x805EB8F: Dw_page_send_selection_event (dw_page.c:1486) ==6797== by 0x805EE47: Dw_page_button_press (dw_page.c:1499) ==6797== by 0x806474D: Dw_widget_mouse_event (dw_widget.c:740) ==6797== Address 0x40D714F0 is 0 bytes inside a block of size 52 free'd ==6797== at 0x40148050: free (in /usr/local/lib/valgrind/valgrind.so) ==6797== by 0x403C1FE8: g_free (in /usr/lib/libglib-1.2.so.0.0.10) ==6797== by 0x8057CA1: a_Dw_ext_iterator_new (dw_ext_iterator.c:171) ==6797== by 0x8066286: a_Selection_button_press (selection.c:136) </q> What does this mean? As a_Dw_ext_iterator_new(it) may _free_ 'it', 'it' should no longer be used after that call. That was the case with the page (right-click test case). I commited a short _code_change_ that avoids the problem. It is not a "patch" but just illustrative code. I believe the functions that may have side effects on their arguments should use an API that somehow reflects that. For instance: DwExtIterator* a_Dw_ext_iterator_new (DwIterator *it); and be used like: a_Dw_ext_iterator_new(&it); so 'it' can be NULL at return time. The same applies for a_Dw_iterator_free() and friends. BTW, the first approach I wrote was to force a_Dw_iterator_free to make NULL its argument). Well, that's it. As I don't know the iterators code as well as Sebastian, I'll let him make the decisions. Hope this helps Happy :) Jorge.-

April 25, 2003

Re: [Dillo-dev] Bookmarks

by Andreas Schweitzer

Hi > > Are there any plans to reintroduce a bookmarks menu? Any patches for it? > > Not really. Although dpis will have a way of setting menu items > someday, it's very unlikely it will be enough to make a good > implementation from it. I think, if the dpi sticks to one bookmark file syntax, dillo should be able to read it - maybe even via a dpi call - and then *only* display it when - let's say - clicking the right mouse button on the bookmark icon. > It is possible to make a dpi that uses a plain GTK+ interface > for bookmarks (think of a dpi as an external program that > communicates with dillo using the dpi protocol), but this > probably would be an overkill for your problem. Actually, in my quest to learn a bit of GTK, I modified the current bookmark server, so that it accepts one more command, which then will pop up a GTK-Gui. So far it only pops up some parts of the GTK tutorial :-) .... but it is kind of cool. The bm server itself returns a webpage that has a link which will fire up the GUI (just like the "modify" link). Alternatively, I modified dillo to directly fire up the bm-gui by pressing the middle mouse button on the bookmark icon (hey there are all three buttons used now ;-) ...) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

April 25, 2003

Re: [Dillo-dev] Bookmarks

by Victor Sahlstedt

On Tue, 22 Apr 2003 16:45:25 -0500 Lars Clausen <lrclause(a)cs.uiuc.edu> wrote: > While the page looks nifty for the editing, I really don't like getting an > extra bookmark page into my history stack every time I want to go to a > bookmark. Agreed. The way Dillo handle bookmarks nowadays is such a hassle that I usually end up just typing the url (whenever I can remember it). Editing bookmarks is quite unconvenient too, unfortunately. - Victor

April 25, 2003

Re: [Dillo-dev] Delayed release

by Phil Pennock

On 2003-04-24 at 20:31 +0200, Andreas Schweitzer wrote: > Here is an alternative method : simply RIGHT-click > on the thumbnails in said page : > http://www.incagold.com/products/Speed/speedthief.php Ah, that did it, I was finally able to reproduce. > Curiously, on FreeBSD I "only" get a > Gtk-WARNING **: gtk_signal_emit_by_name(): could not find signal "link_pressed" in the `DwTable' class ancestry > a second attempt to right click the image will pop up > the menu. FreeBSD 4.7, x86, dumped core on sigsegv. Stack backtrace: -----------------------------< cut here >------------------------------- #0 0x283df1d6 in strncpy () from /usr/lib/libc_r.so.4 #1 0x28273f0e in g_strndup () from /usr/local/lib/libglib12.so.3 #2 0x80671e9 in Selection_copy (selection=0x80eb560) at selection.c:379 #3 0x8066dfc in a_Selection_button_release (selection=0x80eb560, it=0x8281500, char_pos=0, link=39, event=0x80f6018, within_content=1) at selection.c:202 #4 0x805f916 in Dw_page_send_selection_event (page=0x8123e00, fn=0x8066cb8 <a_Selection_button_release>, x=178, y=320, event=0x80f6018) at dw_page.c:1486 #5 0x805f98b in Dw_page_button_release (widget=0x8123e00, x=178, y=320, event=0x80f6018) at dw_page.c:1513 #6 0x80651c3 in Dw_widget_mouse_event (widget=0x811b700, viewwidget=0x80c0b00, x=283, y=1175, event=0x80f6018) at dw_widget.c:740 #7 0x805b86c in Dw_gtk_viewport_mouse_event (widget=0x80c0b00, x=283, y=330, event=0x80f6018) at dw_gtk_viewport.c:358 #8 0x805b940 in Dw_gtk_viewport_button_release (widget=0x80c0b00, event=0x80f6018) at dw_gtk_viewport.c:389 #9 0x2818ce93 in gtk_marshal_BOOL__POINTER () from /usr/X11R6/lib/libgtk12.so.2 #10 0x281bced6 in gtk_signal_real_emit () from /usr/X11R6/lib/libgtk12.so.2 #11 0x281baef3 in gtk_signal_emit () from /usr/X11R6/lib/libgtk12.so.2 #12 0x281f2f6c in gtk_widget_event () from /usr/X11R6/lib/libgtk12.so.2 #13 0x2818cde5 in gtk_propagate_event () from /usr/X11R6/lib/libgtk12.so.2 #14 0x2818bf56 in gtk_main_do_event () from /usr/X11R6/lib/libgtk12.so.2 #15 0x2823c87c in gdk_event_dispatch () from /usr/X11R6/lib/libgdk12.so.2 #16 0x2826acf3 in g_main_dispatch () from /usr/local/lib/libglib12.so.3 #17 0x2826b31c in g_main_iterate () from /usr/local/lib/libglib12.so.3 #18 0x2826b4b4 in g_main_run () from /usr/local/lib/libglib12.so.3 #19 0x2818b813 in gtk_main () from /usr/X11R6/lib/libgtk12.so.2 #20 0x8067e25 in main () #21 0x8053269 in _start () -----------------------------< cut here >------------------------------- At level #2, g_strndup() is called: 379 else if (cmp == 0) 380 /* the end */ 381 txt = g_strndup(si->content.data.text, 382 b_char); (gdb) print si->content.data.text $4 = 0x81265b0 "3D" (gdb) print b_char $5 = 0 Are you supposed to be able to dup zero-length of a string?

April 25, 2003

Re: [Dillo-dev] Cookie locks?

by Lars Clausen

On Fri, 25 Apr 2003, Jorge Arellano Cid wrote: > > > Lars, > >> >> I understand unrestricted access to cookie jars can be bad for your >> health, but it's annoying that you can't have two Dillos using cookies >> at the same time. I usually have a Dillo running permanently, and when >> I get a URL in my mail, I can click on it to open another Dillo >> (quickly!) -- but that Dillo can't use cookies, which is frequently >> (e.g. in bugzilla) necessary. Could we do a write-lock on it? > > Actually, we plan (with Jörgen) to make of cookies a dpi server. Now *that* would be a good use of the dpi server. Shouldn't be horribly hard, and then the plugin can have a nice admin interface if it wants to. -Lars is still miffed about the bookmarks menu. -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor "I do not agree with a word that you say, but I |---------------------------- will defend to the death your right to say it." | Where are we going, and --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket?

April 25, 2003

Re: [Dillo-dev] Cookie locks?

by Jorge Arellano Cid

Lars, > > I understand unrestricted access to cookie jars can be bad for your health, > but it's annoying that you can't have two Dillos using cookies at the same > time. I usually have a Dillo running permanently, and when I get a URL in > my mail, I can click on it to open another Dillo (quickly!) -- but that > Dillo can't use cookies, which is frequently (e.g. in bugzilla) necessary. > Could we do a write-lock on it? Actually, we plan (with Jörgen) to make of cookies a dpi server. Cheers Jorge.-

April 25, 2003

Re: [Dillo-dev] Bookmarks

by Jorge Arellano Cid

On Tue, 22 Apr 2003, Lars Clausen wrote: > > Are there any plans to reintroduce a bookmarks menu? Any patches for it? Not really. Although dpis will have a way of setting menu items someday, it's very unlikely it will be enough to make a good implementation from it. It is possible to make a dpi that uses a plain GTK+ interface for bookmarks (think of a dpi as an external program that communicates with dillo using the dpi protocol), but this probably would be an overkill for your problem. > While the page looks nifty for the editing, I really don't like getting an > extra bookmark page into my history stack every time I want to go to a > bookmark. One way to solve this is to make dpi:/bm/ URIs "phantom URIs". That is, to flag them and tell the stack manager to get rid of them once they're no longer displayed. This needs some thought though, because you may have more than one dillo window. > In other news: Yay! Cut-and-paste! One of my main reasons to use other > browsers is now gone! Thanks! :) Cheers Jorge.-

April 25, 2003