On Wed, 2 Jun 2010 20:33:37 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 2 Jun 2010 09:39:44 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Tue, 1 Jun 2010 21:22:06 +0300% Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
67 works, 68 fails. Stable.
Thanks much for investigating this.
Seems that it will be hard to fix. I've looked through the changes made by merge to files I usually touch in SM, but did not find anything that could cause such a failure. And core SM code in sm.c during the merge, of course, remained the same.
It's somehow sm-related. If I comment out smc_conn = sm_connect(...), 4968 works.
Nice, our estimates are now confirmed.
BTW, you should pass the new client id to gdk_set_sm_client_id(), not the old/NULL one, but that's not the cause of the error.
I don't know how to properly express it in English, but I sometimes think that making stupid little mistakes like this is my second nature. Or maybe the first? :) It's strange that even old client-id seemed to improve the behaviour of Geany on my system… Anyway, I'll fix this error soon, thanks for notice.
In all cases I've googled it's only the program that crashes, not the entire session… Also, errno=32 (EPIPE) indicates something weird is going on. Maybe (blind guess), if startup time is nevertheless the issue, XFCE session manager terminates the connection on timeout…
The "startup time" between which two events? The SM does not know when a program is started, and does not care when/if it's first window will be displayed. You can even write a console program with SM support. :)
Between, for example, establishing the connection and the time when we can handle the first message from session manager (i.e., the time message loop starts working). Again, it's just a wild guess.
Maybe you can track down the bug further by merging trunk to 4967 «step by step» and checking whether the bug is present after each step. When using binary search, those 500 trunk commits will require 10 steps to check. AFAIU, I had no large conflicts while merging. So, if you suddenly have free time for this method, please give it a try.
That'll be a bit more complex. The commits are related, so I can't just arbitarily "turn on/off" half or quarter of them.
But you can merge 1/2 to r67. If the bug appears, go back to r67 and merge 1/4. If the bug doesn't appear, merge 1/8 more. Such a method should work.
And if the crash is caused by 2+ related changes, well...
At least we will find the last of those changes, right? :)
Anyway, I'll run some tests in the weekend.
Thanks you very much in advance.
Best regards, Eugene.