November 2004 - Dillo-dev - lists.mailman3.com

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