- Dillo-dev - lists.mailman3.com

youtube-dl

by onepoint＠starurchin.org

corvid wrote: > Maybe it would be nice to have the dpis able to register interest in > resources meeting certain criteria or something. Or maybe the trick > is to simply :) implement the NPAPI. ??? What is this "NPAPI" of which you speak, Earth being? :-) I guess I've not been keeping up. Jeremy Henty

July 3, 2010

youtube-dl

by corvid＠lavabit.com

Jeremy wrote: > The problem is that, last time I looked at any > rate, dpis are invoked by specific URL schemes. What I'm thinking of > would require dillo to invoke dpis when it sees particular bits of > HTML. That might be non-trivial to implement. Yeah, everything's awfully hardcoded in capi.c. I imagine it would require a fair amount of untangling and thinking. Maybe it would be nice to have the dpis able to register interest in resources meeting certain criteria or something. Or maybe the trick is to simply :) implement the NPAPI. BTW, for <object>s, I remember from the html4 spec that one is _supposed_ to use the data attribute, but nearly everyone ignores that and just makes up a... <param movie=[url]> tag instead, IIRC.

July 3, 2010

youtube-dl

by onepoint＠starurchin.org

robert w hall wrote: > Would it be 'easy' to turn youtube-dl (written in python) into a > dillo 'plugin'?? That's a fun idea! I'm a big fan of youtube-dl. But I'm not sure what you're suggesting. My dream would be to click on an embedded youtube video and have the download dpi (or something else like it) pull down the video. The problem is that, last time I looked at any rate, dpis are invoked by specific URL schemes. What I'm thinking of would require dillo to invoke dpis when it sees particular bits of HTML. That might be non-trivial to implement. As a side question, how much work would it be to get dillo to render <embed> and <object> elements in a useful way? Now there's a thought! How about if dillo rendered them as clickable boxes linked to some URL like embed://?html=<escaped_html>? Then they could be handled by a dpi that might eg. extract Youtube video URLs and run youtube-dl! Does this sound feasible? Regards, Jeremy Henty

July 2, 2010

youtube-dl

by bobh＠n-cantrell.demon.co.uk

Would it be 'easy' to turn youtube-dl (written in python) into a dillo 'plugin'?? Bopb -- robert w hall

July 1, 2010

youtube-dl

by bobh＠n-cantrell.demon.co.uk

Would it be 'easy' to turn youtube-dl (written in python) into a dillo 'plugin'?? Bopb -- robert w hall

July 1, 2010

Re: dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

On Wed, 23 Jun 2010 09:19:10 -0400, Dennis Nezic wrote: > On Sun, 20 Jun 2010 10:02:50 -0400, Jorge Arellano Cid wrote: > > Hi, > > > > At this point, there seems to be something wrong with the way > > the OS is handling its sockets and making them available to the > > application (after all, the freezes happen within system calls). > > > > Please try dillo and don't use any dpis, this will use remote > > TCP sockets only. Just plain web browsing. If this doesn't > > freeze, then there's a problem with local sockets. > > Yea -- the freezes only occur with the dpis. (Either cookie-websites > or local file browsing, or bookmarks, etc) > > > > > If plain web browsing works, you can try letting a chance to > > the OS's defaults by commenting setsockopt in: > > > > IO/dpi.c // line 442 in repo > > dpid/dpid.c // line 525 in repo > > > > recompile > > stop dpid // `dpidc stop` > > reinstall // make install > > retry > > That actually helped! I hesitated to post, because I did get one > freeze a few days ago when trying to download a file (file.c), I > didn't strace it to find which call exactly caused it, but otherwise > that did seem to fix things! (Any ideas why the TCP_NODELAY flag is > causing problems? :P) I should have hesitated. The freezes are back, about as frequently as before. But I guess there's nothing dillo can do about it :\. socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5 connect(5, {sa_family=AF_INET, sin_port=htons(5020), sin_addr=inet_addr ("127.0.0.1")}, 16 **~minute freeze**) = -1 ETIMEDOUT (Connection timed out)

June 27, 2010

Alan Carvalho has invited you to Dropbox

by no-reply＠dropbox.com

We're excited to let you know that Alan Carvalho has invited you to Dropbox! Alan Carvalho has been using Dropbox to sync and share files online and across computers, and thought you might want it too. Visit http://www.dropbox.com/link/20.GFKyIROmjL/NjIzMDg4ODE1Nw to get started. - The Dropbox Team ____________________________________________________ To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/8dacc7789c57/dillo-dev%40dillo.org

June 24, 2010

Alan Carvalho has invited you to Dropbox

by no-reply＠dropbox.com

We're excited to let you know that Alan Carvalho has invited you to Dropbox! Alan Carvalho has been using Dropbox to sync and share files online and across computers, and thought you might want it too. Visit http://www.dropbox.com/link/20.dYwO4oi49R/NjIzMDg3OTkwNw to get started. - The Dropbox Team ____________________________________________________ To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/781c725708e5/dillo-dev%40auriga.wearlab.de

June 24, 2010

Alan Carvalho has invited you to Dropbox

by no-reply＠dropbox.com

We're excited to let you know that Alan Carvalho has invited you to Dropbox! Alan Carvalho has been using Dropbox to sync and share files online and across computers, and thought you might want it too. Visit http://www.dropbox.com/link/20.Qt_XbCeuJe/NjIzMDg3MTk5Nw to get started. - The Dropbox Team ____________________________________________________ To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/e797f9c25f98/dillo-dev%40lists.auriga.wearlab.de

June 24, 2010

Re: dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

On Sun, 20 Jun 2010 10:02:50 -0400, Jorge Arellano Cid wrote: > Hi, > > At this point, there seems to be something wrong with the way > the OS is handling its sockets and making them available to the > application (after all, the freezes happen within system calls). > > Please try dillo and don't use any dpis, this will use remote > TCP sockets only. Just plain web browsing. If this doesn't > freeze, then there's a problem with local sockets. Yea -- the freezes only occur with the dpis. (Either cookie-websites or local file browsing, or bookmarks, etc) > > If plain web browsing works, you can try letting a chance to > the OS's defaults by commenting setsockopt in: > > IO/dpi.c // line 442 in repo > dpid/dpid.c // line 525 in repo > > recompile > stop dpid // `dpidc stop` > reinstall // make install > retry That actually helped! I hesitated to post, because I did get one freeze a few days ago when trying to download a file (file.c), I didn't strace it to find which call exactly caused it, but otherwise that did seem to fix things! (Any ideas why the TCP_NODELAY flag is causing problems? :P)

June 23, 2010

dillorc default font section

by rogerx＠sdf.org

On Sun, Jun 20, 2010 at 09:47:28AM -0400, Jorge Arellano Cid wrote: >On Sat, Jun 19, 2010 at 08:30:33PM +0000, corvid wrote: >> Do you have any opinions on something like: >> >> # Default fonts: >> # >> # If FLTK2 has been configured with Xft enabled (the default), you can >> # use scalable fonts such as DejaVu or Liberation (try running "fc-list"). >> #font_serif="DejaVu Serif" >> #font_sans_serif="DejaVu Sans" >> #font_cursive="URW Chancery L" >> #font_fantasy="DejaVu Sans" >> #font_monospace="DejaVu Sans Mono" >> # >> # Otherwise, use bitmapped fonts like the following (for a list, try running >> # "xlsfonts -fn *-iso10646-1 | grep -v -e -0-0 | cut -d - -f 3 | sort | uniq"). >> # font_serif="times" >> # font_sans_serif="helvetica" >> # font_cursive="helvetica" >> # font_fantasy="helvetica" >> # font_monospace="courier" >> >> If there's a nicer way to get the second list, that would be, well, nice :) > > I don't know of a better way to list them. > OTOH, the above command is just one copy&paste away. Enough for me! > In reference to post "Unexplained Dillo Segfault" concerning var font bug in fltk, all I know is on a default install of xorg, xorg provides a default fixed bitmap font. I don't know of a default variable font. My knowledge is slim at best here, besides running a stand alone Xorg install here without any other stuff I don't need. $ xlsfonts -fn *-iso10646-1 | grep -v -e -0-0 | cut -d - -f 3 | sort | uniq terminus But I only installed terminus fonts because I recently found out how readable they are on framebuffer console! In Xorg, I usually use bitstream-vera. -- Roger http://rogerx.freeshell.org/

June 20, 2010

Re: dillo mysteriously freezes

by jcid＠dillo.org

Hi, At this point, there seems to be something wrong with the way the OS is handling its sockets and making them available to the application (after all, the freezes happen within system calls). Please try dillo and don't use any dpis, this will use remote TCP sockets only. Just plain web browsing. If this doesn't freeze, then there's a problem with local sockets. If plain web browsing works, you can try letting a chance to the OS's defaults by commenting setsockopt in: IO/dpi.c // line 442 in repo dpid/dpid.c // line 525 in repo recompile stop dpid // `dpidc stop` reinstall // make install retry If it doesn't work, check with dillo-2.0. If it works (dpis included) we'll assert it's a problem with the OS and the handling of local TCP sockets. HTH. On Sat, Jun 19, 2010 at 01:54:33AM +0000, corvid wrote: > Dennis wrote: > > Hrrm, although I don't have blackhole (I run "normal" Gentoo here) after > > I strace'ed dillo during the freezes, it might be related. > > > > Here is the part of the strace immediately before and after the > > freeze(s): > > > > 2:24: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6 > > 2:24: setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > > **freeze** > > 2:45: connect(6, {sa_family=AF_INET, sin_port=htons(5020), > > sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed > > out) > > 2:45: write(1, "Dpi_check_dpid_ids: Connection > > t"...,41Dpi_check_dpid_ids: Connection timed out > > > > (and a bit later, another freeze:) > > > > 2:46: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 > > 2:46: setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > > **freeze** > > 3:07: connect(7, {sa_family=AF_INET, sin_port=htons(5029), > > sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed > > out) > > 3:07: write(1, "Dpi_get_server_port: Connection > > "...,42Dpi_get_server_port: Connection timed out 3:07: ) = 42 > > > > Here is a more complete strace: > > http://dennisn.dyndns.org/guest/pubstuff/dillo-strace-freeze > > > > Any idea what else can be causing these timeouts? :\ > > I already used up my relevant TCP knowledge on my previous guess... -- Cheers Jorge.-

June 20, 2010

dillorc default font section

by jcid＠dillo.org

On Sat, Jun 19, 2010 at 08:30:33PM +0000, corvid wrote: > Do you have any opinions on something like: > > # Default fonts: > # > # If FLTK2 has been configured with Xft enabled (the default), you can > # use scalable fonts such as DejaVu or Liberation (try running "fc-list"). > #font_serif="DejaVu Serif" > #font_sans_serif="DejaVu Sans" > #font_cursive="URW Chancery L" > #font_fantasy="DejaVu Sans" > #font_monospace="DejaVu Sans Mono" > # > # Otherwise, use bitmapped fonts like the following (for a list, try running > # "xlsfonts -fn *-iso10646-1 | grep -v -e -0-0 | cut -d - -f 3 | sort | uniq"). > # font_serif="times" > # font_sans_serif="helvetica" > # font_cursive="helvetica" > # font_fantasy="helvetica" > # font_monospace="courier" > > If there's a nicer way to get the second list, that would be, well, nice :) I don't know of a better way to list them. OTOH, the above command is just one copy&paste away. Enough for me! -- Cheers Jorge.-

June 20, 2010

Re: [dillo 2.2] CSS bug?

by johannes.hofmann＠gmx.de

Hi, sorry for the huge delay. I only have limited Internet access atm. The problem you are seeing is that dillo 2.2 does not render headlines and paragraphs (h1,h2,...,p) as separate boxes. Therefore the box model is not applied properly. My display prototype ( http://flpsed.org/hgweb/dillo_display ) should handle these cases better. I plan to integrate this into dillo mainline. Cheers, Johannes

June 20, 2010

dillorc default font section

by corvid＠lavabit.com

Do you have any opinions on something like: # Default fonts: # # If FLTK2 has been configured with Xft enabled (the default), you can # use scalable fonts such as DejaVu or Liberation (try running "fc-list"). #font_serif="DejaVu Serif" #font_sans_serif="DejaVu Sans" #font_cursive="URW Chancery L" #font_fantasy="DejaVu Sans" #font_monospace="DejaVu Sans Mono" # # Otherwise, use bitmapped fonts like the following (for a list, try running # "xlsfonts -fn *-iso10646-1 | grep -v -e -0-0 | cut -d - -f 3 | sort | uniq"). # font_serif="times" # font_sans_serif="helvetica" # font_cursive="helvetica" # font_fantasy="helvetica" # font_monospace="courier" If there's a nicer way to get the second list, that would be, well, nice :)

June 19, 2010

Re: dillo mysteriously freezes

by corvid＠lavabit.com

Dennis wrote: > Hrrm, although I don't have blackhole (I run "normal" Gentoo here) after > I strace'ed dillo during the freezes, it might be related. > > Here is the part of the strace immediately before and after the > freeze(s): > > 2:24: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6 > 2:24: setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > **freeze** > 2:45: connect(6, {sa_family=AF_INET, sin_port=htons(5020), > sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed > out) > 2:45: write(1, "Dpi_check_dpid_ids: Connection > t"...,41Dpi_check_dpid_ids: Connection timed out > > (and a bit later, another freeze:) > > 2:46: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 > 2:46: setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > **freeze** > 3:07: connect(7, {sa_family=AF_INET, sin_port=htons(5029), > sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed > out) > 3:07: write(1, "Dpi_get_server_port: Connection > "...,42Dpi_get_server_port: Connection timed out 3:07: ) = 42 > > Here is a more complete strace: > http://dennisn.dyndns.org/guest/pubstuff/dillo-strace-freeze > > Any idea what else can be causing these timeouts? :\ I already used up my relevant TCP knowledge on my previous guess... > Oh, by the way, while I was testing the bookmarks.dpi (by loading > "dpi:/bm/") and refreshing repeatedly, not only did I get the freeze, > but I also managed to get a Segmentation Fault :s... > > Nav_open_url: new url='dpi:/bm/' > [fopen]: No such file or directory > a_Nav_expect_done: reload! > Nav_open_url: new url='dpi:/bm/' > [dpi::connect] errno:110 Connection timed out > ** ERROR **: dpi.c: can't start dpi daemon > [New Thread 0x7f6945a41720 (LWP 31505)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7f6945a41720 (LWP 31505)] > ---Type <return> to continue, or q <return> to quit--- > 0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 > (gdb) bt > #0 0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 > #1 0x000000000043de72 in dStrdup () > #2 0x0000000000414dd7 in Url_object_new () > #3 0x0000000000415247 in a_Url_dup () > #4 0x0000000000410b68 in a_Bw_add_url () > #5 0x00000000004175d3 in Nav_open_url () > #6 0x00007f6944e564cf in fltk::wait () from /usr/lib64/fltk/libfltk2.so > #7 0x00007f6944e56595 in fltk::run () from /usr/lib64/fltk/libfltk2.so > #8 0x000000000040af23 in main () It doesn't break for me, unfortunately. I imagine that must be from Nav_reload_callback(). Maybe Jorge will know could happen to the a_History_get_url(NAV_TOP_UIDX(bw)) by the time that fltk gets around to calling it.

June 19, 2010

Re: dillo mysteriously freezes

by rogerx＠sdf.org

On Fri, Jun 18, 2010 at 04:56:05PM -0400, Dennis Nezic wrote: >Hrrm, although I don't have blackhole (I run "normal" Gentoo here) after >I strace'ed dillo during the freezes, it might be related. I use Gentoo here too, and use the following USE Flags: =x11-libs/fltk-2.0_pre697 jpeg png xft zlib =www-client/dillo-2.2 gif ipv6 jpeg png ssl >Program received signal SIGSEGV, Segmentation fault. >[Switching to Thread 0x7f6945a41720 (LWP 31505)] >---Type <return> to continue, or q <return> to quit--- >0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 >(gdb) bt >#0 0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 >#1 0x000000000043de72 in dStrdup () >#2 0x0000000000414dd7 in Url_object_new () >#3 0x0000000000415247 in a_Url_dup () >#4 0x0000000000410b68 in a_Bw_add_url () >#5 0x00000000004175d3 in Nav_open_url () >#6 0x00007f6944e564cf in fltk::wait () from /usr/lib64/fltk/libfltk2.so >#7 0x00007f6944e56595 in fltk::run () from /usr/lib64/fltk/libfltk2.so >#8 0x000000000040af23 in main () I don't see this problem here. CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer" =sys-devel/gcc-4.3.4 fortran mudflap nls nptl openmp =sys-devel/gcc-4.4.3-r2 fortran mudflap nls nptl openmp =sys-libs/glibc-2.10.1-r1 nls If there's info I can provide for comparison, let me know. I only saw the "variable font segfault" and was solved by building fltk with xft USE Flag. Following fonts are installed here: media-fonts/arkpandora media-fonts/dejavu media-fonts/encodings media-fonts/font-alias media-fonts/font-bitstream-100dpi media-fonts/font-bitstream-type1 media-fonts/terminus-font media-fonts/ttf-bitstream-vera media-fonts/urw-fonts virtual/ttf-fonts x11-apps/mkfontscale x11-proto/fontsproto Using pretty much a bare install here using minimal number of packages to get X working with DWM. -- Roger http://rogerx.freeshell.org/

June 19, 2010

Re: dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

On Fri, 18 Jun 2010 00:25:32 +0000, corvid wrote: > Dennis wrote: > > On Thu, 17 Jun 2010 21:37:23 +0000, corvid wrote: > > > Jeremy wrote: > > > > On Thu, Jun 17, 2010 at 02:42:19PM -0400, Dennis Nezic wrote: > > > > > > > > > Interesting. It appears that I only get these freezes when > > > > > I have cookies enabled. If I set my cookiesrc file back to > > > > > "DEFAULT DENY" (with no "hostname ACCEPT" afterwards), I no > > > > > longer get the freezes. > > > > > > > > That's useful confirmation that it's a cookies problem. > > > > > > Does the DPI stuff work otherwise? Bookmarks, https:, file:... > > > > Bah. It looks like all the dpi stuff is commonly affected. I tried > > browsing locally with file:// and the same thing occurred. It also > > did unfreeze after about a minute. > > I wonder whether you're using blackhole by any chance. > > The issue was brought up in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-January/007247.html > and at least seemed to be resolved in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-February/007283.html Hrrm, although I don't have blackhole (I run "normal" Gentoo here) after I strace'ed dillo during the freezes, it might be related. Here is the part of the strace immediately before and after the freeze(s): 2:24: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6 2:24: setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 **freeze** 2:45: connect(6, {sa_family=AF_INET, sin_port=htons(5020), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed out) 2:45: write(1, "Dpi_check_dpid_ids: Connection t"...,41Dpi_check_dpid_ids: Connection timed out (and a bit later, another freeze:) 2:46: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 2:46: setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0 **freeze** 3:07: connect(7, {sa_family=AF_INET, sin_port=htons(5029), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed out) 3:07: write(1, "Dpi_get_server_port: Connection "...,42Dpi_get_server_port: Connection timed out 3:07: ) = 42 Here is a more complete strace: http://dennisn.dyndns.org/guest/pubstuff/dillo-strace-freeze Any idea what else can be causing these timeouts? :\ Oh, by the way, while I was testing the bookmarks.dpi (by loading "dpi:/bm/") and refreshing repeatedly, not only did I get the freeze, but I also managed to get a Segmentation Fault :s... Nav_open_url: new url='dpi:/bm/' [fopen]: No such file or directory a_Nav_expect_done: reload! Nav_open_url: new url='dpi:/bm/' [dpi::connect] errno:110 Connection timed out ** ERROR **: dpi.c: can't start dpi daemon [New Thread 0x7f6945a41720 (LWP 31505)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f6945a41720 (LWP 31505)] ---Type <return> to continue, or q <return> to quit--- 0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 #1 0x000000000043de72 in dStrdup () #2 0x0000000000414dd7 in Url_object_new () #3 0x0000000000415247 in a_Url_dup () #4 0x0000000000410b68 in a_Bw_add_url () #5 0x00000000004175d3 in Nav_open_url () #6 0x00007f6944e564cf in fltk::wait () from /usr/lib64/fltk/libfltk2.so #7 0x00007f6944e56595 in fltk::run () from /usr/lib64/fltk/libfltk2.so #8 0x000000000040af23 in main ()

June 18, 2010

Re: dillo mysteriously freezes

by corvid＠lavabit.com

Dennis wrote: > On Thu, 17 Jun 2010 21:37:23 +0000, corvid wrote: > > Jeremy wrote: > > > On Thu, Jun 17, 2010 at 02:42:19PM -0400, Dennis Nezic wrote: > > > > > > > Interesting. It appears that I only get these freezes when I > > > > have cookies enabled. If I set my cookiesrc file back to > > > > "DEFAULT DENY" (with no "hostname ACCEPT" afterwards), I no > > > > longer get the freezes. > > > > > > That's useful confirmation that it's a cookies problem. > > > > Does the DPI stuff work otherwise? Bookmarks, https:, file:... > > Bah. It looks like all the dpi stuff is commonly affected. I tried > browsing locally with file:// and the same thing occurred. It also did > unfreeze after about a minute. I wonder whether you're using blackhole by any chance. The issue was brought up in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-January/007247.html and at least seemed to be resolved in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-February/007283.html

June 18, 2010

Re: dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

On Thu, 17 Jun 2010 21:37:23 +0000, corvid wrote: > Jeremy wrote: > > On Thu, Jun 17, 2010 at 02:42:19PM -0400, Dennis Nezic wrote: > > > > > Interesting. It appears that I only get these freezes when I > > > have cookies enabled. If I set my cookiesrc file back to > > > "DEFAULT DENY" (with no "hostname ACCEPT" afterwards), I no > > > longer get the freezes. > > > > That's useful confirmation that it's a cookies problem. > > Does the DPI stuff work otherwise? Bookmarks, https:, file:... Bah. It looks like all the dpi stuff is commonly affected. I tried browsing locally with file:// and the same thing occurred. It also did unfreeze after about a minute. > > > > > ps -ef | grep dpi doesn't show anything interesting: > > > 1533 1 0 14:31 ? 00:00:00 dpid > > > 1534 1533 0 14:31 ? > > > 00:00:00 /usr/lib64/dillo/dpi/cookies/cookies.dpi > > > > It shows that neither the DPI daemon or the cookies DPI have > > crashed, which is something. I wonder what the cookies DPI is > > doing? Does anyone know how to attach gdb to the cookies DPI > > and see where it's at? > > gdb /usr/lib64/dillo/dpi/cookies/cookies.dpi 1534 > or something along those lines...

June 18, 2010

Re: dillo mysteriously freezes

by corvid＠lavabit.com

Jeremy wrote: > On Thu, Jun 17, 2010 at 02:42:19PM -0400, Dennis Nezic wrote: > > > Interesting. It appears that I only get these freezes when I have > > cookies enabled. If I set my cookiesrc file back to "DEFAULT DENY" > > (with no "hostname ACCEPT" afterwards), I no longer get the freezes. > > That's useful confirmation that it's a cookies problem. Does the DPI stuff work otherwise? Bookmarks, https:, file:... > > ps -ef | grep dpi doesn't show anything interesting: > > 1533 1 0 14:31 ? 00:00:00 dpid > > 1534 1533 0 14:31 ? 00:00:00 /usr/lib64/dillo/dpi/cookies/cookies.dpi > > It shows that neither the DPI daemon or the cookies DPI have crashed, > which is something. I wonder what the cookies DPI is doing? Does > anyone know how to attach gdb to the cookies DPI and see where it's > at? gdb /usr/lib64/dillo/dpi/cookies/cookies.dpi 1534 or something along those lines...

June 17, 2010

Re: dillo mysteriously freezes

by onepoint＠starurchin.org

On Thu, Jun 17, 2010 at 02:42:19PM -0400, Dennis Nezic wrote: > Interesting. It appears that I only get these freezes when I have > cookies enabled. If I set my cookiesrc file back to "DEFAULT DENY" > (with no "hostname ACCEPT" afterwards), I no longer get the freezes. That's useful confirmation that it's a cookies problem. > ps -ef | grep dpi doesn't show anything interesting: > 1533 1 0 14:31 ? 00:00:00 dpid > 1534 1533 0 14:31 ? 00:00:00 /usr/lib64/dillo/dpi/cookies/cookies.dpi It shows that neither the DPI daemon or the cookies DPI have crashed, which is something. I wonder what the cookies DPI is doing? Does anyone know how to attach gdb to the cookies DPI and see where it's at? Regards, Jeremy Henty

June 17, 2010

Re: dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

On Thu, 17 Jun 2010 19:03:32 +0100, Jeremy Henty wrote: > On Thu, Jun 17, 2010 at 01:36:47PM -0400, Dennis Nezic wrote: > > > (gdb) bt > > #0 0x00007f3cca17089d in connect () from /lib/libpthread.so.0 > > #1 0x000000000044227e in Dpi_connect_socket () > > #2 0x0000000000442f6f in a_Dpi_send_blocking_cmd () > > #3 0x0000000000411115 in a_Cookies_get_query () > > #4 0x000000000044098d in a_Http_make_query_str () > > #5 0x0000000000441481 in Http_connect_queued_sockets () > > #6 0x00000000004375da in Dns_timeout_client () > > #7 0x00007f3ccac8c4cf in fltk::wait () > > #from /usr/lib64/fltk/libfltk2.so 8 0x00007f3ccac8c595 in > > #fltk::run () from /usr/lib64/fltk/libfltk2.so 9 > > #0x000000000040af23 in main () > > It looks as though Dillo is waiting for an answer from the cookies DPI > and not getting one. What is the output of "ps -ef | grep dpi"? It > would also be useful if you could save the output of Dillo to a log > file and send it (it's unlikely to be a large file if Dillo hangs > after a few seconds). Interesting. It appears that I only get these freezes when I have cookies enabled. If I set my cookiesrc file back to "DEFAULT DENY" (with no "hostname ACCEPT" afterwards), I no longer get the freezes. ps -ef | grep dpi doesn't show anything interesting: 1533 1 0 14:31 ? 00:00:00 dpid 1534 1533 0 14:31 ? 00:00:00 /usr/lib64/dillo/dpi/cookies/cookies.dpi Sometimes, however, my cpu stalls at 100%, I think caused by dpid, but top only shows 17% from it -- (the rest I assume is some lower level system hook?) -- but this doesn't always happen. Also, I did see dillo unfreeze once, after a few seconds -- but that is rare.

June 17, 2010

Re: dillo mysteriously freezes

by onepoint＠starurchin.org

On Thu, Jun 17, 2010 at 01:36:47PM -0400, Dennis Nezic wrote: > (gdb) bt > #0 0x00007f3cca17089d in connect () from /lib/libpthread.so.0 > #1 0x000000000044227e in Dpi_connect_socket () > #2 0x0000000000442f6f in a_Dpi_send_blocking_cmd () > #3 0x0000000000411115 in a_Cookies_get_query () > #4 0x000000000044098d in a_Http_make_query_str () > #5 0x0000000000441481 in Http_connect_queued_sockets () > #6 0x00000000004375da in Dns_timeout_client () > #7 0x00007f3ccac8c4cf in fltk::wait () from /usr/lib64/fltk/libfltk2.so > #8 0x00007f3ccac8c595 in fltk::run () from /usr/lib64/fltk/libfltk2.so > #9 0x000000000040af23 in main () It looks as though Dillo is waiting for an answer from the cookies DPI and not getting one. What is the output of "ps -ef | grep dpi"? It would also be useful if you could save the output of Dillo to a log file and send it (it's unlikely to be a large file if Dillo hangs after a few seconds). Regards, Jeremy Henty

June 17, 2010

Re: dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

On Thu, 17 Jun 2010 11:14:43 -0400, Jorge Arellano Cid wrote: > On Thu, Jun 17, 2010 at 09:44:03AM -0400, Dennis Nezic wrote: > > I seem to be experiencing a very nasty bug that breaks my Dillo. A > > few seconds after starting dillo, it "freezes" -- standard-output > > stops, the graphics freeze and never get redrawn (resulting in those > > psychodelic effects of moving windows over a non-redrawing window). > > My dillo window then doesn't respond to my window manager's "close" > > events, and I have to manually kill it. > > > > I can't give you the exact steps to reproduce it -- sometimes it's > > like this immediately after starting ... sometimes it magically > > starts to happen a few seconds afterwards -- possibly after I click > > on a link. > > > > dillo-2.2 > > fltk-2_pre7513 (I also tried with earlier versions (6970)) > > > > Ideas? > > gdb dillo > <dillo freezes somewhere here> > ctrl-c > bt > > And send us the gdb backtrace. (gdb) bt #0 0x00007f3cca17089d in connect () from /lib/libpthread.so.0 #1 0x000000000044227e in Dpi_connect_socket () #2 0x0000000000442f6f in a_Dpi_send_blocking_cmd () #3 0x0000000000411115 in a_Cookies_get_query () #4 0x000000000044098d in a_Http_make_query_str () #5 0x0000000000441481 in Http_connect_queued_sockets () #6 0x00000000004375da in Dns_timeout_client () #7 0x00007f3ccac8c4cf in fltk::wait () from /usr/lib64/fltk/libfltk2.so #8 0x00007f3ccac8c595 in fltk::run () from /usr/lib64/fltk/libfltk2.so #9 0x000000000040af23 in main () I don't know if this helps -- but that's the bt for dillo after I ctrl-c, after the graphics/ui becomes unresponsive.

June 17, 2010

dillo mysteriously freezes

by jcid＠dillo.org

On Thu, Jun 17, 2010 at 09:44:03AM -0400, Dennis Nezic wrote: > I seem to be experiencing a very nasty bug that breaks my Dillo. A few > seconds after starting dillo, it "freezes" -- standard-output stops, > the graphics freeze and never get redrawn (resulting in those > psychodelic effects of moving windows over a non-redrawing window). My > dillo window then doesn't respond to my window manager's "close" > events, and I have to manually kill it. > > I can't give you the exact steps to reproduce it -- sometimes it's like > this immediately after starting ... sometimes it magically starts to > happen a few seconds afterwards -- possibly after I click on a link. > > dillo-2.2 > fltk-2_pre7513 (I also tried with earlier versions (6970)) > > Ideas? gdb dillo <dillo freezes somewhere here> ctrl-c bt And send us the gdb backtrace. -- Cheers Jorge.-

June 17, 2010

dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

I seem to be experiencing a very nasty bug that breaks my Dillo. A few seconds after starting dillo, it "freezes" -- standard-output stops, the graphics freeze and never get redrawn (resulting in those psychodelic effects of moving windows over a non-redrawing window). My dillo window then doesn't respond to my window manager's "close" events, and I have to manually kill it. I can't give you the exact steps to reproduce it -- sometimes it's like this immediately after starting ... sometimes it magically starts to happen a few seconds afterwards -- possibly after I click on a link. dillo-2.2 fltk-2_pre7513 (I also tried with earlier versions (6970)) Ideas?

June 17, 2010

Unexplained Dillo Segfault

by rogerx＠sdf.org

On Wed, Jun 16, 2010 at 04:00:49PM +0000, corvid wrote: >rogerx wrote: >> Re-built fltk using "xft", and all seems quiet so far -- no signs of segfault. > >Oh, good good good... OK. Just rambling some thoughts to make sure I have things correct. When I get a chance today, I'll try to open a bug on bugs.gentoo.org concerning this missing runtime depend for a variable font. -- Roger http://rogerx.freeshell.org/

June 16, 2010

Unexplained Dillo Segfault

by corvid＠lavabit.com

rogerx wrote: > On Tue, Jun 15, 2010 at 06:17:11PM +0000, corvid wrote: > >Dillo is set to use DejaVu fonts by default (set in dillorc file), but your > >backtrace showed that fltk is using Font_xlfd.cxx instead of Font_xft.cxx, > >indicating that your fltk was configured with --disable-xft. > >With xft disabled, it's not going to use TTF fonts. > > For those that know this, it's a no brainer -- but obviously I don't as such > easily assumed since I installed Dejavue, it would use those fonts. :-/ Dillo prints out a warning message if it can't load one of the fonts given in dillorc. > Did the debug info (error code) seem kind of brief to you? The "bad font: variable" that fltk2 spits out? Yeah. > >If you don't mind using antialiased fonts, you could reconfigure with xft > >enabled, and recompile, and everything may just magically work. > >If not, and you like bitstream, I'd alias 'fixed' to one of the > >bitstream terminal choices, and alias 'variable' perhaps to one of the > >bitstream charter ones. (And then I think you'd have to run mkfontdir > >afterward.) > > Re-built fltk using "xft", and all seems quiet so far -- no signs of segfault. Oh, good good good... > This definitely seems like fltk cannot be built without xft -- or if without > xft -- user needs to have a variable font installed. Sounds like the package > manager script is missing a depend check. My guess is that "fixed" and "variable" may be standard enough that it's a misconfiguration not to have the aliases present and set to a font that you have, although, yeah, it's a bug in fltk2 not to handle that gracefully. > As far as having the extra eye-candy, I prefer only building/installing stuff > that's needed versus installing a mess of eye candy I don't make much use of. > Hence, the reason why I skipped building "without xft". ;-) Well, it "should" :) 1) not crash 2) print a warning to the terminal if dillo can't use the fonts that it's set to use. In any case, I should update the comments in the fonts section of dillorc to reflect the current state of things. Most/all of the text in that section hasn't been touched since the dillo1 days.

June 16, 2010

Unexplained Dillo Segfault

by rogerx＠sdf.org

On Tue, Jun 15, 2010 at 06:17:11PM +0000, corvid wrote: >rogerx wrote: >> I realize this is info overkill, but I just wanted to get something out asap. I believe I keep things minimal, and rely primarily on bitstream fonts -- with the occassional Terminus and Dejavue (as supposedly Dillo like Dejavue fonts). > >Dillo is set to use DejaVu fonts by default (set in dillorc file), but your >backtrace showed that fltk is using Font_xlfd.cxx instead of Font_xft.cxx, >indicating that your fltk was configured with --disable-xft. >With xft disabled, it's not going to use TTF fonts. For those that know this, it's a no brainer -- but obviously I don't as such easily assumed since I installed Dejavue, it would use those fonts. :-/ Did the debug info (error code) seem kind of brief to you? >If you don't mind using antialiased fonts, you could reconfigure with xft >enabled, and recompile, and everything may just magically work. >If not, and you like bitstream, I'd alias 'fixed' to one of the >bitstream terminal choices, and alias 'variable' perhaps to one of the >bitstream charter ones. (And then I think you'd have to run mkfontdir >afterward.) Re-built fltk using "xft", and all seems quiet so far -- no signs of segfault. This definitely seems like fltk cannot be built without xft -- or if without xft -- user needs to have a variable font installed. Sounds like the package manager script is missing a depend check. As far as having the extra eye-candy, I prefer only building/installing stuff that's needed versus installing a mess of eye candy I don't make much use of. Hence, the reason why I skipped building "without xft". ;-) ... yea, segfaults seemed to have ceased for now. -- Roger http://rogerx.freeshell.org/

June 16, 2010

Unexplained Dillo Segfault

by corvid＠lavabit.com

rogerx wrote: > I realize this is info overkill, but I just wanted to get something out asap. I believe I keep things minimal, and rely primarily on bitstream fonts -- with the occassional Terminus and Dejavue (as supposedly Dillo like Dejavue fonts). Dillo is set to use DejaVu fonts by default (set in dillorc file), but your backtrace showed that fltk is using Font_xlfd.cxx instead of Font_xft.cxx, indicating that your fltk was configured with --disable-xft. With xft disabled, it's not going to use TTF fonts. If you don't mind using antialiased fonts, you could reconfigure with xft enabled, and recompile, and everything may just magically work. If not, and you like bitstream, I'd alias 'fixed' to one of the bitstream terminal choices, and alias 'variable' perhaps to one of the bitstream charter ones. (And then I think you'd have to run mkfontdir afterward.)

June 15, 2010

Unexplained Dillo Segfault

by rogerx＠sdf.org

>$ eix -s bitstream -cI >[I] media-fonts/font-bitstream-100dpi (1.0.0@06/09/2010): X.Org Bitstream bitmap fonts >[I] media-fonts/font-bitstream-type1 (1.0.0@06/09/2010): X.Org Bitstream Type 1 fonts >[I] media-fonts/ttf-bitstream-vera (1.10-r3@06/09/2010): Bitstream Vera font family If I'm not mistaken, bitstream vera sans/vera serif are variable fonts. I'm a little confused as to exactly what I'm looking for as I do have several font packages installed and their font dirs are statically linked into my /etc/X11/xorg.conf file. -- Roger http://rogerx.freeshell.org/

June 15, 2010

Unexplained Dillo Segfault

by rogerx＠sdf.org

On Tue, Jun 15, 2010 at 03:36:03PM +0000, corvid wrote: >> bad font: variable > >Okay, good. Guess I'll have to start digging into the fltk font stuff >again at some point. In the meantime, let's try to make it stop breaking >for you. > >fltk's src/x11/Font_xlfd.cxx asks for "fixed" and "variable" under >certain conditions. In my case, they seem to be (looking in >/usr/lib/X11/fonts/misc/fonts.alias) >fixed -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 >variable -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-1 > >And then in my /usr/lib/X11/fonts/misc/fonts.dir, there's >6x13-ISO8859-1.pcf.gz -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 >and then /usr/lib/X11/fonts/100dpi/fonts.dir has >helvB12-ISO8859-1.pcf.gz -adobe-helvetica-bold-r-normal--17-120-100-100-p-92-iso8859-1 >and /usr/lib/X11/fonts/75dpi/fonts.dir has >helvB12-ISO8859-1.pcf.gz -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1 > >Do you have whatever font 'variable' is set to in your fonts.alias? Only one fonts.alias file: $ cat /usr/share/fonts/100dpi/fonts.alias lucidasans-bolditalic-8 -b&h-lucida-bold-i-normal-sans-11-80-100-100-p-69-iso8859-1 lucidasans-bolditalic-10 -b&h-lucida-bold-i-normal-sans-14-100-100-100-p-90-iso8859-1 lucidasans-bolditalic-12 -b&h-lucida-bold-i-normal-sans-17-120-100-100-p-108-iso8859-1 lucidasans-bolditalic-14 -b&h-lucida-bold-i-normal-sans-20-140-100-100-p-127-iso8859-1 lucidasans-bolditalic-18 -b&h-lucida-bold-i-normal-sans-25-180-100-100-p-159-iso8859-1 lucidasans-bolditalic-24 -b&h-lucida-bold-i-normal-sans-34-240-100-100-p-215-iso8859-1 lucidasans-bold-8 -b&h-lucida-bold-r-normal-sans-11-80-100-100-p-70-iso8859-1 lucidasans-bold-10 -b&h-lucida-bold-r-normal-sans-14-100-100-100-p-89-iso8859-1 lucidasans-bold-12 -b&h-lucida-bold-r-normal-sans-17-120-100-100-p-108-iso8859-1 lucidasans-bold-14 -b&h-lucida-bold-r-normal-sans-20-140-100-100-p-127-iso8859-1 lucidasans-bold-18 -b&h-lucida-bold-r-normal-sans-25-180-100-100-p-158-iso8859-1 lucidasans-bold-24 -b&h-lucida-bold-r-normal-sans-34-240-100-100-p-216-iso8859-1 lucidasans-italic-8 -b&h-lucida-medium-i-normal-sans-11-80-100-100-p-62-iso8859-1 lucidasans-italic-10 -b&h-lucida-medium-i-normal-sans-14-100-100-100-p-80-iso8859-1 lucidasans-italic-12 -b&h-lucida-medium-i-normal-sans-17-120-100-100-p-97-iso8859-1 lucidasans-italic-14 -b&h-lucida-medium-i-normal-sans-20-140-100-100-p-114-iso8859-1 lucidasans-italic-18 -b&h-lucida-medium-i-normal-sans-25-180-100-100-p-141-iso8859-1 lucidasans-italic-24 -b&h-lucida-medium-i-normal-sans-34-240-100-100-p-192-iso8859-1 lucidasans-8 -b&h-lucida-medium-r-normal-sans-11-80-100-100-p-63-iso8859-1 lucidasans-10 -b&h-lucida-medium-r-normal-sans-14-100-100-100-p-80-iso8859-1 lucidasans-12 -b&h-lucida-medium-r-normal-sans-17-120-100-100-p-96-iso8859-1 lucidasans-14 -b&h-lucida-medium-r-normal-sans-20-140-100-100-p-114-iso8859-1 lucidasans-18 -b&h-lucida-medium-r-normal-sans-25-180-100-100-p-142-iso8859-1 lucidasans-24 -b&h-lucida-medium-r-normal-sans-34-240-100-100-p-191-iso8859-1 lucidasanstypewriter-bold-8 -b&h-lucidatypewriter-bold-r-normal-sans-11-80-100-100-m-70-iso8859-1 lucidasanstypewriter-bold-10 -b&h-lucidatypewriter-bold-r-normal-sans-14-100-100-100-m-80-iso8859-1 lucidasanstypewriter-bold-12 -b&h-lucidatypewriter-bold-r-normal-sans-17-120-100-100-m-100-iso8859-1 lucidasanstypewriter-bold-14 -b&h-lucidatypewriter-bold-r-normal-sans-20-140-100-100-m-120-iso8859-1 lucidasanstypewriter-bold-18 -b&h-lucidatypewriter-bold-r-normal-sans-25-180-100-100-m-150-iso8859-1 lucidasanstypewriter-bold-24 -b&h-lucidatypewriter-bold-r-normal-sans-34-240-100-100-m-200-iso8859-1 lucidasanstypewriter-8 -b&h-lucidatypewriter-medium-r-normal-sans-11-80-100-100-m-70-iso8859-1 lucidasanstypewriter-10 -b&h-lucidatypewriter-medium-r-normal-sans-14-100-100-100-m-80-iso8859-1 lucidasanstypewriter-12 -b&h-lucidatypewriter-medium-r-normal-sans-17-120-100-100-m-100-iso8859-1 lucidasanstypewriter-14 -b&h-lucidatypewriter-medium-r-normal-sans-20-140-100-100-m-120-iso8859-1 lucidasanstypewriter-18 -b&h-lucidatypewriter-medium-r-normal-sans-25-180-100-100-m-150-iso8859-1 lucidasanstypewriter-24 -b&h-lucidatypewriter-medium-r-normal-sans-34-240-100-100-m-200-iso8859-1 And then the following fonts.dir: $ locate fonts.dir /usr/share/fonts/urw-fonts/fonts.dir /usr/share/fonts/Type1/fonts.dir /usr/share/fonts/dejavu/fonts.dir /usr/share/fonts/terminus/fonts.dir /usr/share/fonts/100dpi/fonts.dir /usr/share/fonts/ttf-bitstream-vera/fonts.dir /usr/share/fonts/arkpandora/fonts.dir $ cat /usr/share/fonts/100dpi/fonts.dir 28 charB08.pcf.gz -bitstream-charter-bold-r-normal--11-80-100-100-p-69-iso8859-1 charB10.pcf.gz -bitstream-charter-bold-r-normal--14-100-100-100-p-88-iso8859-1 charB12.pcf.gz -bitstream-charter-bold-r-normal--17-120-100-100-p-107-iso8859-1 charB14.pcf.gz -bitstream-charter-bold-r-normal--19-140-100-100-p-119-iso8859-1 charB18.pcf.gz -bitstream-charter-bold-r-normal--25-180-100-100-p-157-iso8859-1 charB24.pcf.gz -bitstream-charter-bold-r-normal--33-240-100-100-p-206-iso8859-1 charBI08.pcf.gz -bitstream-charter-bold-i-normal--11-80-100-100-p-68-iso8859-1 charBI10.pcf.gz -bitstream-charter-bold-i-normal--14-100-100-100-p-86-iso8859-1 charBI12.pcf.gz -bitstream-charter-bold-i-normal--17-120-100-100-p-105-iso8859-1 charBI14.pcf.gz -bitstream-charter-bold-i-normal--19-140-100-100-p-117-iso8859-1 charBI18.pcf.gz -bitstream-charter-bold-i-normal--25-180-100-100-p-154-iso8859-1 charBI24.pcf.gz -bitstream-charter-bold-i-normal--33-240-100-100-p-203-iso8859-1 charI08.pcf.gz -bitstream-charter-medium-i-normal--11-80-100-100-p-60-iso8859-1 charI10.pcf.gz -bitstream-charter-medium-i-normal--14-100-100-100-p-76-iso8859-1 charI12.pcf.gz -bitstream-charter-medium-i-normal--17-120-100-100-p-92-iso8859-1 charI14.pcf.gz -bitstream-charter-medium-i-normal--19-140-100-100-p-103-iso8859-1 charI18.pcf.gz -bitstream-charter-medium-i-normal--25-180-100-100-p-136-iso8859-1 charI24.pcf.gz -bitstream-charter-medium-i-normal--33-240-100-100-p-179-iso8859-1 charR08.pcf.gz -bitstream-charter-medium-r-normal--11-80-100-100-p-61-iso8859-1 charR10.pcf.gz -bitstream-charter-medium-r-normal--14-100-100-100-p-78-iso8859-1 charR12.pcf.gz -bitstream-charter-medium-r-normal--17-120-100-100-p-95-iso8859-1 charR14.pcf.gz -bitstream-charter-medium-r-normal--19-140-100-100-p-106-iso8859-1 charR18.pcf.gz -bitstream-charter-medium-r-normal--25-180-100-100-p-139-iso8859-1 charR24.pcf.gz -bitstream-charter-medium-r-normal--33-240-100-100-p-183-iso8859-1 tech14.pcf.gz -bitstream-terminal-medium-r-normal--18-140-100-100-c-110-dec-dectech techB14.pcf.gz -bitstream-terminal-bold-r-normal--18-140-100-100-c-110-dec-dectech term14.pcf.gz -bitstream-terminal-medium-r-normal--18-140-100-100-c-110-iso8859-1 termB14.pcf.gz -bitstream-terminal-bold-r-normal--18-140-100-100-c-110-iso8859-1 I realize this is info overkill, but I just wanted to get something out asap. I believe I keep things minimal, and rely primarily on bitstream fonts -- with the occassional Terminus and Dejavue (as supposedly Dillo like Dejavue fonts). $ eix -s bitstream -cI [I] media-fonts/font-bitstream-100dpi (1.0.0@06/09/2010): X.Org Bitstream bitmap fonts [I] media-fonts/font-bitstream-type1 (1.0.0@06/09/2010): X.Org Bitstream Type 1 fonts [I] media-fonts/ttf-bitstream-vera (1.10-r3@06/09/2010): Bitstream Vera font family -- Roger http://rogerx.freeshell.org/

June 15, 2010

Unexplained Dillo Segfault

by corvid＠lavabit.com

rogerx wrote: > On Mon, Jun 14, 2010 at 09:31:25PM +0000, corvid wrote: > >rogerx wrote: > >> Every time I visit a web page, I get an unexplained segfault (viewing with > >> strace). > >> > >> This has been occurring for 1-3 months now. > >> > >> I've recently realized a GCC bug with Mozilla based browsers here: > >> http://bugs.gentoo.org/show_bug.cgi?id=270120 > >> > >> > >> I think on one segfault with Dillo, I did get a "bad var font" error, but later > >> lost the url -- so I can only try to recall the exact error. > >> > >> I doubt this is font related as I have several fonts installed. (Following is a > >> quick search of "font" within package manager search function.) > > > >[snip] > > > >Without a gdb backtrace or anything, I can't help but assume that this > >the fltk font problem showing up again... > > Well, by luck, here's a backtrace with some good info. (Most of the other back > traces contained little useful info.) [snip] > bad font: variable Okay, good. Guess I'll have to start digging into the fltk font stuff again at some point. In the meantime, let's try to make it stop breaking for you. fltk's src/x11/Font_xlfd.cxx asks for "fixed" and "variable" under certain conditions. In my case, they seem to be (looking in /usr/lib/X11/fonts/misc/fonts.alias) fixed -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 variable -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-1 And then in my /usr/lib/X11/fonts/misc/fonts.dir, there's 6x13-ISO8859-1.pcf.gz -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 and then /usr/lib/X11/fonts/100dpi/fonts.dir has helvB12-ISO8859-1.pcf.gz -adobe-helvetica-bold-r-normal--17-120-100-100-p-92-iso8859-1 and /usr/lib/X11/fonts/75dpi/fonts.dir has helvB12-ISO8859-1.pcf.gz -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1 Do you have whatever font 'variable' is set to in your fonts.alias?

June 15, 2010

Unexplained Dillo Segfault

by rogerx＠sdf.org

And the offending URL for historical purposes concerning this thread: http://www.nytimes.com/2010/06/15/science/earth/15cleanup.html -- Roger http://rogerx.freeshell.org/

June 15, 2010

Unexplained Dillo Segfault

by rogerx＠sdf.org

Forgot to mention dillo/fltk versions: www-client/dillo (2.2@06/14/2010) x11-libs/fltk (2.0_pre6970(2)@06/14/2010) -- Roger http://rogerx.freeshell.org/

June 15, 2010

Unexplained Dillo Segfault

by rogerx＠sdf.org

On Mon, Jun 14, 2010 at 09:31:25PM +0000, corvid wrote: >rogerx wrote: >> Every time I visit a web page, I get an unexplained segfault (viewing with >> strace). >> >> This has been occurring for 1-3 months now. >> >> I've recently realized a GCC bug with Mozilla based browsers here: >> http://bugs.gentoo.org/show_bug.cgi?id=270120 >> >> >> I think on one segfault with Dillo, I did get a "bad var font" error, but later >> lost the url -- so I can only try to recall the exact error. >> >> I doubt this is font related as I have several fonts installed. (Following is a >> quick search of "font" within package manager search function.) > >[snip] > >Without a gdb backtrace or anything, I can't help but assume that this >the fltk font problem showing up again... Well, by luck, here's a backtrace with some good info. (Most of the other back traces contained little useful info.) $ gdb dillo ... run ... CssParser::parseImport(): @import /css/0.1/screen/common/modules/sharetools.css CssParser::parseImport(): @import /css/0.1/screen/common/modules/readercomments.css CssParser::parseImport(): @import /css/0.1/screen/section/travel/modules/expedia.css CssParser::parseImport(): @import /css/0.1/screen/article/upnext.css bad font: variable Program received signal SIGSEGV, Segmentation fault. 0x4429f928 in strcmp () from /lib/libc.so.6 (gdb) bt #0 0x4429f928 in strcmp () from /lib/libc.so.6 #1 0xb7f60884 in fltk::setfont (font=0xb7fda6e0, psize=9) at x11/Font_xlfd.cxx:539 #2 0xb7f55094 in fltk::measure (str=0x80d845e "x", w=@0xbfffe998, h=@0xbfffe994, flags=0) at drawtext.cxx:659 #3 0x08097fff in FltkFont (this=0x830bd20, attrs=0xbfffeacc) at fltkplatform.cc:70 #4 0x080981a7 in dw::fltk::FltkFont::create (attrs=0xbfffeacc) at fltkplatform.cc:98 #5 0x08099447 in dw::fltk::FltkPlatform::createFont (this=0x81197a8, attrs=0xbfffeacc, tryEverything=false) at fltkplatform.cc:465 #6 0x080b1343 in dw::core::Layout::createFont (this=0x8177ef0, attrs=0xbfffeacc, tryEverything=false) at layout.hh:322 #7 0x080b033a in dw::core::style::Font::create0 (layout=0x8177ef0, attrs=0xbfffeacc, tryEverything=false) at style.cc:297 #8 0x080b035c in dw::core::style::Font::create (layout=0x8177ef0, attrs=0xbfffeacc) at style.cc:302 #9 0x0806bb5d in StyleEngine::apply (this=0x835ff30, attrs=0xbfffeb44, props=0xbfffebe4) at styleengine.cc:334 #10 0x0806c779 in StyleEngine::style0 (this=0x835ff30, nonCssProperties=0xbfffec5c) at styleengine.cc:615 #11 0x0806b3b7 in StyleEngine::setNonCssHints (this=0x835ff30, nonCssHints=0xbfffec5c) at styleengine.cc:135 #12 0x080716cc in Html_tag_open_body (html=0x8248db0, tag=0x83297b9 "<body >\n\r\n\r\n<a name=\"top\"></a>\r\n<div id=\"shell\">\r\n<ul id=\"memberTools\">\n\n<li><a href=\"http://www.nytimes.com/adx/bin/a"..., tagsize=7) at html.cc:1725 #13 0x080758d0 in Html_process_tag (html=0x8248db0, tag=0x83297b9 "<body >\n\r\n\r\n<a name=\"top\"></a>\r\n<div id=\"shell\">\r\n<ul id=\"memberTools\">\n\n<li><a href=\"http://www.nytimes.com/adx/bin/a"..., tagsize=7) at html.cc:3481 #14 0x08076525 in Html_write_raw (html=0x8248db0, buf=0x83286a0 "\n\n\n\n\n\n\n<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"http://www.w3.org/TR/html4/loose.dtd\">\r\n<html>\r\n<head>\r\n<title>Onshore Oil Spill Response Is Described as Chaotic - NYTimes.com</"..., bufsize=66856, Eof=0) at html.cc:3782 #15 0x0806eeca in DilloHtml::write (this=0x8248db0, Buf=0x83286a0 "\n\n\n\n\n\n\n<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"http://www.w3.org/TR/html4/loose.dtd\">\r\n<html>\r\n<head>\r\n<title>Onshore Oil Spill Response Is Described as Chaotic - NYTimes.com</"..., BufSize=66856, Eof=0) at html.cc:554 #16 0x0807602a in Html_callback (Op=0, Client=0x816c020) at html.cc:3673 #17 0x080621b2 in Cache_process_queue (entry=0x826a928) at cache.c:1172 #18 0x080623a7 in Cache_delayed_process_queue_callback () at cache.c:1237 #19 0xb7f8f2a7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:478 #20 0xb7f8f3d4 in fltk::run () at run.cxx:399 #21 0x08050ab3 in main (argc=1, argv=0xbfffef64) at dillo.cc:371 (gdb) -- Roger http://rogerx.freeshell.org/

June 15, 2010

Unexplained Dillo Segfault

by corvid＠lavabit.com

rogerx wrote: > Every time I visit a web page, I get an unexplained segfault (viewing with > strace). > > This has been occurring for 1-3 months now. > > I've recently realized a GCC bug with Mozilla based browsers here: > http://bugs.gentoo.org/show_bug.cgi?id=270120 > > > I think on one segfault with Dillo, I did get a "bad var font" error, but later > lost the url -- so I can only try to recall the exact error. > > I doubt this is font related as I have several fonts installed. (Following is a > quick search of "font" within package manager search function.) [snip] Without a gdb backtrace or anything, I can't help but assume that this the fltk font problem showing up again...

June 14, 2010

Unexplained Dillo Segfault

by rogerx＠sdf.org

Every time I visit a web page, I get an unexplained segfault (viewing with strace). This has been occurring for 1-3 months now. I've recently realized a GCC bug with Mozilla based browsers here: http://bugs.gentoo.org/show_bug.cgi?id=270120 I think on one segfault with Dillo, I did get a "bad var font" error, but later lost the url -- so I can only try to recall the exact error. I doubt this is font related as I have several fonts installed. (Following is a quick search of "font" within package manager search function.) media-fonts/font-bitstream-100dpi (1.0.0@06/09/2010): X.Org Bitstream bitmap fonts media-fonts/font-bitstream-type1 (1.0.0@06/09/2010): X.Org Bitstream Type 1 fonts media-fonts/terminus-font (4.30@06/09/2010): A clean fixed font for the console and X11 media-fonts/urw-fonts (2.4.9@06/09/2010): free good quality fonts gpl'd by URW++ media-libs/fontconfig (2.8.0(1.0)@06/09/2010): A library for configuring and customizing font access virtual/ttf-fonts (1@06/08/2010): Virtual for Serif/Sans/Monospace font packages x11-apps/mkfontdir (1.0.5@06/09/2010): create an index of X font files in a directory x11-apps/mkfontscale (1.0.7@06/09/2010): create an index of scalable font files for X x11-libs/libXfont (1.4.1@06/09/2010): X.Org Xfont library x11-libs/libXfontcache (1.0.5@06/09/2010): X.Org Xfontcache library x11-libs/libfontenc (1.0.5@06/08/2010): X.Org fontenc library x11-proto/fontcacheproto (0.1.3@06/08/2010): X.Org Fontcache protocol headers x11-proto/fontsproto (2.1.0@06/08/2010): X.Org Fonts protocol headers x11-proto/xf86bigfontproto (1.2.0@06/08/2010): X.Org XF86BigFont protocol headers -- Roger http://rogerx.freeshell.org/

June 14, 2010

scroll bar in textarea

by furaisanjin＠gmail.com

2010/6/13 corvid <corvid(a)lavabit.com>: > I disabled inputs outside of forms after Rogut#s reported a segfault > caused by using a <select> field when a repush comes along > ( http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-March/007408.html ) OK, I understand. Regards, furaisanjin

June 13, 2010

scroll bar in textarea

by corvid＠lavabit.com

furaisanjin wrote: > Are you able to control vertical and horizontal scroll bars in the > below example? > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" > "http://www.w3.org/TR/html4/strict.dtd"> > <html> > <head> > </head> > <body> > > <textarea cols=10 rows=10> > Test message 1 - message 1. > > Test message 2 - message 2. > > Test message 3 - message 3. > > Test message 4 - message 4. > > Test message 5 - message 5. > > Test message 6 - message 6. > > Test message 7 - message 7. > > </textarea> > </body> > </html> > > I can't control them at all on my FreeBSD 8.0R. I disabled inputs outside of forms after Rogut#s reported a segfault caused by using a <select> field when a repush comes along ( http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-March/007408.html )

June 12, 2010

scroll bar in textarea

by furaisanjin＠gmail.com

Hi all. Are you able to control vertical and horizontal scroll bars in the below example? <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> </head> <body> <textarea cols=10 rows=10> Test message 1 - message 1. Test message 2 - message 2. Test message 3 - message 3. Test message 4 - message 4. Test message 5 - message 5. Test message 6 - message 6. Test message 7 - message 7. </textarea> </body> </html> I can't control them at all on my FreeBSD 8.0R. Regards, furaisanjin

June 12, 2010

Re: [dillo 2.2] CSS bug?

by jcid＠dillo.org

On Tue, May 11, 2010 at 01:36:51PM +0200, Michael Baeuerle wrote: > > Hi, > I have added a piece of demonstration code in the attached tarball. > Viewing the index.html file with dillo 2.2 shows the problem: If one of > the boxes contain code with "h2" or "p" tags, the margins associated > with the content seems to affect the layout outside the box (The margins > between the "top" and "content" boxes are defined as zero, so there > should be no space between them). IIRC dillo 2.1.1 have behaved > different. > > I have added two screenshots how dillo 2.2 and Webkit 1.1.8 (Midori) > render the test code on my machine. If I understand the CSS box model > [1] correctly, the content should never affect the area outside the > border and what dillo does is wrong. > > > Regards, > Michael Baeuerle > > [1] http://www.w3schools.com/css/css_boxmodel.asp Example: http://www.dillo.org/test/css-top-margin-bug.html Tarball: http://www.dillo.org/test/css-top-margin-bug.tar -- Cheers Jorge.-

May 22, 2010

Re: dillo question

by corvid＠lavabit.com

Johannes wrote: > and recompile fltk2 + dillo and run your test again? If we're already going for a recompilation, configuring fltk with ./configure --enable-debug and dillo with CFLAGS=-g CXXFLAGS=-g ./configure certainly would help.

May 15, 2010

Re: dillo question

by Johannes.Hofmann＠gmx.de

On Fri, May 14, 2010 at 05:09:56PM -0400, Jorge Arellano Cid wrote: > On Fri, May 14, 2010 at 04:44:30PM -0400, Matthew Craig wrote: > > Thanks for the continued diagnostic suggestions. I have joined the > > dillo-dev mailing list to make it easier for everyone else. I > > discovered interesting data-point, by chance. Normally, I run dillo > > with the command parameter "-g 999x666" to fit my screen more > > appropriately. > > > > ---Type <return> to continue, or q <return> to quit--- > > Core was generated by `dillo -g 999x666 > > http://uaddit.com/discussions/showthread.php?t=5931'. > > Program terminated with signal 6, Aborted. > > [New process 5489] > > #0 0x2af949f8 in raise () from /lib/libc.so.6 > > (gdb) bt > > #0 0x2af949f8 in raise () from /lib/libc.so.6 > > #1 0x2af9665c in abort () from /lib/libc.so.6 > > #2 0x0051facc in __gnu_cxx::__verbose_terminate_handler () > > #3 0x0051d7c4 in __cxxabiv1::__terminate () > > #4 0x0051d828 in std::terminate () > > #5 0x0051d9f8 in __cxa_throw () > > #6 0x0051de84 in operator new () > > #7 0x0051def8 in operator new[] () > > #8 0x004d14a0 in fltk::Image::make_current () > > #9 0x00499eac in ?? () > > This is interesting: it crashes within an FLTK2 function. > > I'm using fltk-2.0.x-r7513 and there we have: > > void Image::make_current() { > // TODO - make the cr point at the image_surface! > } > > No new() operator, no nothing! I think you need to check the Image::make_current() implementation in src/x11/Images.cxx. There is a buffer is allocated depending on the window size - which would explain, why the -g 999x666 is needed to trigger the bug. And there is this buffer size computation at line 1035, that I don't fully understand: n = (ld*h+3)&-4; maybe that doesn't work as expected on MIPS? Matthew, could you add a fprintf like fprintf(stderr, "====> n=%d\n", n); right after line 1035 in src/x11/Image.cxx of your fltk2 copy and recompile fltk2 + dillo and run your test again?

May 14, 2010

Re: dillo question

by jcid＠dillo.org

On Fri, May 14, 2010 at 04:44:30PM -0400, Matthew Craig wrote: > Thanks for the continued diagnostic suggestions. I have joined the > dillo-dev mailing list to make it easier for everyone else. I > discovered interesting data-point, by chance. Normally, I run dillo > with the command parameter "-g 999x666" to fit my screen more > appropriately. > ---Type <return> to continue, or q <return> to quit--- > Core was generated by `dillo -g 999x666 > http://uaddit.com/discussions/showthread.php?t=5931'. > Program terminated with signal 6, Aborted. > [New process 5489] > #0 0x2af949f8 in raise () from /lib/libc.so.6 > (gdb) bt > #0 0x2af949f8 in raise () from /lib/libc.so.6 > #1 0x2af9665c in abort () from /lib/libc.so.6 > #2 0x0051facc in __gnu_cxx::__verbose_terminate_handler () > #3 0x0051d7c4 in __cxxabiv1::__terminate () > #4 0x0051d828 in std::terminate () > #5 0x0051d9f8 in __cxa_throw () > #6 0x0051de84 in operator new () > #7 0x0051def8 in operator new[] () > #8 0x004d14a0 in fltk::Image::make_current () > #9 0x00499eac in ?? () This is interesting: it crashes within an FLTK2 function. I'm using fltk-2.0.x-r7513 and there we have: void Image::make_current() { // TODO - make the cr point at the image_surface! } No new() operator, no nothing! What fltk2 version are you using? -- Cheers Jorge.-

May 14, 2010

Re: dillo question

by matthew.t.craig＠gmail.com

Thanks for the continued diagnostic suggestions. I have joined the dillo-dev mailing list to make it easier for everyone else. I discovered interesting data-point, by chance. Normally, I run dillo with the command parameter "-g 999x666" to fit my screen more appropriately. The output, with 'ulimit -c unlimited' is below. (... continued) mtc@freedomincluded:/$ dillo -g 999x666 http://uaddit.com/discussions/showthread.php?t=5931 paths: Cannot open file '/home/mtc/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Disabling cookies. Nav_open_url: new url='http://uaddit.com/discussions/showthread.php?t=5931' Dns_server [0]: uaddit.com is 72.44.80.46 Connecting to 72.44.80.46 CssParser::parseImport(): @import clientscript/vbulletin_css/style-01a90dc0-00011.css terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted (core dumped) (... continued) Now, watch the output as I run in the same environment without the "-g" parameter. No crash! mtc@freedomincluded:/$ dillo http://uaddit.com/discussions/showthread.php?t=5931 paths: Cannot open file '/home/mtc/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Disabling cookies. Nav_open_url: new url='http://uaddit.com/discussions/showthread.php?t=5931' Dns_server [0]: uaddit.com is 72.44.80.46 Connecting to 72.44.80.46 CssParser::parseImport(): @import clientscript/vbulletin_css/style-01a90dc0-00011.css a_UIcmd_close_bw Dillo: normal exit! I have also run the core dump (from above) through gdb as you specified in your email. The output follows: mtc@freedomincluded:~$ gdb /usr/local/bin/dillo /tmp/core GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "mipsel-linux-gnu"... (no debugging symbols found) Reading symbols from /usr/lib/libjpeg.so.62...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libpng12.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpng12.so.0 Reading symbols from /usr/lib/libz.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libX11.so.6 Reading symbols from /usr/lib/libXi.so.6... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libXi.so.6 Reading symbols from /usr/lib/libXinerama.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXinerama.so.1 Reading symbols from /usr/lib/libXcursor.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libXcursor.so.1 Reading symbols from /usr/lib/libXft.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXft.so.2 Reading symbols from /lib/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /usr/lib/libstdc++.so.6... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libgcc_s.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/ld.so.1 Reading symbols from /usr/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXrender.so.1 Reading symbols from /usr/lib/libfontconfig.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libfontconfig.so.1 Reading symbols from /usr/lib/libxcb-xlib.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb-xlib.so.0 Reading symbols from /usr/lib/libxcb.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb.so.1 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libXfixes.so.3... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libXfixes.so.3 Reading symbols from /usr/lib/libfreetype.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading symbols from /usr/lib/libXau.so.6... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libXau.so.6 Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libXdmcp.so.6... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libXdmcp.so.6 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_mdns4_minimal.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libnss_mdns4_minimal.so.2 Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/gconv/ISO8859-1.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so ---Type <return> to continue, or q <return> to quit--- Core was generated by `dillo -g 999x666 http://uaddit.com/discussions/showthread.php?t=5931'. Program terminated with signal 6, Aborted. [New process 5489] #0 0x2af949f8 in raise () from /lib/libc.so.6 (gdb) bt #0 0x2af949f8 in raise () from /lib/libc.so.6 #1 0x2af9665c in abort () from /lib/libc.so.6 #2 0x0051facc in __gnu_cxx::__verbose_terminate_handler () #3 0x0051d7c4 in __cxxabiv1::__terminate () #4 0x0051d828 in std::terminate () #5 0x0051d9f8 in __cxa_throw () #6 0x0051de84 in operator new () #7 0x0051def8 in operator new[] () #8 0x004d14a0 in fltk::Image::make_current () #9 0x00499eac in ?? () warning: GDB can't find the start of the function at 0x499eab. GDB is unable to find the start of the function at 0x499eab and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0x499eab for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. Backtrace stopped: previous frame inner to this frame (corrupt stack?)

May 14, 2010

Re: dillo question

by Johannes.Hofmann＠gmx.de

On Fri, May 14, 2010 at 10:22:53AM -0400, Matthew Craig wrote: > process limits set in your environmen (ulimit -a) > > mtc@freedomincluded:~$ ulimit -a > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 4019 > max locked memory (kbytes, -l) 64 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 4019 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited Ah, core files are disabled on your system. You need to call ulimit -c unlimited in the shell from which you start dillo to actually get a core file. After dillo aborts, the core file should show up in /tmp.

May 14, 2010

Re: dillo question

by Johannes.Hofmann＠gmx.de

On Fri, May 14, 2010 at 10:22:53AM -0400, Matthew Craig wrote: > process limits set in your environmen (ulimit -a) > > mtc@freedomincluded:~$ ulimit -a > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 4019 > max locked memory (kbytes, -l) 64 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 4019 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited Ok, so that's not it... Do you get a core file when it aborts? If so please run gdb on it: gdb <path to dillo binary> <path to core file> and type "bt" at the gdb prompt. The output might give us a hint on what's failing.

May 14, 2010

Re: dillo question

by jcid＠dillo.org

On Fri, May 14, 2010 at 09:40:09AM -0400, Matthew Craig wrote: > Here is the output with all CSS options turned off: > > Nav_open_url: new url='http://uaddit.com/discussions/showthread.php?t=5931' > Dns_server [0]: uaddit.com is 72.44.80.46 > Connecting to 72.44.80.46 > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Aborted OK, let's test without CSS as it is not the problem. From previous output it looks like the problem is related to an event and not the suspected function. I'd say: gdb ./dillo r http://uaddit.com/discussions/showthread.php?t=5931 at some point it'll crash, then: bt (and send us the backtrace). There's a lot more you can do with gdb, this is just to start. PS: Forget my previous email, I pressed "send" instead of "postpone" and that's why it got cut in the middle of a sentence :-) -- Cheers Jorge.-

May 14, 2010