On Wed, 2 Jun 2010 20:33:37 +0300% Dimitar Zhekov <dimitar.zhe...@gmail.com> wrote:
> On Wed, 2 Jun 2010 09:39:44 +0400 > Eugene Arshinov <earshi...@gmail.com> wrote: > > > On Tue, 1 Jun 2010 21:22:06 +0300% > > Dimitar Zhekov <dimitar.zhe...@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. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel