- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]about DilloHtmlParseMode

by Jorge Arellano Cid

On Mon, Dec 06, 2004 at 05:07:36PM +0800, Calvin Yu wrote: > hello all: > Can you tell me the difference among these dillo html parse mode? >DILLO_HTML_PARSE_MODE_INIT, DILLO_HTML_PARSE_MODE_STASH, >DILLO_HTML_PARSE_MODE_STASH_AND_BODY, DILLO_HTML_PARSE_MODE_VERBATIM, >DILLO_HTML_PARSE_MODE_BODY, DILLO_HTML_PARSE_MODE_PRE > What do these parse mode mean? Especially, what is stash mode? > Thank you very much! The generic parser in Dillo deals with plain text, HTML, XML, comments and the hybrid defined by the PRE element. These modes are flags that let the parser know how to treat the source when switching from one to another. _INIT almost not used. Flags the state before parsing. _BODY is for generic HTML. _VERBATIM is for text that should not be interpreted. _PRE is for handling the <PRE> element. _STASH groups words into a string, and when done processes the sentence as a whole. _STASH_AND_BODY is a bit of a hack to allow for constructing the page index menu from header elements. -- Cheers Jorge.-

Dec. 10, 2004

[Dillo-dev][Offtopic] Dillo in mobile research

by Livio Soares

Hi all, Just as a miscellaneous little bit of curious information: while taking a Mobile Computing course during my first semester here at the University of Toronto, I've learned of the citation of Dillo in a few mobile computing papers: [1] Ghosts in the Machine: Interfaces for Better Power Management http://notrump.eecs.umich.edu/group/papers/mobisys04.pdf Work from University of Michigan, presented in Mobisys'2004 (a very good conference in the mobile area). Won the best paper award. Dillo is used to measure energy savings in the proposed system. [2] Transport Protocol Optimization For Energy Efficient Wireless Embedded Systems http://www.ee.princeton.edu/~anand/pub_links/date03_tcp.pdf Work from Princeton, presented in Design, Automation and Test in Europe Conference and Exhibition (DATE 03) Dillo, again, is used in the evaluation section for energy-savings measurements. [3] Chameleon: Application Controlled Power Management with Performance Isolation http://lass.cs.umass.edu/~lass/papers/pdf/TR04-26.pdf Just a technical report from University of Massachusetts Amherst Also used in evaluation section. Again for energy savings/power-management. The papers themselves have nothing directly to do with Dillo, but it was still nice to see it being mentioned and used in the mobile-research community. My (wild) guess is that the mobile people probably know about Dillo because of its inclusion in the 'Familiar' distribution. Cheers, Livio

Dec. 10, 2004

[Dillo-dev]about ccc model

by Calvin Yu

I think the CCC model is too complex to understand. :( Where can I find a more detailed document about it?

Dec. 8, 2004

[Dillo-dev]about DilloHtmlParseMode

by Calvin Yu

hello all: Can you tell me the difference among these dillo html parse mode? DILLO_HTML_PARSE_MODE_INIT,DILLO_HTML_PARSE_MODE_STASH,DILLO_HTML_PARSE_MODE_STASH_AND_BODY,DILLO_HTML_PARSE_MODE_VERBATIM,DILLO_HTML_PARSE_MODE_BODY,DILLO_HTML_PARSE_MODE_PRE What do these parse mode mean? Especially, what is stash mode? Thank you very much!

Dec. 6, 2004

[Dillo-dev]Ugly fonts -- fixed

by Chris de Vidal

I honestly don't know what worked. This morning I commented out vw_fontname and reloaded Dillo and it worked! Apparently at some point in time I fixed the problem but because vw_fontname was set I didn't know when it was fixed. Now the default font looks great, like the screenshots. Compared to anti-aliased fonts of course it looks edgier and for some reason the screenshot's fonts look slightly less edgy, but it's far better than when I first started using it. Thanks to everyone! CD "You will exist forever. You and God are both in the universe to stay either as friends on his terms, or enemies on yours. Which it will be is proven in this life. And this life is a vapor. Two seconds, and we will be gone. Surely God means for our time on earth to count for something significant." -- John Piper in "Life as a Vapor." Read it here: http://www.desiringgod.org/library/onlinebooks_index.html#blv

Dec. 3, 2004

Re: [Dillo-dev]Ugly fonts

by Chris de Vidal

Thus spaketh higuita: > a font might be installed in the new system, but not installed > in the old X font system... this is your problem... I might agree, except I installed every font package on the KDE system onto the XFCE system. Xlsfonts and xfontsel shows the same output on both machines (see below). No, I think it's a matter of which GTK engine KDE is running. Strangely, XFCE 4 is GTK 2-based... The answer is probably in an obscure GTK config file somewhere. >> I don't think you mean xfontsel because that just lets me see what fonts >> look like, it doesn't show which my X server is using. > > nope, if a font show there, its installed and will show with > any problem as any aplication You might be right; the manpage *does* say xfonsel "displays the fonts known to your X server" but I haven't figured out how... I've only figured out how to show the number of matches (3022) and select an individual font and view it. xlsfonts showed me all of the fonts known to my X server but the output is identical on both systems. > so try it, check the bitstream vera fonts, they are good > fonts and should exist in all distros today > se if they look the same in xfontsel in both systems... Vera isn't an option under "fmly" on either system; it isn't even greyed out so that I could choose it if it were enabled. When I choose the bistream "fndry" and go to "fmly" I only see charter, courier, terminal. >> I compared font packages on both machines and ensured both had the same >> packages installed. Some were missing, so I installed them, updated >> the font cache, restarted X. No joy. > > restart the xfs also Oh yeah forgot to mention I did that too. >> xlsfonts shows exactly the same fonts on both machines. > > try to compare the output of some fonts in xfontsel > in both systems Actually, fonts in xfontsel on the KDE system all look crummy too... they look identical on both systems. Both systems now have exactly the same fonts. Xfontsel says "3022 names match" when I open it on both systems. Xlsfonts also matches (I did a diff on the output). I've installed the same font .deb packages. I just don't understand it. >> X on both machines are now using strictly xfs for fonts. > > also try in both systems with a new temporary user > and see if you get the same results... Worth a shot. > try to use the same desktop manager/window manager > for both also Sorry, I'm not installing a heavy window manager for a lightweight browser; there *has* to be some way to make it nice like I see in the screenshots without installing KDE. > also, try > xset fp default > xset fp rehash > and test it again... if the "good" machine start > outputting bad fonts also, its KDE that its adding > a font path that isnt in the default Same... did I also have to restart X + XFS? > KDE installs some fonts also in $HOME/.kde/share/fonts > or something like this, check if you dont have some > extra fonts in there in the good machine Negative, I did a case-insensitive search under .kde for a folder called "*font*" and came up empty. > finally, are you using the same debian "version" on both > machines? not woody and sid, right 8) Same. Also, same screen resolution and color depth. About the only difference between the two machines is KDE and XFCE. I refuse to use such bloatware on my fast work computer. It's the same reason I want Dillo to work well :) >> I think I'll just give up using Dillo for now... it hurts the eyes too >> much. > > also try in a debian mailling list Well, it's just taking up alot of time; I'll just give up for now. Thanks for the effort. Let me know if I have to restart X + XFS after running xset on the KDE machine. CD "You will exist forever. You and God are both in the universe to stay either as friends on his terms, or enemies on yours. Which it will be is proven in this life. And this life is a vapor. Two seconds, and we will be gone. Surely God means for our time on earth to count for something significant." -- John Piper in "Life as a Vapor." Read it here: http://www.desiringgod.org/library/onlinebooks_index.html#blv

Dec. 3, 2004

Re: [Dillo-dev]Ugly fonts

by higuita

On Wed, 1 Dec 2004 07:26:33 -0500 (EST), "Chris de Vidal" <Chris(a)deVidal.tv> wrote: > This must be related to the GTK 1.x engine that's used with XFCE 4. I say (...) > used by the menus at the top of Multi-Gnome-Terminal. But on GTK 2.x GTK1.x use the tradicional X fonts system GTK2.X use a new font system a font might be installed in the new system, but not installed in the old X font system... this is your problem... KDE also use the new system > I don't think you mean xfontsel because that just lets me see what fonts > look like, it doesn't show which my X server is using. nope, if a font show there, its installed and will show with any problem as any aplication its just really a program that calls X font system and asks for all fonts so try it, check the bitstream vera fonts, they are good fonts and should exist in all distros today se if they look the same in xfontsel in both systems... > I compared font packages on both machines and ensured both had the same > packages installed. Some were missing, so I installed them, updated the > font cache, restarted X. No joy. restart the xfs also > xlsfonts shows exactly the same fonts on both machines. try to compare the output of some fonts in xfontsel in both systems > X on both machines are now using strictly xfs for fonts. also try in both systems with a new temporary user and see if you get the same results... try to use the same desktop manager/window manager for both also also, try xset fp default xset fp rehash and test it again... if the "good" machine start outputting bad fonts also, its KDE that its adding a font path that isnt in the default KDE installs some fonts also in $HOME/.kde/share/fonts or something like this, check if you dont have some extra fonts in there in the good machine finally, are you using the same debian "version" on both machines? not woody and sid, right 8) > I think I'll just give up using Dillo for now... it hurts the eyes too much. also try in a debian mailling list good luck higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Dec. 2, 2004

[Dillo-dev]Ugly fonts

by Chris de Vidal

This must be related to the GTK 1.x engine that's used with XFCE 4. I say that because the font in the type location box (Ctrl+L) has the same ugliness that Dillo renders websites with, and this font is the same as used by the menus at the top of Multi-Gnome-Terminal. But on GTK 2.x programs I get a nice anti-aliased font for the menus. J-Pilot, a GTK app, was recently converted from 1.x to 2.x. Before the upgrade fonts were terrible; now they're smooth. KDE must use a slightly different configuration for GTK 1.x apps; on the wife's computer, both Dillo and Multi-Gnome-Terminal use nice fonts for the menus, location box (Dillo, Ctrl+L), and when Dillo renders HTML. I have the same versions of GTK 1.x and 2.x on both machines. XFCE 4 is GTK 2.x-based. Do I *have* to install a heavy window manager to use a light web browser? Not fair :( Livio Baldini Soares wrote: > Chris, regarding your Debian box, make sure you have correctly > configured your '/etc/fonts/local.conf' configuration file. > Specifically, I have found that most Debian default installations > disable bitmapped fonts, due to the use of anti-aliased or truetype > fonts used in most applications and/or window managers. Uncomment the > lines around: <dir>/usr/X11R6/lib/X11/fonts</dir> > > After you do that, run: > > $ defoma-reconfigure > and > $ fc-cache -f No gold. > Another issue is that fonts with "odd" sizes are butt-ugly. In this > respect, try adding 0.1 to your "font_factor" variable in your dillorc > file (if it's 1.0 set it to 1.1, if it's 1.1 set it to 1.2, for > example). It usually makes very little difference in the final font > size, but makes it a _big_ difference in scalability. No difference. Thanks for the attempt. higuita wrote: > try > > "-misc-fixed-*-*-*--*-*-*-*-*-*-iso8859-1" Same. > probably kde installed truetype fonts... > try to do the xfontsel in that computer and compare > then I don't think you mean xfontsel because that just lets me see what fonts look like, it doesn't show which my X server is using. Jorge Arellano Cid said: > This is a problem with your machine's installed > fonts, not with Dillo. Never doubted that for a second, especially when exactly the same Dillo binary and config file worked at home. Just writing this list because I don't know where else to look. > I'm not a Debian user, but most probably you left out > a set of "legacy" fonts that Dillo requires. Wish that were true... I've installed every font package the other machine has. > Maybe the fastest solution is to check the font-specific .debs > of your wife's cpmputer against yours, once this is done update > the font cache, restart X and retry. I compared font packages on both machines and ensured both had the same packages installed. Some were missing, so I installed them, updated the font cache, restarted X. No joy. xlsfonts shows exactly the same fonts on both machines. X on both machines are now using strictly xfs for fonts. I think I'll just give up using Dillo for now... it hurts the eyes too much.

Dec. 1, 2004

Re: [Dillo-dev]Dillo doesn't work!! :(

by Jorge Arellano Cid

On Wed, Dec 01, 2004 at 10:50:23AM +0100, Andrea Spadaccini wrote: > higuita wrote: > > > > dillorc:98: unexpected string constant "force_visited_color", expected > > > symbol > > > > comment this line as dillo dont recognise it, as its useless > > done > > > > dpi_socket_dir.c:61: tst_dir: access : No such file or directory > > > - /tmp/andrea-0c137u/ > > > debug_msg - init_sockdir: The socket directory > > > /tmp/andrea-0c137u does not exist > > > or is not a directory dpid.c:500: init_all_dpi_sockets: bind : > > > Address already in use/tmp/andrea-3vbac6/bookmarks.dpi > > > > try removing this directory and kill any dillo and > > dpi server and try again... > > [andrea@iridiumII andrea]$ ls /tmp/ > gconfd-andrea/ orbit-andrea/ sylpheed-1000= xmms_giorgia.0= > mc-root/ session_mm_apache0.sem xmms_andrea.0= xmms_luther.0= > [andrea@iridiumII andrea]$ dillo > dillo_dns_init: Here we go! > Disabling cookies. > Nav_open_url: Url=>about:splash< > Nav_open_url: Url=>dpi:/bm/< > dpi_socket_dir.c:61: tst_dir: access : No such file or directory > - /tmp/andrea-u1ua5k/ > debug_msg - init_sockdir: The socket directory /tmp/andrea-u1ua5k does not exist > or is not a directory dpid.c:500: init_all_dpi_sockets: bind : Address already > in use/tmp/andrea-69f7lb/bookmarks.dpi > dpid started > Capi_dpi_conn_timeout:: try 1 > main.c:153: get_command: dpid tag is NULL > : main.c:326: main: get_command failed > : > ** ERROR **: file main.c: line 351 (main): assertion failed: (numsocks >= 0) > aborting... > waitpid: No child processes > IO_write_chunk: Pipe rotta > Dillo: normal exit! > > > > if it still fails, try to strace the dillo to > > see if you find any tip why its failing > > I did it, but I didn't understand anything!!!! > > > also, if still fails, try to do a netstat -lp and > > see if that sockets are still in use and by who. > > [andrea@iridiumII andrea]$ su > Password: > [root@iridiumII andrea]$ netstat -lp > Active Internet connections (only servers) > Proto Recv-Q Send-Q Local Address Foreign Address State > PID/Program name tcp 0 0 *:x11 *:* > LISTEN 164/X tcp 0 0 *:http > *:* LISTEN 112/httpd Active UNIX domain > sockets (only servers) Proto RefCnt Flags Type State I-Node > PID/Program name Path unix 2 [ ACC ] STREAM LISTENING 284 > 232/sylpheed /tmp/sylpheed-1000 unix 2 [ ACC ] STREAM > LISTENING 132 164/X /tmp/.X11-unix/X0 > > > maybe you have a locked/sleeping dpi server somehere > > [root@iridiumII andrea]$ ps aux | grep dp > root 164 4.2 9.7 116544 37764 ? R 10:16 1:24 X -dpi 120 > > > > i'm using slackware 10.0 and dillo is working fine > > here > > :( > Can you give me some other tip, please? > What should I find when I strace dillo? An easier approach would be to follow the directions of: Q: After the upgrade I got: "ERROR: can't start dpid daemon!" in the FAQ. From this lines: > dpi_socket_dir.c:61: tst_dir: access : No such file or directory > - /tmp/andrea-u1ua5k/ > debug_msg - init_sockdir: The socket directory /tmp/andrea-u1ua5k does not ex > or is not a directory dpid.c:500: init_all_dpi_sockets: bind : Address alread > in use/tmp/andrea-69f7lb/bookmarks.dpi It's clear there're conflicts with the directory and an old dpi server. The directory names are different and there's a bound address for bookmarks. -- Cheers Jorge.-

Dec. 1, 2004

Re: [Dillo-dev]Dillo doesn't work!! :(

by Andrea Spadaccini

higuita wrote: > > dillorc:98: unexpected string constant "force_visited_color", expected > > symbol > > comment this line as dillo dont recognise it, as its useless done > > dpi_socket_dir.c:61: tst_dir: access : No such file or directory > > - /tmp/andrea-0c137u/ > > debug_msg - init_sockdir: The socket directory > > /tmp/andrea-0c137u does not exist > > or is not a directory dpid.c:500: init_all_dpi_sockets: bind : > > Address already in use/tmp/andrea-3vbac6/bookmarks.dpi > > try removing this directory and kill any dillo and > dpi server and try again... [andrea@iridiumII andrea]$ ls /tmp/ gconfd-andrea/ orbit-andrea/ sylpheed-1000= xmms_giorgia.0= mc-root/ session_mm_apache0.sem xmms_andrea.0= xmms_luther.0= [andrea@iridiumII andrea]$ dillo dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Nav_open_url: Url=>dpi:/bm/< dpi_socket_dir.c:61: tst_dir: access : No such file or directory - /tmp/andrea-u1ua5k/ debug_msg - init_sockdir: The socket directory /tmp/andrea-u1ua5k does not exist or is not a directory dpid.c:500: init_all_dpi_sockets: bind : Address already in use/tmp/andrea-69f7lb/bookmarks.dpi dpid started Capi_dpi_conn_timeout:: try 1 main.c:153: get_command: dpid tag is NULL : main.c:326: main: get_command failed : ** ERROR **: file main.c: line 351 (main): assertion failed: (numsocks >= 0) aborting... waitpid: No child processes IO_write_chunk: Pipe rotta Dillo: normal exit! > if it still fails, try to strace the dillo to > see if you find any tip why its failing I did it, but I didn't understand anything!!!! > also, if still fails, try to do a netstat -lp and > see if that sockets are still in use and by who. [andrea@iridiumII andrea]$ su Password: [root@iridiumII andrea]$ netstat -lp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 *:x11 *:* LISTEN 164/X tcp 0 0 *:http *:* LISTEN 112/httpd Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 2 [ ACC ] STREAM LISTENING 284 232/sylpheed /tmp/sylpheed-1000 unix 2 [ ACC ] STREAM LISTENING 132 164/X /tmp/.X11-unix/X0 > maybe you have a locked/sleeping dpi server somehere [root@iridiumII andrea]$ ps aux | grep dp root 164 4.2 9.7 116544 37764 ? R 10:16 1:24 X -dpi 120 > i'm using slackware 10.0 and dillo is working fine > here :( Can you give me some other tip, please? What should I find when I strace dillo? Thanks for your help! > ciao Are you Italian too? Ciao :) -- [ Andrea Spadaccini a.k.a. Lupino / Lupin85 - from Catania ] [ MAIL: lupin85(at)email.it - ICQ: 91528290 - Linux 2.4.22 ] [ Linux Registered User #313388 - Powered by Slackware 9.1 ] -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Difendi la tua casella di posta dai virus e dallo spam, prendi Email.it Pro15, Pro50 o Pro100 la casella professionale e sicura. Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1048&d=1-12

Dec. 1, 2004

Re: [Dillo-dev]Re: dillo: umask(0) in dpid/main.c?

by Jeremy Henty

On Tue, Nov 30, 2004 at 03:10:50PM -0300, Jorge Arellano Cid wrote: > On Sun, Nov 28, 2004 at 01:03:23PM +0100, Richard Zidlicky wrote: > > > Is there still a good reason to set umask to 0 for all plugins? > > ... it makes much more sense to use 077 as a mask for dpis > (i.e. only allowing the owner). > > Comments are welcome. Well, I'd vote for 077. World-writable files give me the willies. Cheers, Jeremy

Dec. 1, 2004

Re: [Dillo-dev]Dillo doesn't work!! :(

by higuita

On Tue, 30 Nov 2004 01:04:35 +0100, Andrea Spadaccini <lupin85(a)email.it> wrote: > dillorc:98: unexpected string constant "force_visited_color", expected > symbol comment this line as dillo dont recognise it, as its useless > dpi_socket_dir.c:61: tst_dir: access : No such file or directory > - /tmp/andrea-0c137u/ > debug_msg - init_sockdir: The socket directory > /tmp/andrea-0c137u does not exist > or is not a directory dpid.c:500: init_all_dpi_sockets: bind : > Address already in use/tmp/andrea-3vbac6/bookmarks.dpi try removing this directory and kill any dillo and dpi server and try again... if it still fails, try to strace the dillo to see if you find any tip why its failing also, if still fails, try to do a netstat -lp and see if that sockets are still in use and by who. maybe you have a locked/sleeping dpi server somehere i'm using slackware 10.0 and dillo is working fine here ciao -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Dec. 1, 2004

[Dillo-dev]Re: dillo: umask(0) in dpid/main.c?

by Jorge Arellano Cid

On Sun, Nov 28, 2004 at 01:03:23PM +0100, Richard Zidlicky wrote: > Hi, Hi. > I stumbled upon this as I noticed that bookmarks and saved files > are world writable. Is there still a good reason to set umask > to 0 for all plugins? Good question! Basically the umask(0) call is there because the "Linux Programming Second Edition Unleashed" recommends so as a standard for daemons ;). Now, looking into it, it makes much more sense to use 077 as a mask for dpis (i.e. only allowing the owner). > > Another detail I noticed while checking file creation > is this: > --- dillo-0.8.3/src/cookies.c.rz 2004-11-28 12:39:33.000000000 +0100 > +++ dillo-0.8.3/src/cookies.c 2004-11-28 12:40:22.000000000 +0100 > @@ -100,7 +100,7 @@ > > if ((F_in = fopen(filename, "r+")) == NULL) { > /* Create the file */ > - fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR); > + fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR, 0777); > if (fd != -1) { > if (init_str) > write(fd, init_str, strlen(init_str)); Well, with the proper mask set to 0077 this would not be required. If the need to add explicit permissions arise, it'd be 0077 too. Comments are welcome. -- Cheers Jorge.-

Nov. 30, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Jorge Arellano Cid

Hi there, Do you remember this 4KB memory leak mail-thread? On Thu, Oct 28, 2004 at 09:14:15AM +0200, Roberto A. Foglietta wrote: > robert w hall wrote: > > >Hmm - could this be distro/kernel dependent? > > Doing something similar (toggling reload when monitoring the dillo cvs > >page IIRC) and monitoring memory via top on a remote terminal shows No > >systematic effect - but this is playstation2-linux - an old 2.2.21 > >kernel on a redhat-like implementation for a mips. > > > >In detail:- > >On first coming from the home page to the CVS changelog, top shows > >9460k; this goes up to 9564 on first and stays there for subsequent > >presses of reload. Returning to Home then back to cvs recovers the 9460, > >9564, 9564 sequence. > >Bob > > It should be a glibc bug much more than kernel one, IMHO. > > Sometimes (but very rarely) I supposed to have managed to fix it > because I didn't see it anymore, but recompiling THE SAME code or simply > restarting dillo I saw it again. Obviously I was reloading THE SAME > trivial html page (html, head, body, 4 links in 4 rows, closing-end). The pthreads bug was not deterministic, sometimes it got detached some others not, depending on the kernel scheduler and pthreads implementation. > > I'm working on MDK 10.1 but I could test it on a slackware too. Or > better I will test dillo running on A but compiled in B and all others > combinations foreach A, B in {mdk,slack}. At least after the pthread bug interim patch (CVS) it doesn't leak anymore in my system. And there's this gentle side effect of Dillo using less than 1/5 memory than before! -- Cheers Jorge.-

Nov. 30, 2004

Re: [Dillo-dev]dillo.c patch

by Jorge Arellano Cid

Hi Russell, Sorry for the late answer, the parser and pthreads kept me away from everything else. On Wed, Nov 03, 2004 at 08:05:17AM +0800, Russell J. Wood wrote: > Hello all, > > Attached is a patch for dillo.c that merely ensures all command line arguments > are parsed and complete before the GUI environment. > > Previous to this, the locale and GUI functions where run and then the command > line, of which, in my opinion, should be run after the CLI because the CLI has > the immediate commands. There is no point firing up the GUI when all one would > like to know is the version they are running, right? > > Again, it's nothing major and doubtfully increases performance in any way. The locale needs to be set before parsing the options because some of them can change its meanings (e.g. 1,2 != 1.2). gtk_init(&argc, &argv) needs to be called to get rid of gtk specific args (hopefully not much of an issue when working under FLTK though ;). -- Cheers Jorge.-

Nov. 30, 2004

[Dillo-dev]Dillo doesn't work!! :(

by Andrea Spadaccini

Hi everyone, i compiled and installed Dillo 0.83, but it doesn't open anything! Here there are the error messages I get: [andrea@iridiumII andrea]$ dillo dillorc:98: unexpected string constant "force_visited_color", expected symbol dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Nav_open_url: Url=>dpi:/bm/< dpi_socket_dir.c:61: tst_dir: access : No such file or directory - /tmp/andrea-0c137u/ debug_msg - init_sockdir: The socket directory /tmp/andrea-0c137u does not exist or is not a directory dpid.c:500: init_all_dpi_sockets: bind : Address already in use/tmp/andrea-3vbac6/bookmarks.dpi dpid started Capi_dpi_conn_timeout:: try 1 main.c:153: get_command: dpid tag is NULL : main.c:326: main: get_command failed : ** ERROR **: file main.c: line 351 (main): assertion failed: (numsocks >= 0) aborting... waitpid: No child processes IO_write_chunk: Pipe rotta It seems like it cannot access the dir /tmp/andrea-0c137u, but it should be able to do it: [andrea@iridiumII andrea]$ ll /tmp/ totale 4 drwx------ 2 andrea users 4096 2004-11-30 00:59 andrea-3vbac6/ srwxr-xr-x 1 andrea users 0 2004-11-30 00:59 sylpheed-1000= srwxr-xr-x 1 andrea users 0 2004-11-29 22:20 xmms_andrea.0= srwxr-xr-x 1 giorgia users 0 2004-11-03 16:57 xmms_giorgia.0= srwxr-xr-x 1 luther users 0 2004-11-27 11:50 xmms_luther.0= [andrea@iridiumII andrea]$ cd /tmp/andrea-3vbac6/ [andrea@iridiumII andrea-3vbac6]$ ls bookmarks.dpi= dpid.srs= ftp.filter.dpi= https.filter.dpi= downloads.dpi= file.dpi= hello.filter.dpi= I get the same problems if I'm root too, so it shouldn't be a permissions problem... I've tried installing dpis in my home directory, but it doesn't work.. Can you help me, please? Thanks! :) -- [ Andrea Spadaccini a.k.a. Lupino / Lupin85 - from Catania ] [ MAIL: lupin85(at)email.it - ICQ: 91528290 - Linux 2.4.22 ] [ Linux Registered User #313388 - Powered by Slackware 9.1 ]

Nov. 30, 2004

Re: [Dillo-dev]pthreads

by Jorge Arellano Cid

On Fri, Nov 26, 2004 at 02:14:53PM -0200, Livio Baldini Soares wrote: > Hi Jorge! > > Jorge Arellano Cid writes: > > Errata: > > > > > > > > but it usually ends with: > > > > > > jcid 19262 0.0 0.4 1652 400 pts/10 S+ 08:18 0:00 ./pth_mem2 cd > > > [...] > > > jcid 19027 0.0 0.4 2676 408 pts/10 S+ 08:14 0:00 ./pth_mem2 cd > > > > Oh, the the PID and time in the above example are quoted wrong, > > it should say: > > > > jcid 19262 0.0 0.4 1652 400 pts/10 S+ 08:18 0:00 ./pth_mem2 cd > > [...] > > jcid 19262 0.0 0.4 2676 408 pts/10 S+ 08:18 0:00 ./pth_mem2 cd > > I can't really tell if that's a leak or not. In my system, there is > an increase use of memory between the first iteration and the second, > but from then on, things become _very_ stable (box with Linux 2.4 and > libc 2.3.2 from Debian/unstable): I understand. In my box the "leak" usually occurs near the fifth if at all... > livio 20097 0.0 0.0 1664 336 pts/21 S+ 10:24 0:00 ./pth_mem cd > livio 20097 0.0 0.0 32556 468 pts/21 S+ 10:24 0:00 ./pth_mem cd > livio 20097 0.0 0.0 1796 396 pts/21 S+ 10:24 0:00 ./pth_mem cd > livio 20097 0.0 0.0 32556 476 pts/21 S+ 10:24 0:00 ./pth_mem cd > livio 20097 0.0 0.0 1796 396 pts/21 S+ 10:25 0:00 ./pth_mem cd > > So there is certainly an increase in memory use (in my case a lot > smaller than yours). But look, there is no leak of memory, because > with each interation, the memory is equal to the previous phase. > > Or do you get an increase of 0.5-1 MiB for _each_ phase? No but I get a "random" one in one of them. For instance: I just run this one and there was no leak: <q> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jcid 26194 0.0 0.3 1640 336 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.5 32412 476 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.4 1652 404 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.5 32412 484 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.4 1652 404 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.5 32412 484 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.4 1652 404 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.5 32412 484 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.4 1652 404 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.5 32412 484 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.4 1652 404 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.5 32412 484 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.4 1652 404 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.5 32412 484 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.4 1652 404 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.5 32412 484 pts/29 S+ 17:50 0:00 ./pth_mem2 cd jcid 26194 0.0 0.4 1652 404 pts/29 S+ 17:50 0:00 ./pth_mem2 cd </q> Then I run this other one (w/leak): <q> jcid 26878 0.0 0.3 1640 336 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.5 32412 472 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.4 1652 400 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.5 32412 480 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.4 1652 400 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.5 32412 480 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.4 1652 400 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.5 33436 484 pts/29 S+ 18:27 0:00 ./pth_mem2 d * jcid 26878 0.0 0.4 2676 404 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.5 33436 484 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.4 2676 404 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.5 33436 484 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.4 2676 404 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.5 33436 484 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.4 2676 404 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.5 33436 484 pts/29 S+ 18:27 0:00 ./pth_mem2 d jcid 26878 0.0 0.4 2676 404 pts/29 S+ 18:27 0:00 ./pth_mem2 d </q> I can easily get results with an without leaks for the three ways though. As from my tests, it seems like the "leak" can appear on any iteration > > To make my point clearer, look at how my home box handles the fixed > test program (I'm using Linux kernel 2.6 with NTPL, and libc 2.3.2 > from Debian/unstable): > > livio 4300 0.0 0.0 1440 316 pts/7 S+ 10:40 0:00 ./pth_mem d > livio 4300 0.0 0.0 93812 432 pts/7 Sl+ 10:40 0:00 ./pth_mem d > livio 4300 0.0 0.0 34356 372 pts/7 S+ 10:40 0:00 ./pth_mem d > livio 4300 0.0 0.0 93812 436 pts/7 Sl+ 10:40 0:00 ./pth_mem d > > etc. Even though I use humengeous use of memory, I'm pretty sure > it's not leaking (since the numbers are the same after the first > iteration). A thing that's not happening on my box. > > Looking at straces, I see that libc is doing mmap2() on anonymous > memory for allocation, and in the first phase, actually allocates 8 > MiB worth of stack for each thread! (I know it's stack because it's > setting PROT_EXEC on, whoch it doesn't for regular > mallocs()). Subsequently, each thread mmap2() _2_ MiB of anonymous > memory (instead of only one). > > Anyways, not wanting to get too much into the details, it's hard to > predict what your libc is doing for you. I can see that libc correctly > munmaps() all the mapped segments (effectively freeing the > memory). _And_ the VSZ stays the same throughout interations. > > REMINDER: In this case a big VSZ does not mean big memory > usage. It means a _potential_ to use a lot of memory (I've seen rare > cases where a thread actually makes use of more than 1MiB of stack, > for example, let alone 8MiB). If the mmap2() is is never touched, a > page never gets assigned to the process' page table. BTW, Is the VSZ reserved somehow, on swap at least? or is just a potential size that we can happily ignore? I'm adding six more test results, this time with Dillo and a small page with a hundred tiny images. It has three samples for each technique: Note: I'm using the file dpi server, so dillo uses a pthread for each IO. Using 'd' technique: <q> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 13820 11168 ./dillo 15492 12624 ./dillo 15600 12736 ./dillo </q> Using 'cd' technique: <q> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 15496 12640 ./dillo 9272 6888 ./dillo 10408 7940 ./dillo </q> Here the RSS is smaller for 'cd' so I opted this one for the interim patch just commited to CVS. -- Cheers Jorge.-

Nov. 28, 2004

Re: [Dillo-dev]pthreads

by Livio Baldini Soares

Hi Jorge! Jorge Arellano Cid writes: > Errata: > > > > > but it usually ends with: > > > > jcid 19262 0.0 0.4 1652 400 pts/10 S+ 08:18 0:00 ./pth_mem2 cd > > [...] > > jcid 19027 0.0 0.4 2676 408 pts/10 S+ 08:14 0:00 ./pth_mem2 cd > > Oh, the the PID and time in the above example are quoted wrong, > it should say: > > jcid 19262 0.0 0.4 1652 400 pts/10 S+ 08:18 0:00 ./pth_mem2 cd > [...] > jcid 19262 0.0 0.4 2676 408 pts/10 S+ 08:18 0:00 ./pth_mem2 cd I can't really tell if that's a leak or not. In my system, there is an increase use of memory between the first iteration and the second, but from then on, things become _very_ stable (box with Linux 2.4 and libc 2.3.2 from Debian/unstable): livio 20097 0.0 0.0 1664 336 pts/21 S+ 10:24 0:00 ./pth_mem cd livio 20097 0.0 0.0 32556 468 pts/21 S+ 10:24 0:00 ./pth_mem cd livio 20097 0.0 0.0 1796 396 pts/21 S+ 10:24 0:00 ./pth_mem cd livio 20097 0.0 0.0 32556 476 pts/21 S+ 10:24 0:00 ./pth_mem cd livio 20097 0.0 0.0 1796 396 pts/21 S+ 10:25 0:00 ./pth_mem cd So there is certainly an increase in memory use (in my case a lot smaller than yours). But look, there is no leak of memory, because with each interation, the memory is equal to the previous phase. Or do you get an increase of 0.5-1 MiB for _each_ phase? To make my point clearer, look at how my home box handles the fixed test program (I'm using Linux kernel 2.6 with NTPL, and libc 2.3.2 from Debian/unstable): livio 4300 0.0 0.0 1440 316 pts/7 S+ 10:40 0:00 ./pth_mem d livio 4300 0.0 0.0 93812 432 pts/7 Sl+ 10:40 0:00 ./pth_mem d livio 4300 0.0 0.0 34356 372 pts/7 S+ 10:40 0:00 ./pth_mem d livio 4300 0.0 0.0 93812 436 pts/7 Sl+ 10:40 0:00 ./pth_mem d etc. Even though I use humengeous use of memory, I'm pretty sure it's not leaking (since the numbers are the same after the first iteration). Looking at straces, I see that libc is doing mmap2() on anonymous memory for allocation, and in the first phase, actually allocates 8 MiB worth of stack for each thread! (I know it's stack because it's setting PROT_EXEC on, whoch it doesn't for regular mallocs()). Subsequently, each thread mmap2() _2_ MiB of anonymous memory (instead of only one). Anyways, not wanting to get too much into the details, it's hard to predict what your libc is doing for you. I can see that libc correctly munmaps() all the mapped segments (effectively freeing the memory). _And_ the VSZ stays the same throughout interations. REMINDER: In this case a big VSZ does not mean big memory usage. It means a _potential_ to use a lot of memory (I've seen rare cases where a thread actually makes use of more than 1MiB of stack, for example, let alone 8MiB). If the mmap2() is is never touched, a page never gets assigned to the process' page table. hope this helps, -- Livio B. Soares

Nov. 26, 2004

Re: [Dillo-dev]pthreads

by Jorge Arellano Cid

Errata: > > but it usually ends with: > > jcid 19262 0.0 0.4 1652 400 pts/10 S+ 08:18 0:00 ./pth_mem2 cd > [...] > jcid 19027 0.0 0.4 2676 408 pts/10 S+ 08:14 0:00 ./pth_mem2 cd Oh, the the PID and time in the above example are quoted wrong, it should say: jcid 19262 0.0 0.4 1652 400 pts/10 S+ 08:18 0:00 ./pth_mem2 cd [...] jcid 19262 0.0 0.4 2676 408 pts/10 S+ 08:18 0:00 ./pth_mem2 cd -- Cheers Jorge.-

Nov. 26, 2004

Re: [Dillo-dev]pthreads

by Jorge Arellano Cid

On Thu, Nov 25, 2004 at 04:48:07PM +0100, Lars Segerlund wrote: > > I REALLY understand chasing the leaks and then finding > something like this stings ... Yes it does. Note that even knowing that it was my fault (assuming wrongly about the API), the irony remains. ...and the soothing side of it, is that now we have a Dillo running on less than 1/5 of the memory it used to. -- Cheers Jorge.-

Nov. 26, 2004

Re: [Dillo-dev]pthreads

by Jorge Arellano Cid

On Thu, Nov 25, 2004 at 02:39:01PM -0200, Livio Baldini Soares wrote: > Hi Jorge, > > I just got the chance to look at your little test program. It has a > few bugs: > > 1) In pthread_create() you are passing a pointer to the unintialized > thrdID[i] variable. Pthreads does not guarantee that the threadID > argument is initialized before the start_routine is called. If you > try printing the value of p_thrID in the 'thr_function', you'll see > you'll get some correct and some random values. Gotcha! This explains most of it. So the quid is that Pthreads does not guarantee that the threadID argument is initialized before the start_routine is called. My fault! Even though some other pthread implementations seem to do it, the document from the opengroup you cite is clear: <q> APPLICATION USAGE There is no requirement on the implementation that the ID of the created thread be available before the newly created thread starts executing. The calling thread can obtain the ID of the created thread through the return value of the pthread_create() function, and the newly created thread can obtain its ID by a call to pthread_self(). </q> Now, even after patching the test program to use: > - pthread_detach(*p_thrID); > + pthread_detach(pthread_self()); it still leaks some memory in my machine! (near half a MB). It is interesting to note that as Brian reports: > [Brian wrote:] > > [Jorge wrote:] > > > > Has anyone had the opportunity to run the test program under > > Solaris? This is an interesting test because Solaris has its own > > threads implementation. I'd expect the detached pthreads test not > > to leak memory on Solaris. > > did it just now. all three ways leak zero memory. Zero leak on Solaris. On my machine, the three ways can still leak, but sometimes they don't. For instance, running the test should give: jcid 19262 0.0 0.4 1652 400 pts/10 S+ 08:18 0:00 ./pth_mem2 cd [...] jcid 19262 0.0 0.4 1652 400 pts/10 S+ 08:18 0:00 ./pth_mem2 cd but it usually ends with: jcid 19262 0.0 0.4 1652 400 pts/10 S+ 08:18 0:00 ./pth_mem2 cd [...] jcid 19027 0.0 0.4 2676 408 pts/10 S+ 08:14 0:00 ./pth_mem2 cd (the same amount leaked either with "d", "cd" or "j" mode). At some point in time "cd" seemed to be the "better" one, but surely more testing is required. Or better, finding the bug. ;) -- Cheers Jorge.-

Nov. 26, 2004

Re: [Dillo-dev]pthreads

by Livio Baldini Soares

Hi Brian, Brian Hechinger writes: > i just did a test on my mac, which runs NetBSD 2.0 RC4, and it also does > not leak memory in either of the three cases. > > i know they use the pth library, but i wonder if they do something > differently than linux does? Did you get a chance to read my bugreport messages? http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-November/002448.html and http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-November/002450.html It is possible that different pthread implementations initialize (or set) the threadID (first argument passed to pthread_create()) in different orders. In Linux, I have seen different systems behave randomly (probably because it issues a clone(), and from then on let's the OS take over the scheduling, which is usually non-deterministic). Even if you tried sucessfully on Solaris and *BSD, it does not mean that it is a safe construct to rely on. The OS might happen to schedule the threads in a certain order, or the specific version of the libraries synchronizes the thread creation in a specific manner, etc. Bottom line, the POSIX threads specificiation does *not* require the threadID to be set before the new thread begin execution:

Nov. 26, 2004

Re: [Dillo-dev]pthreads

by Brian Hechinger

i just did a test on my mac, which runs NetBSD 2.0 RC4, and it also does not leak memory in either of the three cases. i know they use the pth library, but i wonder if they do something differently than linux does? -brian -- "Now you know why I got the everliving hell OUT of Windows administration. Knowing it doesn't make it any easier. It's just broken-as-designed."

Nov. 26, 2004

Re: [Dillo-dev]Ugly fonts

by higuita

hi On Thu, 25 Nov 2004 04:41:19 -0200, Livio Baldini Soares <livio(a)ime.usp.br> wrote: > > try to do the xfontsel in that computer and compare then > You probably mean 'xlsfonts', which will list all the fonts the > current X server has access to (in a nicer format for comparison, than > xfontsel). agree, xfontsel is ugly but better to choose a font, but for comparing xlsfont is *alot* better... but i also suspect that the difference would be huge (maybe 10 fonts against 100) so enough to search for the cause thanks anyway for the correction 8) higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Nov. 26, 2004

Re: [Dillo-dev]pthreads

by Brian Hechinger

On Wed, Nov 24, 2004 at 10:46:30AM -0300, Jorge Arellano Cid wrote: > > Has anyone had the opportunity to run the test program under > Solaris? This is an interesting test because Solaris has its own > threads implementation. I'd expect the detached pthreads test not > to leak memory on Solaris. did it just now. all three ways leak zero memory. -brian -- "Now you know why I got the everliving hell OUT of Windows administration. Knowing it doesn't make it any easier. It's just broken-as-designed."

Nov. 26, 2004

Re: [Dillo-dev]pthreads

by Livio Baldini Soares

Hi (again), Livio Baldini Soares writes: > Hi Jorge, > > I just got the chance to look at your little test program. It has a > few bugs: > > 1) In pthread_create() you are passing a pointer to the unintialized > thrdID[i] variable. Pthreads does not guarantee that the threadID > argument is initialized before the start_routine is called. If you > try printing the value of p_thrID in the 'thr_function', you'll see > you'll get some correct and some random values. I just looked and there are three occurences of this bug in Dillo: dpi/file.c src/IO/IO.c src/dns.c All three of them should have the current calls to: 'pthread_detach(uninitialized-variable)' changed to use 'pthread_detach(phtread_self())' As in all three cases the variable used has some likelihood (in my system, a high likelihood) of not yet being initialized. In some cases (like struct DnsServer) the threadID variable can optionally be altogether removed. The final patch is left as an exercise to the reader ;-) hope this helps, -- Livio B. Soares

Nov. 25, 2004

Re: [Dillo-dev]pthreads

by robert w hall

In article <20041125152322.GH1676(a)dillo.org>, Jorge Arellano Cid <jcid(a)dillo.org> writes > What an irony: after years of chasing the most minor memory >leaks (up to a few bytes), it ends up being that we've leaked >a lot, by Megabyte units, because of an external library. > well I _did_ say it didn't appear to be leaking on a playstation-2... -- robert w hall

Nov. 25, 2004

Re: [Dillo-dev]pthreads

by Livio Baldini Soares

Hi Jorge, I just got the chance to look at your little test program. It has a few bugs: 1) In pthread_create() you are passing a pointer to the unintialized thrdID[i] variable. Pthreads does not guarantee that the threadID argument is initialized before the start_routine is called. If you try printing the value of p_thrID in the 'thr_function', you'll see you'll get some correct and some random values. 2) Still, it's not a good idea to pass variables from the thread stack. In this particular case, it will work since the main thread outlives all the created ones, but it is usually highly likely to cause you headaches... A minimal fix for your test code is: --- pth_mem.orig.c 2004-11-25 11:16:01.000000000 -0500 +++ pth_mem.c 2004-11-25 11:33:34.000000000 -0500 @@ -7,11 +7,10 @@ int mode; static void *thr_function(void *data) { int i; - pthread_t *p_thrID = data; void *mem; if (mode == 'd') - pthread_detach(*p_thrID); + pthread_detach(pthread_self()); for (i = 0; i < 10; ++i) { mem = malloc(1024*1024); In my box, this gets rid of any leaks. best regards, -- Livio B. Soares

Nov. 25, 2004

Re: [Dillo-dev]pthreads

by Lars Segerlund

I REALLY understand chasing the leaks and then finding something like this stings ... / regars, Lars Segerlund. On Thu, 25 Nov 2004 12:23:22 -0300 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi, > > Well, I searched for where to report bugs in pthreads and the > process is tedious to say the least. > > They want the submitter to test against CVS glibc which is a > thing I don't have the time, nor the machine to do. > > FWIW, a near target is at least the test program on the latest > glibc (glibc-2.3.3 at this time), but I have 2.3.2. Can someone > please test it with glibc-2.3.3? > > If the Solaris test shows no leaks, then that's strong evidence > of a _serious_ problem within glibc's pthreads and the bug report > will most probably be welcomed. > > After I have the results from glibc-2.3.3 and Solaris, I'll > send the report. In the meanwhile I've been playing some > workarounds for Dillo and the results is an impressive memory > usage reduction so far (BTW, the reload memory leak also had its > roots in pthreads leaking memory). > > What an irony: after years of chasing the most minor memory > leaks (up to a few bytes), it ends up being that we've leaked > a lot, by Megabyte units, because of an external library. > > Notwithstanding there's still the possibility of me being wrong > in the understanding of its API, this chance is growing thiner. > > It could also be the kernel (or ps) not reporting correctly the > VSZ and RSS. Who knows? At least the workarounds are improving a > lot these stats in my tree. > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 25, 2004

Re: [Dillo-dev]pthreads

by Jorge Arellano Cid

Hi, Well, I searched for where to report bugs in pthreads and the process is tedious to say the least. They want the submitter to test against CVS glibc which is a thing I don't have the time, nor the machine to do. FWIW, a near target is at least the test program on the latest glibc (glibc-2.3.3 at this time), but I have 2.3.2. Can someone please test it with glibc-2.3.3? If the Solaris test shows no leaks, then that's strong evidence of a _serious_ problem within glibc's pthreads and the bug report will most probably be welcomed. After I have the results from glibc-2.3.3 and Solaris, I'll send the report. In the meanwhile I've been playing some workarounds for Dillo and the results is an impressive memory usage reduction so far (BTW, the reload memory leak also had its roots in pthreads leaking memory). What an irony: after years of chasing the most minor memory leaks (up to a few bytes), it ends up being that we've leaked a lot, by Megabyte units, because of an external library. Notwithstanding there's still the possibility of me being wrong in the understanding of its API, this chance is growing thiner. It could also be the kernel (or ps) not reporting correctly the VSZ and RSS. Who knows? At least the workarounds are improving a lot these stats in my tree. -- Cheers Jorge.-

Nov. 25, 2004

Re: [Dillo-dev]Ugly fonts

by Livio Baldini Soares

Hi, Sorry for the slightly unrelated post, higuita writes: > On Wed, 24 Nov 2004 17:57:19 -0500 (EST), "Chris de Vidal" <Chris(a)deVidal.tv> wrote: > > Switched vw_fontname to > > "-misc-fixed-bold-r-normal--12-120-75-75-c-0-iso8859-1" > [...] > > kernel version, but running KDE 3.3 not XFCE. Looks beatiful, just like > > the screenshot. > > probably kde installed truetype fonts... > try to do the xfontsel in that computer and compare > then You probably mean 'xlsfonts', which will list all the fonts the current X server has access to (in a nicer format for comparison, than xfontsel). Chris, regarding your Debian box, make sure you have correctly configured your '/etc/fonts/local.conf' configuration file. Specifically, I have found that most Debian default installations disable bitmapped fonts, due to the use of anti-aliased or truetype fonts used in most applications and/or window managers. Uncomment the lines around: <dir>/usr/X11R6/lib/X11/fonts</dir> After you do that, run: $ defoma-reconfigure and $ fc-cache -f Another issue is that fonts with "odd" sizes are butt-ugly. In this respect, try adding 0.1 to your "font_factor" variable in your dillorc file (if it's 1.0 set it to 1.1, if it's 1.1 set it to 1.2, for example). It usually makes very little difference in the final font size, but makes it a _big_ difference in scalability. There was something else I was going to suggest, but I forget now... If I remember I'll write. Sorry, have to run now, good luck, and hope this helps, -- Livio B. Soares

Nov. 25, 2004

Re: [Dillo-dev]Ugly fonts

by higuita

On Wed, 24 Nov 2004 17:57:19 -0500 (EST), "Chris de Vidal" <Chris(a)deVidal.tv> wrote: > Switched vw_fontname to > "-misc-fixed-bold-r-normal--12-120-75-75-c-0-iso8859-1" try "-misc-fixed-*-*-*--*-*-*-*-*-*-iso8859-1" maybe this way you manage to get the bold, italic and different font sizes the way you put force the font to be exactly like that, my way "might" allow all combinations (might because i'm not sure if this isnt too generic or if dillo support it) also, is this the only font you have in xfontsel? > the dillo.org screenshot has very smooth fonts. Mine is all jaggedy. the jagged font usually is because the font is not propocional/scalable or low quality > kernel version, but running KDE 3.3 not XFCE. Looks beatiful, just like > the screenshot. probably kde installed truetype fonts... try to do the xfontsel in that computer and compare then good luck higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Nov. 25, 2004

Re: [Dillo-dev]Ugly fonts

by Jorge Arellano Cid

On Wed, Nov 24, 2004 at 05:57:19PM -0500, Chris de Vidal wrote: > Thus spaketh higuita: > > check with xfontsel what font do you really have for normal > > X programs, as gtk2 programs should be using a new way of > > generating fonts (XFT) and probably most of your truetype > > fonts arent really in the old X11 font interface > > > > try chossing a font listed in the xfontsel that looks > > good and its scalable... > > if you have bitstream vera, use it > > Switched vw_fontname to > "-misc-fixed-bold-r-normal--12-120-75-75-c-0-iso8859-1" > which looks somewhat better, but still not as good as the originals: > http://devidal.tv/~chris/mine_versus_dillo.org.gif > > You may not see much difference but believe me my eyes hurt looking at my > dillo. You really see the difference in the two green topic title bars; > the dillo.org screenshot has very smooth fonts. Mine is all jaggedy. > > Tried the same version of dillo on my wife's PC, also Debian Sid, same > kernel version, but running KDE 3.3 not XFCE. Looks beatiful, just like > the screenshot. > > Something isn't right. I thought I set her machine up with the same fonts... > > Ideas anyone? Hi. It should be working. This is a problem with your machine's installed fonts, not with Dillo. Dillo doesn't do True Type at this time, so there's no point installing this type of fonts. I'm not a Debian user, but most probably you left out a set of "legacy" fonts that Dillo requires. Maybe the fastest solution is to check the font-specific .debs of your wife's cpmputer against yours, once this is done update the font cache, restart X and retry. A more accurate way of solving it is to ask a long time Debian user what the packages for "legacy" (not antialiased) fonts are and how to install them. Please let us know when it starts working for you. HTH. -- Cheers Jorge.-

Nov. 24, 2004

Re: [Dillo-dev]Ugly fonts

by Chris de Vidal

Thus spaketh higuita: > check with xfontsel what font do you really have for normal > X programs, as gtk2 programs should be using a new way of > generating fonts (XFT) and probably most of your truetype > fonts arent really in the old X11 font interface > > try chossing a font listed in the xfontsel that looks > good and its scalable... > if you have bitstream vera, use it Switched vw_fontname to "-misc-fixed-bold-r-normal--12-120-75-75-c-0-iso8859-1" which looks somewhat better, but still not as good as the originals: http://devidal.tv/~chris/mine_versus_dillo.org.gif You may not see much difference but believe me my eyes hurt looking at my dillo. You really see the difference in the two green topic title bars; the dillo.org screenshot has very smooth fonts. Mine is all jaggedy. Tried the same version of dillo on my wife's PC, also Debian Sid, same kernel version, but running KDE 3.3 not XFCE. Looks beatiful, just like the screenshot. Something isn't right. I thought I set her machine up with the same fonts... Ideas anyone? CD "You will exist forever. You and God are both in the universe to stay either as friends on his terms, or enemies on yours. Which it will be is proven in this life. And this life is a vapor. Two seconds, and we will be gone. Surely God means for our time on earth to count for something significant." -- John Piper in "Life as a Vapor." Read it here: http://www.desiringgod.org/library/onlinebooks_index.html#blv

Nov. 24, 2004

Re: [Dillo-dev]pthreads

by Jorge Arellano Cid

On Wed, Nov 24, 2004 at 03:15:15PM +0100, Riccardo Mottola wrote: > Hey Jorge, > > just a quick answer, but I am ina hurry > > > I have solaris, I have gcc. so I can test and compile. I have also > MkLinux which is linux where threads are mapped to mach threads (linux > on mach microkernel). > > > What source code should I run? How do i check for memory leaks (no > valgrind for solaris)... I posted it to the mailing list with instructions. You can find it here: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-November/002436.html The mail thread starts at: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-November/002429.html BTW, I'm making some tests in dillo using the results explained there, and the results are impressive: For instance: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jcid 3234 2.5 13.9 663804 13116 pts/15 S+ 11:59 0:05 ./dillo jcid 3238 0.0 13.9 663804 13116 pts/15 S+ 11:59 0:00 ./dillo (see the huge virtual size? It's a simple page with lots of tiny images). The same dillo, this time using the explicit detached-attribute pthread creation technique, gives: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jcid 3792 11.8 11.0 14116 10448 pts/15 S+ 12:49 0:07 ./dillo jcid 3793 0.3 11.0 14116 10448 pts/15 S+ 12:49 0:00 ./dillo Same code, same page. Something really weird is going on here! Does anyone know the email of the pthreads library maintainer? -- Cheers Jorge.-

Nov. 24, 2004

Re: [Dillo-dev]pthreads

by Jorge Arellano Cid

On Thu, Nov 18, 2004 at 01:34:46PM -0300, Jorge Arellano Cid wrote: > [...] > I decided to cut glib out of the problem, then developed a test > program and did some research. *Very* interesting results came > out of it. > > [...] > > > [Lars wrote:] > > If the threads are allocating of a public heap it might not be > > possible to reclaim/remap the heap so it will look as if a lot of > > memory is allocated. There is a similar 'bug' in the C++ standard > > that means that memory allocated by objects might never be > > reclaimed under some circumstances. > > Yes it look like this kind of problem. > > > I DO NOT now if this is related to the problem, but it sounds a > > bit similar (I suppose you have tried running the whole lot under > > valgrind ?) > > I cut glib out and made a test program (attached), that > matches mallocs and frees trivially. > > The results were amazing: > > compile the program with: > > gcc pth_mem.c -o pth_mem -lpthread > > run it like this: > > ./pth_mem <j|d|cd> > > and observe the memory footprint from another terminal with: > > while [ 1 ]; do ps aux | grep [p]th_mem; sleep 4; done Has anyone had the opportunity to run the test program under Solaris? This is an interesting test because Solaris has its own threads implementation. I'd expect the detached pthreads test not to leak memory on Solaris. BTW, the new threads-based dpi server is in the CVS now. This fixes a critical race with large files that linked lots of instances of a minor image (a bullet for instance). It worked OK with my tests (up to a 2MB page), uses joinable threads, and didn't show any leaks while testing. Strange no one reported this bug before... Well I guess almost nobody writes large HTML pages these days, as the very big browsers will surely have a hard time with them! :-) -- Cheers Jorge.-

Nov. 24, 2004

[Dillo-dev]Parser orthogonalization

by Jorge Arellano Cid

Hi there, A few days ago I finished the: [1] Orthogonalize the parser (leaks, XML, CSS) task from the list. I didn't commit it inmediately because of the pthreads issue we're still workint in (it showed as a parser bug when in fact it was elsewhere). Now the large parser patch is commited (a 70KB beast!). From the ChangeLog: <q> * Orthogonalized the generic parser: - Fixes memory leaks and widget state when recovering from bad HTML. - Improves error detection and validation (needed by XHTML). - Makes DOC tree generation possible (needed by CSS). - Cleaner design of handling routines for bad HTML. - Orthodox treatment of double optional elements (HTML, HEAD, BODY). - Lots of minor code cleanups. </q> That's the summary. Now tags are always pushed into the stack when they're found and the respective closing functions are always called when finishing them, no matter if this is triggered by an explicit tag, optional close, or bad-HTML cleanup. This is very important because of the above explained reasons. The routines for handling HTML cleanup (optional, magic and bad HTML) were mostly isolated into three functions: Html_test_section() Html_stack_cleanup_at_open() Html_tag_cleanup_at_close() (fairly commented in the source). In brief: the good news of all of this patch is that it makes much easier to understand, improve and maintain the parser (eventually to chop, merge or reuse too), fixes memory handling, widget creation state, validation, and is also good for future CSS, XHTML. For instance, look at the new <P> and </P> tag treatment at: http://www-106.ibm.com/developerworks/eserver/articles/framework.html Now, I'm back to pthreads, ah, and I have more cleanups already done waiting for commit, some patches pending, the usual stuff! -- Cheers Jorge.-

Nov. 21, 2004

[Dillo-dev]Dillo and multimedia keys

by Andrea Spadaccini

Hi everyone, does Dillo support "strange" keys that are configured with Xmodmap? I'd like to hit the "back" button (XF86Back) and go back one page, and so on... If Dillo doesn't support this, you could give me suggestions on how to implement it. I know a little C, and maybe I could be able to help you. Thanks in advance -- [ Andrea Spadaccini a.k.a. Lupino / Lupin85 - from Catania ] [ MAIL: lupin85(at)email.it - ICQ: 91528290 - Linux 2.4.22 ] [ Linux Registered User #313388 - Powered by Slackware 9.1 ] -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Email.it Phone Card: chiami in tutto il mondo a tariffe imbattibili da tutti i telefoni fissi e cellulari! Clicca e scopri come Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2686&d=20-11

Nov. 20, 2004

Re: [Dillo-dev]pthreads

by Lars Segerlund

Thanks, I'm so glad I actually was in the ballpark :-) ... Usually when I have a good idéa of what's happening, it's wrong :-) .. I'll also look at it, since I debugged some stuff like this a long time ago :-) ... ( C++ project big -> bugs -> I rewrote in C and put up some wrappers ... -> worked ( well, it looked good anyhow )). I'm really intrigued now ! / Lars ... On Thu, 18 Nov 2004 13:34:46 -0300 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Livio, Lars, > ...snip... > > > [Lars wrote:] > > If the threads are allocating of a public heap it might not be > > possible to reclaim/remap the heap so it will look as if a lot of > > memory is allocated. There is a similar 'bug' in the C++ standard > > that means that memory allocated by objects might never be > > reclaimed under some circumstances. > > Yes it look like this kind of problem. > ...snip...

Nov. 18, 2004

Re: [Dillo-dev]pthreads

by Jorge Arellano Cid

Livio, Lars, On Tue, Nov 16, 2004 at 06:05:17PM -0200, Livio Baldini Soares wrote: > Hi Jorge, Hi Livio! Good to know you're still there. > I don't have time to really look at this, but are you using > g_thread_init(), gdk_threads_init(), gdk_threads_enter(), > gdk_threads_leave() and company? Here is some info: > > http://www.gtk.org/faq/#AEN482 > > I wouldn't be surprised if GLib gets confused without calling > g_thread_init(). Specifically, if I remember correctly, the locking > of GLibc's internal variables is only actually done when > g_thread_init() is executed. > > This _might_ explain your problem... but it might be a long shot, > since a race condition is needed to activate the possible problem. If > you're sure, however, that g_malloc and g_free are the source for > your memory leak, that the problem is something else (in GLib 1.2, at > least, g_malloc and g_free map almost directly to malloc() and free(), > which are thread-safe). > > The only big caveat of malloc/free is that they are not signal-safe, > i.e., you shouldn't use them (along with a hoard of other things in > libc and systems calls, etc) in signal handlers. I decided to cut glib out of the problem, then developed a test program and did some research. *Very* interesting results came out of it. > [Lars wrote:] > If the threads are allocating of a public heap it might not be > possible to reclaim/remap the heap so it will look as if a lot of > memory is allocated. There is a similar 'bug' in the C++ standard > that means that memory allocated by objects might never be > reclaimed under some circumstances. Yes it look like this kind of problem. > I DO NOT now if this is related to the problem, but it sounds a > bit similar (I suppose you have tried running the whole lot under > valgrind ?) I cut glib out and made a test program (attached), that matches mallocs and frees trivially. The results were amazing: compile the program with: gcc pth_mem.c -o pth_mem -lpthread run it like this: ./pth_mem <j|d|cd> and observe the memory footprint from another terminal with: while [ 1 ]; do ps aux | grep [p]th_mem; sleep 4; done The program makes 8 iterations, launching 10 pthreads on each one. Each launched thread allocates memory, sleeps and frees it 10 times using malloc/free, then it exits. The interesting part is that: ./pth_mem d ('d' for detached with pthread_detach()) leaks tons of memory!!! ./pth_mem cd ('cd' for create detached with pthread_attr_setdetachstate) leaks much less memory! ./pth_mem j ('j' for joinable) is almost perfect but sometimes leaks. The first two should be the same, even more, the manual says: <q> `pthread_detach' puts the thread TH in the detached state. This guarantees that the memory resources consumed by TH will be freed immediately when TH terminates. However, this prevents other threads from synchronizing on the termination of TH using `pthread_join'. </q> Unless I'm missing a key point, this looks like a bug in pthreads. Would you mind check it out and point my mistake, or giving me a pointer to pthreads library maintainer? -- Cheers Jorge.-

Nov. 18, 2004

Re: [Dillo-dev]Ugly fonts

by higuita

On Tue, 16 Nov 2004 17:52:01 -0500 (EST), "Chris de Vidal" <Chris(a)deVidal.tv> wrote: > The fonts on my machine look far worse than those in the screenshots. For > example, Slashdot: check with xfontsel what font do you really have for normal X programs, as gtk2 programs should be using a new way of generating fonts (XFT) and probably most of your truetype fonts arent really in the old X11 font interface try chossing a font listed in the xfontsel that looks good and its scalable... if you have bitstream vera, use it good luck higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Nov. 18, 2004

[Dillo-dev]Ugly fonts

by Chris de Vidal

Wonderful, fast program! Especially dig the fullscreen mode and keyboard shortcuts. HTML layout rendering of pages like Google and Amazon and eBay and Slashdot looks great! Unfortunately the fonts don't... Dillo 0.8.3 Debian Sid XFCE 4.0.5-1 XFS 4.3.0.dfsg.1-8 Kernel 2.6.8.1 The fonts on my machine look far worse than those in the screenshots. For example, Slashdot: http://devidal.tv/~chris/ugly_dillo_fonts.png Compared to your screenshot: http://www.dillo.org/screenshots/slashdot1.png And just for reference, Firefox 1.0 RC1 from a Debian Sid source (probably includes gtk2 and xfs): http://devidal.tv/~chris/nice_firefox_fonts.png These fonts are about the only thing preventing my more regular use of Dillo. I built Dillo with just ./configure make make install I tried vw_fontname=lucida which helped some, but it's still uglier than the screenshots. Ideas? Need to know anything else? CD "You will exist forever. You and God are both in the universe to stay either as friends on his terms, or enemies on yours. Which it will be is proven in this life. And this life is a vapor. Two seconds, and we will be gone. Surely God means for our time on earth to count for something significant." -- John Piper in "Life as a Vapor." Read it here: http://www.desiringgod.org/library/onlinebooks_index.html#blv

Nov. 16, 2004

Re: [Dillo-dev]pthreads

by Livio Baldini Soares

Hi Jorge, Jorge Arellano Cid writes: > Hi, > > Is anyone here savvy on using dynamic memory allocation in > pthreads? > > The problem: while hunting a bug that showed after the large > parser orthogonalization patch, it was finally found between > dillo and the file dpi server; it was a critical race. I recoded > the file server to use pthreads and it went away, but... > > ... the new file server started to increase dramatically its > virtual size. > > The threads are allocating memory and freeing it with the usual > g_malloc/g_free pair, but it seems like these blocks remain > allocated even after the thread is finished. I don't have time to really look at this, but are you using g_thread_init(), gdk_threads_init(), gdk_threads_enter(), gdk_threads_leave() and company? Here is some info: http://www.gtk.org/faq/#AEN482 I wouldn't be surprised if GLib gets confused without calling g_thread_init(). Specifically, if I remember correctly, the locking of GLibc's internal variables is only actually done when g_thread_init() is executed. This _might_ explain your problem... but it might be a long shot, since a race condition is needed to activate the possible problem. If you're sure, however, that g_malloc and g_free are the source for your memory leak, that the problem is something else (in GLib 1.2, at least, g_malloc and g_free map almost directly to malloc() and free(), which are thread-safe). The only big caveat of malloc/free is that they are not signal-safe, i.e., you shouldn't use them (along with a hoard of other things in libc and systems calls, etc) in signal handlers. > This may be the same root for the reload memory leak > pointed somtime ago, do you remember? The IO engine uses a > pthread to make the request. > > It seems that there's an API to use "thread specific data" or > TSD by using pthread_key_create() and akin functions. Does anyone > know if this is the only way, or an URL of a good tutorial on how > to do this? Thread specific data is a solution, but I'd recommend avoiding it as much as possible. There should be a way to figure out what is going on with your memory leaks... Hope this helps, -- Livio B. Soares

Nov. 16, 2004

Re: [Dillo-dev]dns error with static dillo

by Jorge Arellano Cid

On Tue, Nov 16, 2004 at 05:18:50PM +0100, Roberto A. Foglietta wrote: > Hi, > > please try to reproduce this bug: I've compiled dillo with -static in > linking but 0.8.2 --> 0.8.4rc1 show the same problem: dns error! It works here. i.e. relinking by adding "-static" to the default make process. > [roberto@wsraf src]$ ./dillo > > Gdk-WARNING **: locale not supported by C library > > GLib-WARNING **: getpwuid_r(): failed due to: No such user 1309. Dillo doesn't call getpwuid_r(). You're having problems with gdk (locale) and glib (getpwuid_r). > > Gtk-WARNING **: libc.so.6: cannot handle TLS data ... and TLS. > > Gtk-WARNING **: libc.so.6: cannot handle TLS data > > Gtk-WARNING **: libc.so.6: cannot handle TLS data > > Gtk-WARNING **: libc.so.6: cannot handle TLS data > > Gtk-WARNING **: libc.so.6: cannot handle TLS data > > Gtk-WARNING **: libc.so.6: cannot handle TLS data > > Gtk-WARNING **: libc.so.6: cannot handle TLS data > > Gtk-WARNING **: libc.so.6: cannot handle TLS data > dillo_dns_init: Here we go! > Disabling cookies. > Nav_open_url: Url=>about:splash< > Nav_open_url: Url=>http://www.lugge.net< > Dns_server [0]: www.lugge.net is (nil) > Dillo: normal exit! No problem here to solve http://www.lugge.net with a "static" dillo. You can try with the "C" locale. If the problem persists, it may be a library configuration problem. -- Cheers Jorge.-

Nov. 16, 2004

[Dillo-dev]refresh tag patch for 0.8.4 (and fix)

by Roberto A. Foglietta

Hi, previous patch was little buggy, I hope this is better and it's against the last version I know. I hope you will interested in apply it. :-) Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Nov. 16, 2004

[Dillo-dev]dns error with static dillo

by Roberto A. Foglietta

Hi, please try to reproduce this bug: I've compiled dillo with -static in linking but 0.8.2 --> 0.8.4rc1 show the same problem: dns error! [roberto@wsraf src]$ ./dillo Gdk-WARNING **: locale not supported by C library GLib-WARNING **: getpwuid_r(): failed due to: No such user 1309. Gtk-WARNING **: libc.so.6: cannot handle TLS data Gtk-WARNING **: libc.so.6: cannot handle TLS data Gtk-WARNING **: libc.so.6: cannot handle TLS data Gtk-WARNING **: libc.so.6: cannot handle TLS data Gtk-WARNING **: libc.so.6: cannot handle TLS data Gtk-WARNING **: libc.so.6: cannot handle TLS data Gtk-WARNING **: libc.so.6: cannot handle TLS data Gtk-WARNING **: libc.so.6: cannot handle TLS data dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://www.lugge.net< Dns_server [0]: www.lugge.net is (nil) Dillo: normal exit! -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Nov. 16, 2004

[Dillo-dev]pthreads

by Jorge Arellano Cid

Hi, Is anyone here savvy on using dynamic memory allocation in pthreads? The problem: while hunting a bug that showed after the large parser orthogonalization patch, it was finally found between dillo and the file dpi server; it was a critical race. I recoded the file server to use pthreads and it went away, but... ... the new file server started to increase dramatically its virtual size. The threads are allocating memory and freeing it with the usual g_malloc/g_free pair, but it seems like these blocks remain allocated even after the thread is finished. This may be the same root for the reload memory leak pointed somtime ago, do you remember? The IO engine uses a pthread to make the request. It seems that there's an API to use "thread specific data" or TSD by using pthread_key_create() and akin functions. Does anyone know if this is the only way, or an URL of a good tutorial on how to do this? Note that the file server problem can be solved by using a dpi filter instead of a server, but as pthreads are being used in other parts of Dillo, this becomes very important to know. -- Cheers Jorge.-

Nov. 16, 2004

[Dillo-dev]https by lynx -source

by Hanspeter Roth

Hello, I don't know where to post feature requests. So I try here. Could one do a preliminary implementation of HTTPS (SSL) via piping to `lynx -source %s'? -Hanspeter

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by Roberto A. Foglietta

Riccardo Mottola wrote: > robert w hall wrote: > > >>>Suggest: use directfb combined with gtk eventually >> >>will that translate easily across all machine architectures? > > > absolutely not. WHile Motif/lesstif is. > Lars explain his point of view very well. I'm not able to be so much clear as him but you didn't understood my mail: - directfb could free dillo from X11 but still running on X and you still continue to use gtk which call code is mixed up with other Dillo code. Because DirectFB is an abstraction layer of FB is much more possibility to port DirectFB on different arch than X. DirectFB doesn't need gtk either so one day you could choose to use them as FB abstraction layer AND as graphic library toolkit Cheers -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by Lars Segerlund

All in this case means, ( I think ), that gtk can run on a framebuffer device without X as well as under X11, ( and GNOME / KDE ) since that toolkit has a quite solid abstraction. As discussed previously however, gtk ( 2 ) has a ton of dependencies since there has not been any work to reduce them, thus it is BIG and SLOW compared to more light weight approaches. Using a toolkit built on top of Xt on the on the other hand trades some portability, ( need's X11 ), for speed, size and a bit more low level handling of the callbacks and action tables. It is possible to have some toolkits run on 'raw' graphics devices though. / Lars Segerlund. On Mon, 15 Nov 2004 11:00:12 +0000 robert w hall <bobh(a)n-cantrell.demon.co.uk> wrote: > In article <41987D95.7010209(a)sad.it>, Roberto A. Foglietta > <roberto.foglietta(a)sad.it> writes > >Lars Segerlund wrote: > >> There has been a lot of talk about toolkits and dillo, and I had a small > >idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can > >bring only the widgets you need ) and if done with some care a statically linked > >dillo would not be bloated. > > > > Suggest: use directfb combined with gtk eventually > > will that translate easily across all machine architectures? > > > > > > Cheers, > > -- > robert w hall > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 15, 2004