recent style/layout segfaults
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) 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 .. The layout in frame 3 was: p *layout $7 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x814c0f0, views = 0x815cb78, topLevel = 0x0, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 0, canvasAscent = 0, canvasDescent = 0, usesViewport = true, scrollX = 0, scrollY = 0, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x815cba0, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x815ca58, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 1, toChar = 1, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 3, link = 0x0, linkChar = 3, linkNumber = 13}, findtextState = {key = 0x0, caseSens = 32, nexttab = 0x0, widget = 0x0, iterator = 0x0, hlIterator = 0x0}} and the layout in frame 7 was: p *this $8 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x8281808, views = 0x8246f38, topLevel = 0x8249308, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 665, canvasAscent = 5, canvasDescent = 11564, usesViewport = true, scrollX = 0, scrollY = 8854, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x81e4078, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x822f868, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 3, toChar = 3, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 136509888, link = 0x0, linkChar = 136509920, linkNumber = 0}, findtextState = { key = 0x0, caseSens = 16, nexttab = 0x0, widget = 0x8249308, iterator = 0x0, hlIterator = 0x0}} Both look fairly layoutish. I only had one bw open at the time of crash. 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.
Hi, 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 ..
The layout in frame 3 was:
p *layout $7 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x814c0f0, views = 0x815cb78, topLevel = 0x0, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 0, canvasAscent = 0, canvasDescent = 0, usesViewport = true, scrollX = 0, scrollY = 0, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x815cba0, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x815ca58, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 1, toChar = 1, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 3, link = 0x0, linkChar = 3, linkNumber = 13}, findtextState = {key = 0x0, caseSens = 32, nexttab = 0x0, widget = 0x0, iterator = 0x0, hlIterator = 0x0}}
and the layout in frame 7 was:
p *this $8 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x8281808, views = 0x8246f38, topLevel = 0x8249308, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 665, canvasAscent = 5, canvasDescent = 11564, usesViewport = true, scrollX = 0, scrollY = 8854, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x81e4078, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x822f868, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 3, toChar = 3, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 136509888, link = 0x0, linkChar = 136509920, linkNumber = 0}, findtextState = { key = 0x0, caseSens = 16, nexttab = 0x0, widget = 0x8249308, iterator = 0x0, hlIterator = 0x0}}
Both look fairly layoutish. I only had one bw open at the time of crash.
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. Cheers, Johannes
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.
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@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
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...
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.
On Sat, Jun 07, 2008 at 06:04:07PM +0200, Johannes Hofmann 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.
To make clear what I mean, here comes the patch: http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dw2 http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dillo2 (they are too large for the list). I'm not sure why Sebastian avoided that possiblity. Maybe the virtual destructors which are needed in this implementation? Comments welcome! I feel a bit uncomfortable proposing a pretty drastic change like this. Cheers, Johannes
Johannes wrote:
Comments welcome! I feel a bit uncomfortable proposing a pretty drastic change like this.
Although obviously I don't know the code well, it seems like an improvement. PS Jeremy's new html.cc is in CVS now, so the dillo2 part of the patch no longer applies very cleanly.
On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote:
Johannes wrote:
Comments welcome! I feel a bit uncomfortable proposing a pretty drastic change like this.
Although obviously I don't know the code well, it seems like an improvement.
PS Jeremy's new html.cc is in CVS now, so the dillo2 part of the patch no longer applies very cleanly.
Ah ok. I updated the dillo2 part: http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dillo2
On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote:
Johannes wrote:
Comments welcome! I feel a bit uncomfortable proposing a pretty drastic change like this.
Although obviously I don't know the code well, it seems like an improvement.
After thinking some more about it, I believe this is the right way to go. My initial patch had some issues though: It was complete nonsense of course to make the destructor of the derived class (FltkFont and FltkColor) virtual. It only worked because Font and Color are derived from lout::Object which already has a virtual destructor. So in fact the change does not add any additional virtual methods. I also decided to keep the interface to dillo2 as it is (the now unused layout parameter in Style::create()). So attached is my official proposal to fix the style related segfaults that where introduced by my style caching patch. Cheers, Johannes
On Tue, Jun 10, 2008 at 07:21:35PM +0200, Johannes Hofmann wrote:
On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote:
Johannes wrote:
Comments welcome! I feel a bit uncomfortable proposing a pretty drastic change like this.
Although obviously I don't know the code well, it seems like an improvement.
After thinking some more about it, I believe this is the right way to go. My initial patch had some issues though: It was complete nonsense of course to make the destructor of the derived class (FltkFont and FltkColor) virtual. It only worked because Font and Color are derived from lout::Object which already has a virtual destructor. So in fact the change does not add any additional virtual methods. I also decided to keep the interface to dillo2 as it is (the now unused layout parameter in Style::create()).
So attached is my official proposal to fix the style related segfaults that where introduced by my style caching patch.
Trying to be practical I'd say: if we don't have a comment in a week let's commit. -- Cheers Jorge.-
On Tue, Jun 10, 2008 at 07:21:35PM +0200, Johannes Hofmann wrote:
On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote:
Johannes wrote:
Comments welcome! I feel a bit uncomfortable proposing a pretty drastic change like this.
Although obviously I don't know the code well, it seems like an improvement.
After thinking some more about it, I believe this is the right way to go. My initial patch had some issues though: It was complete nonsense of course to make the destructor of the derived class (FltkFont and FltkColor) virtual. It only worked because Font and Color are derived from lout::Object which already has a virtual destructor. So in fact the change does not add any additional virtual methods. I also decided to keep the interface to dillo2 as it is (the now unused layout parameter in Style::create()).
So attached is my official proposal to fix the style related segfaults that where introduced by my style caching patch.
Committed! -- Cheers Jorge.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de