- Dillo-dev - lists.mailman3.com

Executing commands via URL

by weigelt＠metux.de

Hi folks, I'd like to use Dillo for an help system and control center on an end-user desktop appliance. Therefore I need it to execute certain commands. But Dillo itself should not fork/exec itself, instead send the commands to some special daemon via an 9P channel. An simple approach could be coding an dpi which just parses the requested URL and sends the actual command to the exec server through 9P. But I have to make absolutely sure that commands can only be sent when coming from certain pages. How can I achieve this ? thx -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 04:34:04PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > > > I've seen occasional segfaults in recent weeks, and > > > > > twice now I've been able to catch them when I remembered > > > > > to have gdb going (and, well, zero times when I remembered > > > > > to have ulimit -c unlimited) > > > > > > > > I had some of these segfaults too. > > > > > > > > > These two have been nearly identical. Here's the one I just got: > > > > > > > > > > #0 0x00000048 in ?? () > > > > > #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, > > > > > attrs=0x81dfc08) at layout.hh:253 > > > > > #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, > > > > > layout=0x815ca58) at style.cc:287 > > > > > #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, > > > > > layout=0x815ca58) at style.hh:587 > > > > > #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 > > > > > #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) > > > > > at style.hh:505 > > > > > #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 > > > > > #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, > > > > > widget=0x827b3b0) at layout.cc:175 > > > > > #8 0x0805aea8 in a_Web_dispatch_by_type ( > > > > > Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, > > > > > Data=0x821d324) at web.cc:94 > > > [snip] > > > > > My guess at the problem: > > > > > StyleTable will give you back whatever Style matches your attrs, > > > > > but maybe that Style was created with a different layout. > > > > > > > > > > > > > I will have a look at that. Maybe the StyleTable should be > > > > associated with a layout too. > > > > > > It looks like style uses layout to get to platform. I wonder whether > > > it would go against any dw rules to let style have platform. > > > > > > > My problem is that I don't understand why fontsTable and > > colorsTable need to be platform specific in the first place. > > As long as their members match they should be sharable - even > > if they are used for different platforms. > > > > I would just make them static members of Font and Color > > respectively. That way we would no longer need the layout parameter > > in the *::create methods. > > > > What am I missing here? > > I may be wrong here, but I think the idea is that the colors or fonts > in the tables are currently FltkColor/FltkFont, but they could in principle > be mixed together with ones from another toolkit. Yes, I also read the comment in platform.hh about Style Resources. But still, if every implementation of Font or Color would handle its caching on its own with a static hash table, it should still work. If there should be a GtkFont class some day, it would have its own static hash table. I would rather see the need for a Font factory in platform that creates the right sort of Font for that platform. > > Hmm. I wonder whether it would break anything to change > a_UIcmd_browser_window_new() to have a single static FltkPlatform... Yeah, I thought about that too. I think apart from the current delete platform; in the Layout destructor that should work. And we could delete platfrom at the level where it was created. But all the platform stuff is difficult to understand as we currently only have one.

June 7, 2008

recent style/layout segfaults

by corvid＠lavabit.com

Johannes wrote: > On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > > Johannes wrote: > > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > > I've seen occasional segfaults in recent weeks, and > > > > twice now I've been able to catch them when I remembered > > > > to have gdb going (and, well, zero times when I remembered > > > > to have ulimit -c unlimited) > > > > > > I had some of these segfaults too. > > > > > > > These two have been nearly identical. Here's the one I just got: > > > > > > > > #0 0x00000048 in ?? () > > > > #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, > > > > attrs=0x81dfc08) at layout.hh:253 > > > > #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, > > > > layout=0x815ca58) at style.cc:287 > > > > #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, > > > > layout=0x815ca58) at style.hh:587 > > > > #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 > > > > #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) > > > > at style.hh:505 > > > > #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 > > > > #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, > > > > widget=0x827b3b0) at layout.cc:175 > > > > #8 0x0805aea8 in a_Web_dispatch_by_type ( > > > > Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, > > > > Data=0x821d324) at web.cc:94 > > [snip] > > > > My guess at the problem: > > > > StyleTable will give you back whatever Style matches your attrs, > > > > but maybe that Style was created with a different layout. > > > > > > > > > > I will have a look at that. Maybe the StyleTable should be > > > associated with a layout too. > > > > It looks like style uses layout to get to platform. I wonder whether > > it would go against any dw rules to let style have platform. > > > > My problem is that I don't understand why fontsTable and > colorsTable need to be platform specific in the first place. > As long as their members match they should be sharable - even > if they are used for different platforms. > > I would just make them static members of Font and Color > respectively. That way we would no longer need the layout parameter > in the *::create methods. > > What am I missing here? I may be wrong here, but I think the idea is that the colors or fonts in the tables are currently FltkColor/FltkFont, but they could in principle be mixed together with ones from another toolkit. Hmm. I wonder whether it would break anything to change a_UIcmd_browser_window_new() to have a single static FltkPlatform...

June 7, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > I've seen occasional segfaults in recent weeks, and > > > twice now I've been able to catch them when I remembered > > > to have gdb going (and, well, zero times when I remembered > > > to have ulimit -c unlimited) > > > > I had some of these segfaults too. > > > > > These two have been nearly identical. Here's the one I just got: > > > > > > #0 0x00000048 in ?? () > > > #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, > > > attrs=0x81dfc08) at layout.hh:253 > > > #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, > > > layout=0x815ca58) at style.cc:287 > > > #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, > > > layout=0x815ca58) at style.hh:587 > > > #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 > > > #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) > > > at style.hh:505 > > > #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 > > > #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, > > > widget=0x827b3b0) at layout.cc:175 > > > #8 0x0805aea8 in a_Web_dispatch_by_type ( > > > Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, > > > Data=0x821d324) at web.cc:94 > [snip] > > > My guess at the problem: > > > StyleTable will give you back whatever Style matches your attrs, > > > but maybe that Style was created with a different layout. > > > > > > > I will have a look at that. Maybe the StyleTable should be > > associated with a layout too. > > It looks like style uses layout to get to platform. I wonder whether > it would go against any dw rules to let style have platform. > My problem is that I don't understand why fontsTable and colorsTable need to be platform specific in the first place. As long as their members match they should be sharable - even if they are used for different platforms. I would just make them static members of Font and Color respectively. That way we would no longer need the layout parameter in the *::create methods. What am I missing here? Cheers, Johannes > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 7, 2008

another segfault

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > Johannes wrote: > > now I've got some more info on that problem. The buffer on which > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > a_Cache_set_content_type(). I don't understand the details though. > > Do you have an idea? > > Ah! Does this help? > Yes, it does. Excellent! Johannes

June 7, 2008

another segfault

by corvid＠lavabit.com

Johannes wrote: > now I've got some more info on that problem. The buffer on which > Html_write_raw is operating (0x285c8000 in this case) is free'd by > a_Cache_set_content_type(). I don't understand the details though. > Do you have an idea? Ah! Does this help?

June 7, 2008

another segfault

by Johannes.Hofmann＠gmx.de

Hi, now I've got some more info on that problem. The buffer on which Html_write_raw is operating (0x285c8000 in this case) is free'd by a_Cache_set_content_type(). I don't understand the details though. Do you have an idea? (gdb) bt #0 dFree (mem=0x285c8000) at dlib.c:59 #1 0x08071ae7 in dStr_free (ds=0x285c0ed0, all=677150720) at dlib.c:291 #2 0x08058ef1 in a_Cache_set_content_type (url=0x28539500, ctype=0x285d2000 "text/html; charset=us-asci i", force=0 '\0') at cache.c:499 #3 0x08061a82 in Html_tag_open_meta (html=0x28689e00, tag=0x285c80a5 "<META http-equiv=\"Content-Type\" content=\"text/html; charset=us-ascii\">\n </HEAD >\n <BODY BGCOLOR=\"#ffffff\">\n <h1>The Mercurial Archives </h1>\n <p>\n You can get <a h ref=\"http://selenic.com"..., tagsize=70) at html.cc:3995 #4 0x080616c4 in Html_write_raw (html=0x28689e00, buf=0x285c8000 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2//EN\">\n<HTML>\n <HEAD>\n <title>T he Mercurial Archives</title>\n <META NAME=\"robots\" CONTENT=\"noindex,follow\">\n <META http-e quiv=\"Content-Type\" con"..., bufsize=1119, Eof=0) at html.cc:5653 #5 0x08061af1 in DilloHtml::write (this=0x28689e00, Buf=0x285c8000 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2//EN\">\n<HTML>\n <HEAD>\n <title>T he Mercurial Archives</title>\n <META NAME=\"robots\" CONTENT=\"noindex,follow\">\n <META http-e quiv=\"Content-Type\" con"..., BufSize=675443204, Eof=0) at html.cc:967 #6 0x080621ba in Html_callback (Op=0, Client=0x28549bc0) at html.cc:5883 #7 0x08058433 in Cache_process_queue (entry=0x285d4200) at cache.c:1075 #8 0x08058d98 in a_Cache_process_dbuf (Op=0, buf=0x285a1000 "HTTP/1.1 200 OK\r\nDate: Sat, 07 Jun 2008 09:35:46 GMT\r\nServer: Apache/1.3.34 (Deb ian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c\r\nLast-Modified: Sat, 07 Jun 2008 08:24:59 GMT\r\n ETag: \"271005-41b5-4"..., buf_size=1440, Url=0x28539800) at cache.c:871 #9 0x0805650c in a_Chain_fcb (Op=675443204, Info=0x0, Data1=0x285c0340, Data2=0x80eb382) at chain.c:111 #10 0x08074440 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x285490c0, Data1=0x2848d5f0, Data2=0x0) at dpi .c:223 #11 0x0805650c in a_Chain_fcb (Op=675443204, Info=0x0, Data1=0x2848d5f0, Data2=0x0) at chain.c:111 #12 0x08074d61 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x28549ac0, Data1=0x285497c0, Data2=0x0) at IO.c :418 #13 0x08074eee in IO_callback (fd=<value optimized out>, io=0x285497c0) at IO.c:205 #14 0x08074fc7 in IO_fd_read_cb (fd=7, data=0xc) at IO.c:291 #15 0x080c2869 in fltk::wait () #16 0x080c2a19 in fltk::run () #17 0x0804e63d in main (argc=0, argv=0x0) at dillo.cc:125 (gdb) Cheers, Johannes

June 7, 2008

Splitting html.cc: common functions, part 1

by onepoint＠starurchin.org

On Fri, Jun 06, 2008 at 06:53:58PM +0100, Jeremy Henty wrote: > On Fri, Jun 06, 2008 at 04:29:02PM +0000, corvid wrote: > > compiler errors: I think it's that Jeremy is using gcc3 and not > > seeing those errors. > > I'll fix up the other branches and send a mega-patch privately. Done. Thanks to corvid for reminding me that we had seen this before. Are there any gcc flags I could set to stop stuff like this getting through? Regards, Jeremy Henty

June 6, 2008

Splitting html.cc: common functions, part 1

by jcid＠dillo.org

On Fri, Jun 06, 2008 at 04:29:02PM +0000, corvid wrote: > compiler errors: I think it's that Jeremy is using gcc3 and not > seeing those errors. Here I have: gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) -- Cheers Jorge.-

June 6, 2008

Splitting html.cc: common functions, part 1

by onepoint＠starurchin.org

On Fri, Jun 06, 2008 at 04:29:02PM +0000, corvid wrote: > compiler errors: I think it's that Jeremy is using gcc3 and not > seeing those errors. Yes, it looks very much like something we have seen before where gcc4 wants the scope of variables initialised in switch statements to be restricted to one branch of the switch. In reset() that's already been done to the case DILLO_HTML_INPUT_FILE: branch lower down. I'll fix up the other branches and send a mega-patch privately. Regards, Jeremy Henty

June 6, 2008