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

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

[Dillo-dev]Orthogonalize the parser (leaks, XML, CSS)

by Jorge Arellano Cid

Hi there, I'm devoted 100% to this task now. It started as a small polish and ended being a huge patch. It's incredible how tricky optional tags can get when combined into a pot of tag soup! :-) Add, memory management (almost done), validation, HTML+XML soup and you'll get the idea. I'm testing now. It seems pretty good by now, but there's a page where it hangs dillo with almost no CPU consumption. A riddle to solve... -- Cheers Jorge.-

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by Riccardo Mottola

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. -R

Nov. 15, 2004