Dillo-dev

Download

By thread

dillo-dev@mailman3.com

1 participants
11683 messages

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

Splitting html.cc: common functions, part 1

by corvid＠lavabit.com

compiler errors: I think it's that Jeremy is using gcc3 and not seeing those errors.

June 6, 2008

Splitting html.cc: common functions, part 1

by jcid＠dillo.org

Hi Jeremy, On Thu, Jun 05, 2008 at 06:25:33PM +0100, Jeremy Henty wrote: > > This patch moves some function declarations from html.cc to > html_common.hh . It only does *some* of the renaming because the full > patch breaks the list's moderation limit. I'll follow up to this > message with the rest of the renaming. You may want to batch this > patch and the followup together as a single commit. > > Please comment! With regard to big patches and splitting, please don't burden yourself with splitting. This is just cleanup so please send me one big patch to my email address not dillo-dev. After applying thwe full patchset, I got compiler errors. :( <quote> g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I../../dw-testbed -I/usr/include/libpng12 -I/usr/local/include -I/usr/include/freetype2 -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -MT form.o -MD -MP -MF .deps/form.Tpo -c -o form.o form.cc form.cc: In member function 'void DilloHtmlInput::reset()': form.cc:1413: error: jump to case label form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1414: error: jump to case label form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1419: error: jump to case label form.cc:1415: error: crosses initialization of 'dw::core::ui::ToggleButtonResource* tb_r' form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1434: error: jump to case label form.cc:1415: error: crosses initialization of 'dw::core::ui::ToggleButtonResource* tb_r' form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1449: error: jump to case label [...] </quote> To solve this problem, please send me one big patch with all the changes. I'm not committing anything yet. -- Cheers Jorge.-

June 6, 2008

Splitting html.cc: the rest of the form code

by onepoint＠starurchin.org

This is it!. These three patches complete the migration of all the form code to form.cc . They move respectively the receiver class, the input class and the class declarations (which were temporarily put in form.hh ). Now all the details of form handling are in form.cc and form.hh exports an opaque API to the rest of the Html module. Regards, Jeremy Henty

June 6, 2008

Splitting html.cc: the form class, part II

by onepoint＠starurchin.org

And here we move the rest of the DilloHtmlForm implementation, in two patches. The first patch moves the methods that create data for submitting a form. This is large because it includes a number of static functions that have to be moved together. The second patch moves the last method. Regards, Jeremy Henty

June 6, 2008

Splitting html.cc: the form class, part I

by onepoint＠starurchin.org

The next task is to move the implementation of DilloHtmlForm into form.cc . This is a lot of code, so I'm splitting it into several parts. This part moves the constructor, destructor and most of the methods. Regards, Jeremy Henty

June 6, 2008

recent style/layout segfaults

by corvid＠lavabit.com

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.

June 6, 2008

Jump to page: