[Geany-devel] SM r4968 bug (was: Multiple instances of Geany issues)
earshinov at xxxxx
Wed Jun 2 18:17:02 UTC 2010
On Wed, 2 Jun 2010 20:33:37 +0300%
Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> On Wed, 2 Jun 2010 09:39:44 +0400
> Eugene Arshinov <earshinov at gmail.com> wrote:
> > On Tue, 1 Jun 2010 21:22:06 +0300%
> > Dimitar Zhekov <dimitar.zhekov at 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
> 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.
More information about the Devel