cheese failing silently

[Michael Butash]

I've had the same problem with Cheese across several distro's now, and
have just given up on whatever being broken being so.  I've got a Dell
xps m1330 with known cheese issues (dell linux list confirms numerous
users with issue) that thus far no one has actually fixed yet, mostly
because there are problems both from the uvcvideo side, as well as from
Cheese.  Exact same symptoms, camera will light twice, indicate it's
working, but will only show black for an image.  Ekiga and other video
apps work fine.  

I've even tried recompiling uvcvideo modules with updates that
supposedly fix the issue from their side, but Cheese still fails, even
latest on Jaunty ubuntu.  The only thing I can recommend is maybe try
compiling your own Cheese from SVN to see if it works locally from the
binary directory, and if so use checkinstall to make a deb package to
update to.  I stopped caring whether it worked or not to go this
far.  :)

-mb


On Mon, 2009-07-27 at 08:20 -0700, Matt Graham wrote:
> From: Dazed_75 <lthielster at gmail.com>
> > Matt Graham <danceswithcrows at usa.net>wrote:
> >> strace and strace -ff can be your friends if the process
> >> that's failing silently is dying because of a missing file,
> >> or a file that's not where it's supposed to be.
> 
> >> The main problem is that this approach won't help much with
> >> programs that communicate with other programs over sockets.
> 
> > Apparently the strace slowed cheese down enough that in addition
> > to seeing the cheese GUI come up and then drop as before, it
> > stayed up long enough that I could see the web cam indicator light
> > come on twice for a moment.
> 
> Well, that shows that *something* is working.
> 
> > {fd=9, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN}, {fd=15,
> > events=POLLIN}],
> > 6, 99The program 'cheese' received an X Window System error.
> > This probably reflects a bug in the program.
> > The error was 'BadAlloc (insufficient resources for operation)'.
> >    To debug your program, run it with the --sync command line
> >    option to change this behavior. You can then get a meaningful
> >    backtrace from your debugger if you break on the
> >    gdk_x_error() function.)
> 
> X problem.  Somewhere in the lower levels of whatever this is doing,
> it made a bad GTK+ or GDK call.  (Or if you're really unlucky, one
> of those libraries is doing something stupid.)  Getting info on
> this with strace will be difficult as X calls are typically made
> over... yep, a socket.  Like the error says, you'd probably have
> to compile with -g, run with --sync in gdb, and break on the
> function mentioned.  Not the world's most fun thing to do.
> 
> > I think I will check again for a revision before I claw further
> > back in the 1.2 MB log file
> 
> That'd be the easiest thing to try, see if they have another
> point release....
>