GNU bug report logs - #24041
25.1.50; xwidget + -nw mode gives segfault

Previous Next

Full log

View this message in rfc822 format

From: joakim <at> verona.se
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24041 <at> debbugs.gnu.org, shanemhansen <at> gmail.com, Robert Cochran <robert-emacs <at> cochranmail.com>
Subject: bug#24041: 25.1.50; xwidget + -nw mode gives segfault
Date: Mon, 22 Aug 2016 21:52:58 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Robert Cochran <robert-emacs <at> cochranmail.com>
>> Cc: Robert Cochran <robert-emacs <at> cochranmail.com>,  shanemhansen <at> gmail.com,  24041 <at> debbugs.gnu.org
>> Date: Mon, 22 Aug 2016 11:30:15 -0700
>> 
>> > My only comment is that you could call check_x_display_info with Qnil
>> > as its argument.
>> 
>> I did think about that. But then it arguably does the wrong thing:
>> `check_x_display_info` with `Qnil` only signals an error when there have
>> never been X windows, eg, opening and closing an X window satisfies the
>> check from then on. It no longer crashes in that instance, but I
>> personally don't think that's the right behavior; if my starting frame
>> isn't capable of displaying an xwidget, say so! Hence checking with the
>> current frame.
>
> Joakim, is it certain that the xwidget will always be shown in the
> frame that is the selected one at the time make-xwidget is called?

make-xwidget doesnt actualy show the widget.

There is code like this in xwidget-insert:
    (put-text-property (point) (+ 1 (point))
                       'display (list 'xwidget ':xwidget id))


>
>> Thanks for your reassurance! My one gripe about this patch is that I
>> didn't figure out how to kill the buffer after xwidget creation failure
>> (leaving it seems rather ugly IMO), but I just now realized what I can
>> do. As long as it's not considered wrong to kill a mode's buffer on
>> error, would you also consider this patch to go along with it?
>
> I'm not sure if this is TRT.  I'd rather erase-buffer at the beginning
> of xwidget-webkit-new-session, and leave the buffer alone if we signal
> an error.  The buffer might have contents that the user will hate
> losing, for diagnostic purposes if nothing else.
>
> Joakim, WDYT?

I tried to model the code originaly after what the various emacs image
modes did, mostly along the principle of least surprise. I think emacs
normally works like Eli describes above, so I'd go with that yes.



-- 
Joakim Verona

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.