Bug 655836

Hmm,

Bummer. So you did not see these crashes with spice-client-0.6.3-3 ? And when you say: "in spice-client-0.6.3-4.fc14.x86_64", you mean the scratchy build I did for bug 654265 I assume? As there has not been an official spice-client-0.6.3-4 release yet. And when you're using the git compiled version, have you included the patch I did for 654265 yourself, or is it just plain git ?

Also could you perhaps edit: client/x11/platform.cpp, goto line 298 and replace the:
            THROW("no window proc");
With:
            printf("no window proc\n");
            continue;

Re-compile and then start spicec under a debugger and set a break point at the
printf("no window proc\n"); Then use as normally until the break point hits, when the breakpoint hits, do a bt on all threads and print the contents of event.

Thanks,

Hans

(In reply to comment #1)
> Hmm,
> 
> Bummer. So you did not see these crashes with spice-client-0.6.3-3 ? And when
> you say: "in spice-client-0.6.3-4.fc14.x86_64", you mean the scratchy build I
> did for bug 654265 I assume? As there has not been an official
> spice-client-0.6.3-4 release yet. And when you're using the git compiled
> version, have you included the patch I did for 654265 yourself, or is it just
> plain git ?

I think I did see these with 0.6.3-3, but didn't report them. I can't be 100% certain, though. Yes, the 0.6.3-4 I refer to is your scratch build. My local git repo has the fix for 654265 in it.

> Also could you perhaps edit: client/x11/platform.cpp, goto line 298 and replace
> the:
>             THROW("no window proc");
> With:
>             printf("no window proc\n");
>             continue;
> 
> Re-compile and then start spicec under a debugger and set a break point at the
> printf("no window proc\n"); Then use as normally until the break point hits,
> when the breakpoint hits, do a bt on all threads and print the contents of
> event.

Because of my lack of confidence in gdb's breakpoints in the face of optimisation, I've stuck an abort() immediately before the THROW(), and have enabled core dumps. Is there anything you can think of which might stop that from doing what I expect?

(In reply to comment #2)
> (In reply to comment #1)
> > Hmm,
> > 
> > Bummer. So you did not see these crashes with spice-client-0.6.3-3 ? And when
> > you say: "in spice-client-0.6.3-4.fc14.x86_64", you mean the scratchy build I
> > did for bug 654265 I assume? As there has not been an official
> > spice-client-0.6.3-4 release yet. And when you're using the git compiled
> > version, have you included the patch I did for 654265 yourself, or is it just
> > plain git ?
> 
> I think I did see these with 0.6.3-3, but didn't report them. I can't be 100%
> certain, though. Yes, the 0.6.3-4 I refer to is your scratch build. My local
> git repo has the fix for 654265 in it.
> 
> > Also could you perhaps edit: client/x11/platform.cpp, goto line 298 and replace
> > the:
> >             THROW("no window proc");
> > With:
> >             printf("no window proc\n");
> >             continue;
> > 
> > Re-compile and then start spicec under a debugger and set a break point at the
> > printf("no window proc\n"); Then use as normally until the break point hits,
> > when the breakpoint hits, do a bt on all threads and print the contents of
> > event.
> 
> Because of my lack of confidence in gdb's breakpoints in the face of
> optimisation, I've stuck an abort() immediately before the THROW(), and have
> enabled core dumps. Is there anything you can think of which might stop that
> from doing what I expect?

No. that should work fine as far as I can see.

Created attachment 462067 [details]
spicec thread backtraces at abort()

I've also included 'info locals' for the function containing the abort(). I'll keep the core and binary around for a bit.

Matthew and I have been debugging this further by mail + irc. The problem is that when ibus XIM input gets used, an invisible window get created by XIM and sometimes we receive events on this window. Since this window is not created by us it does not have an event handler function stored as window context, causing us to raise the "no window proc" exception causing the crash reported here.

Specifically Matthew has been seeing _GTK_LOAD_ICONTHEMES type client messages been posted as events to this hidden window.

To reproduce do:
1) install ibus (yum groupinstall "Input Methods")
2) run im-chooser choose ibus
3) add Chinese - Pinyin input method
4) change an icon under /usr/share/icons/hicolor
5) touch /usr/share/icons/hicolor
6) gtk-update-icon-cache /usr/share/icons/hicolor
7) profit^W spicec terminated by "no window proc" exception

I've a patch for this upstream, expect an update fixing this soon.

spice-0.6.3-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/spice-0.6.3-4.fc14

spice-0.6.3-4.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update spice'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/spice-0.6.3-4.fc14

spice-0.6.3-4.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.