Re: Problems with emacs built with gsettings support [was: Problems with emacs built against gtk3]

[Ken Brown <kbrown@cornell.edu>]

On 4/4/2012 6:12 PM, Yaakov (Cygwin/X) wrote:
> On 2012-04-04 09:15, Ken Brown wrote:
>> Another option is to use gtk3 but to put the GSETTINGS_BACKEND
>> workaround into the emacs startup code:
>>
>> setenv ("GSETTINGS_BACKEND", "memory", 1);
>>
>> I've been testing this, and it seems to work (but I won't be completely
>> confident until I've had emacs running for a day or so). Do you see any
>> downside?
>
> This is intended solely for testing and debugging. Settings will not be
> saved from one invocation to the next, so that's a pretty big downside.

OK, that was a bad idea.  I'm going to try to debug this problem.

I was wrong when I said that the problem doesn't occur with gtk2.  I 
based that statement on earlier tests; but I did those tests several 
months ago, when I started this thread, and I probably didn't have 
dconf-service installed at the time.  Now I can reproduce the problem 
with both gtk2 and gtk3.  But the problem doesn't occur if I build emacs 
with the configure option --without-gsettings.  I've changed the subject 
line accordingly.

By the way, emacs (starting with emacs-24) will use both GSettings and 
GConf if they're available.  But there doesn't appear to be any problem 
using GConf alone.

Here's my most recent debugging session.  This is from a build using 
gtk2 and GSettings (but not GConf):

GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
[...]
Reading symbols from /home/kbrown/src/emacs/test/src/emacs...done.
(gdb) r -Q
Starting program: /home/kbrown/src/emacs/test/src/emacs -Q
[New Thread 12220.0x950]
[...]
[New Thread 12220.0x330c]

Program received signal SIGSEGV, Segmentation fault.
0x00289d7a in ?? ()
(gdb) bt full
#0  0x00289d7a in ?? ()
No symbol table info available.
#1  0x007bd264 in __morecore ()
No symbol table info available.
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

#2  0x00000001 in ?? ()
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

         wsock_started = true
         wsadata = {wVersion = 514, wHighVersion = 514,
           szDescription = "WinSock 2.0", '\000' <repeats 245 times>,
           szSystemStatus = "Running", '\000' <repeats 121 times>,
           iMaxSockets = 0, iMaxUdpDg = 0, lpVendorInfo = 0x0}
#3  0x00606175 in calloc (nmemb=4294867296, size=8) at gmalloc.c:1547
         result = 0x0
#4  0x00000000 in ?? ()
No symbol table info available.

This looks very strange to me, especially the part about WinSock.  Where 
could that have come from?

Here are the steps for reproducing the problem:

1. Install the following packages and their dependencies:

   gnutls-devel
   libdbus1-devel
   libdbus1_3
   libgif-devel
   libgtk2.0-devel
   libgtk3-devel
   libMagick-devel
   libMagickCore5
   librsvg2-devel
   libSM-devel
   libXpm-devel

[These might not all be necessary for reproducing the problem, but 
they're used in my build or as runtime dependencies of my build.]

2. Build emacs with GSettings support but not GConf support:

wget ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.95.tar.gz
tar -xf emacs-24.0.95.tar.gz
cd emacs-24.0.95
./configure --without-gconf && make

[Note: By default, the build will use gtk2.  The option 
"--with-x-toolkit=gtk3" will make it use gtk3.]

3. Start the X server using the Start Menu shortcut, with no ~/.startxwinrc.

4. In the resulting xterm window:

eval `dbus-launch --sh-syntax`
cd emacs-24.0.95/src
./emacs -Q &

5. Ignore emacs; it will eventually crash.  This could take one or more 
hours, but it happens every time on my system.  It happens much faster 
if I don't disable GConf support.

It would be extremely helpful if someone could try to reproduce this. 
At the very least, I'd like to rule out the possibility that it's caused 
by BLODA on my system.

Ken

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/