On Feb 13, 2008 6:35 AM, Paul Wise <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-02-12 at 23:29 -0600, Luis Rodrigo Gallardo Cruz wrote:
> > On Wed, Feb 13, 2008 at 01:33:18PM +0900, Paul Wise wrote:
> > > [ Tracing the problem to the stored value of last-vpane-pos ]
> > > I did a bisect on this value using the following command and found that
> > > 635 was the magic value that caused crashes. 634 did not cause crashes.
> > >
> > > gconftool --type int --set /apps/liferea/last-vpane-pos 635
> > >
> > > I removed all the gconf settings and ~/.liferea-1.4 then set
> > > last-vpane-pos to 635 and got the crash. I set it to 634 and did not get
> > > the crash.
> > >
> > > Hopefully I've provided enough information for this bug to be tracked
> > > down and fixed.
> >
> > Well, if you haven't that just means this is a *weird* bug.
> >
> > What size is the liferea main window when it starts up without
> > crashing?
>
> Maximised. On my 1280x800 laptop LCD, I get this from xwininfo:
>
> xwininfo: Window id: 0x4600027 "Liferea"
>
> Absolute upper-left X: 0
> Absolute upper-left Y: 41
> Relative upper-left X: 0
> Relative upper-left Y: 18
> Width: 1280
> Height: 738
> Depth: 24
> Visual Class: TrueColor
> Border width: 0
> Class: InputOutput
> Colormap: 0x20 (installed)
> Bit Gravity State: NorthWestGravity
> Window Gravity State: NorthWestGravity
> Backing Store State: NotUseful
> Save Under State: no
> Map State: IsViewable
> Override Redirect State: no
> Corners: +0+41 -0+41 -0-21 +0-21
> -geometry 1280x738+0-21
>
> > Looking at the code, last-vpane-pos is the size of the feedlist
> > area. It would seem that making it too large gives too litle space to
> > the item views. What I'd like to do is determine what's the minimum
> > size those areas can have and not crash, and then change the code that
> > sets the size from the stored pref to respect that minimum.
> >
> > I'll try to produce a patch to do that and a test package including it
> > sometime this week.
>
> Cool, thanks.
>
> > Thank you very much for this investigation.
>
> No problems.
Just some additional information: I can reproduce it by using the gconf-tool
command Paul suggested. But it doesn't crash immediately. I have to minimize the
overall window size to totally hide the HTML widget. When I then exit the
program and restart it again the following crash happens:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2b89c9d73a70 (LWP 11752)]
mozsupport_set_zoom (embed=0x10aef30, aZoom=1) at mozsupport.cpp:120
120 mWebBrowser->GetContentDOMWindow(getter_AddRefs(mDOMWindow));
Current language: auto; currently c++
(gdb) bt
#0 mozsupport_set_zoom (embed=0x10aef30, aZoom=1) at mozsupport.cpp:120
#1 0x00000000004419b2 in ui_mainwindow_init (mainwindowState=0)
at ui_mainwindow.c:679
#2 0x00000000004316ef in main (argc=1, argv=0x7fffe9b27048) at main.c:290
(gdb) q
So it seems that when the Gecko widget is not visible (realized)
any operation on it causes a crash. I've tried to implement some
simple fixes but was not successful so far.
Regards,
Lars
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
