[Geany-devel] SM r4968 bug (was: Multiple instances of Geany issues)

[Eugene Arshinov]

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
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.