*** Bug 81762 has been marked as a duplicate of this bug. ***

looks like this is for real.

will investigate.

Have you had any joy in debugging this Jacob?

Do you have a simple test app for Linux?

It looks to me like gsm is calling SmsDie on the client at an
inappropriate time. From looking quickly at the code it looks like it
only does this on shutdown tough. Hmmm.

haven't looked at it, as i'm currently fighting default apps crapplet.

there are a few gsm bugs that are in here; planned to tackle them next
week.

if you want to look into this go ahead.

I might have a look at it. I'll let you know how it goes if I do.

Assigning back to gnome-session-maint so we all see any commentry on
the bug

This problem can also be recreated using both sdtfprop and sdthotkey.

adding to my list

i looked at this today.

these apps do not support XSMP, so they do their session management
via gnome-smproxy.

when they map their windows etc., gnome-smproxy connects to
gnome-session and proxies the sm connection.  gnome-session tells
gnome-smproxy to save its session, and gnome-smproxy sends a client
message to sdtprocess to save itself.

sdtprocess does not seem to reply (afaict), and so after a timeout
gnome-session tells gnome-smproxy to kill itself, which it then does
to sdtprocess.

if i had the source to sdtprocess, i could debug that...

do you know of any apps which use the old SM stuff that work correctly?

at this point, i believe the bug to be in sdtprocess and the other apps.

are they session managed in dtsession?

looking at it a bit more, it seems sdtprocess is setting WM_COMMAND
before it gets SaveYourself, or smproxy doesn't get notified because
the property doesn't change.

will investigate a bit more.

Jacob, is perfectly correct. I looked in to it too and came to the
same conclusion ...

sdtprocess is setting the WM_COMMAND property before it ever gets a
WM_SAVE_YOURSELF message. This means smproxy never gets a
PropertyNotify on the WM_COMMAND property. This is not ICCCM compliant
and there is nothing much smproxy/gnome-session can do to work around it.

From the ICCCM:

"
Clients that receive WM_SAVE_YOURSELF should place themselves in a
state from which they can be restarted and should update WM_COMMAND to
be a command that will restart them in this state. The session manager
will be waiting for a PropertyNotify event on WM_COMMAND as a
confirmation that the client has saved its state. Therefore,
WM_COMMAND should be updated (perhaps with a zero-length append) even
if its contents are correct.
"

sdtprocess should be fixed to do a zero-length append on the property
when it receives the WM_SAVE_YOURSELF message.

This problem is because CDE applications depend on the "_DT_SAVE_MODE"
property to know where to save the SM_COMMAND data.  It will save them
in $HOME/.dt/sessions/(_DT_SAVE_MODE).  If this directory does not
exist, then any CD application will create it the first time it
receives WM_SAVE_YOURSELF.

_DT_SAVE_MODE values of "home" and "current" are used by CDE.

So, all CDE programs will work okay if the _DT_SAVE_MODE property is
set with the XServer.  I recommend using the value "gnome" (or
anything other than "home" and "current"), so any CDE home and
current sessions are never affected.

If you run this little X-program which sets this _DT_SAVE_MODE
property, then everything will work okay.  No crashes.  It assumes
that the DISPLAY environment variable has a real value.  Therefore,
in an environment where CDE programs are likely to be run, the
following program should probably be run when Gnome first starts up.
Note that the user will get a $HOME/.dt/sessions/gnome directory
automatically created whenever they start a CDE program that 
receives a WM_SAVE_YOURSELF.  

The code can be compiled with these options:

  cc -L/usr/openwin/lib -lX11

--code starts--

#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xos.h>
#include <X11/Xatom.h>
#include <stdio.h>
#include <stdlib.h>

char GNOME_DIRECTORY[] = "gnome";

void main(int argc, char **argv) {

   Display       *display;
   unsigned char *propData;
   Atom           XaSmSaveMode;
   char          *display_name;

   display_name = getenv("DISPLAY");
   propData     = (unsigned char *) GNOME_DIRECTORY;
   display      = XOpenDisplay(display_name);

   XaSmSaveMode = XInternAtom(display, "_DT_SAVE_MODE", False);

   XChangeProperty(display, RootWindow(display, 0),
          XaSmSaveMode, XA_STRING, 8, PropModeReplace,
          propData, strlen((char *)propData));

   XCloseDisplay(display);
}

--code ends--
 

But you do accept that these apps are broken - they do not comply with
what the ICCCM explicitly says - and that they should be fixed ?

I've added the following patch, just because the workaround is trivial.

Created attachment 8767 [details] [review]
Workaround patch that has been committed.

Currently all CDE applications require this property to be set in
order for them to work properly.  Therefore the fix is either to
make all CDE applications behave properly even when the property
is missing, or to make the setting of this property be a public
dependency.

I've submitted a bug against the CDE arguing that this property
should be made public and information about its requirement 
included in the CDE man pages.  Regardless this is a CDE issue
so we can continue this discussion via bugtraq.

You can only do that by modifying the ICCCM, the specification the CDE
 apps are supposed to be following ...

I'm totally bewildered that you don't understand that ...

I have just noticed that it is also necessary to set _DT_RESTORE_MODE
to the same value that is used by _DT_SAVE_MODE.  _DT_SAVE_MODE is
used when a program is sent WM_SAVE_YOURSELF, and _DT_RESTORE_MODE
is used when restoring programs.  I have included this fix in a 
patch for another problem.  Refer to:

   http://bugzilla.gnome.org/show_bug.cgi?id=85933

This issue has been fixed with the CDE that will ship with Solaris
10.  When _DT_SAVE_MODE and _DT_RESTORE_MODE are not set, they will
default to "other".  This will keep programs from core dumping in
a nicer way, and won't require that session managers set
_DT_SAVE_MODE or _DT_RESTORE_MODE.  Unfortunately there is no
current push to backport this to Solaris 8 or 9.

However it is probably desirable for Gnome to set these values
to a unique (non "other") value.   This is because all session
managers that do not set _DT_SAVE_MODE and _DT_RESTORE_MODE to
a unique value will all share "other".  This means that CDE
session information set with one session-manager using the
default "other" value will override the CDE session information
set in any other session-manager that is also using the default
"other" value.  Gnome setting it to the unique "gnome" value
ensures that when running Gnome, CDE programs will store session
information in a directory unique to Gnome.  Therefore I think 
this "hack" is appropriate to support CDE compatibility.

Brian. None of this should be neccessary. It only is neccessary
because the protocol is fundamently broken and, hence, deprecated. CDE
should be moving to using XSMP. Under that protocol, you *never*
overwrite your session data. You save in a new unique file each time
and DiscardCommand is called deleting the old file.

I've committed the following

2002-07-02  Mark McLoughlin  <mark@skynet.ie>

        * smproxy.c: also set _DT_RESTORE_MODE to "gnome"
        for very broken CDE apps. See #81343.