Bug 3821

Created attachment 1275 [details]
Extract from the dmesg after the webcam connection (shorted)

That has nothing to do with the installer.
If cheese is crashing, then:
1) enable the Core debug medium, 
2) install the following packages: glibc-devel, cheese-debug gtk+3.0-debug  gdk-pixbuf2.0-debug  glib2.0-debug v4l-utils-debug gdb
3) run the following command from a terminal "gdb -q cheese"
4) type "run", cheese will start
5) when cheese crashes, type "bt", then copy the stack trace in some text file you will _attach_ to this bug report

CC: (none) => thierry.vignaud
Component: Installer => RPM Packages
Source RPM: (none) => cheese

Created attachment 1278 [details]
The debugginng command

err it didn't crashed...

Yes :/
But when I launch it without gdb, I get:
** CRITICAL **: cheese_effect_load_effects_from_directory: assertion `is_dir' failed

** CRITICAL **: cheese_effect_load_effects_from_directory: assertion `is_dir' failed
Erreur de segmentation".

@ papoteur

Is this bug still valid in current cauldron (mga2a3)?

cc'ing cheese maintainer

Keywords: (none) => NEEDINFO
CC: (none) => marja11, olav

(In reply to comment #6)
> @ papoteur
> 
> Is this bug still valid in current cauldron (mga2a3)?
I have updated to alpha3.
Yet, Cheese can not be launched :

cheese

Clutter-CRITICAL **: Unable to initialize Clutter: The OpenGL version could not be determined


urpmq cheese -i
pas d'information xml pour le média « core media », uniquement un résultat partiel pour le paquetage cheese
Name        : cheese
Version     : 3.3.3
Release     : 1.mga2
Group       : Video
Size        : 4382341                      Architecture: i586
Summary     : A GNOME application for taking pictures and videos from a webcam

assigning to maintainer

Keywords: NEEDINFO => (none)
Assignee: bugsquad => olav

I retest with Mageia beta2.
When the webcam is not connected, Cheese crashes :
** WARNING **: cheese-window.vala:1624: Error: Aucun périphérique détecté

Erreur de segmentation (core dumped)

(no peripheral detected, segfault)

When the webcam is connected, Cheese start, but does not recognizes the webcam :
** WARNING **: Could not negotiate format

In the same, I get this messages from dmesg :
cheese[2542]: segfault at 484 ip b69a0129 sp bfe3fa30 error 4 in libcogl.so.8.0.0[b696f000+80000]
cheese[2565]: segfault at 484 ip b694d129 sp bfe54d30 error 4 in libcogl.so.8.0.0[b691c000+80000]
usb 5-4: new high-speed USB device number 3 using ehci_hcd
usb 5-4: New USB device found, idVendor=046d, idProduct=0825
usb 5-4: New USB device strings: Mfr=0, Product=0, SerialNumber=2
usb 5-4: SerialNumber: B9B963A0
Linux media interface: v0.10
Linux video capture interface: v2.00
3:3:4: cannot get freq at ep 0x86
5:2: cannot get min/max values for control 2 (id 5)
usbcore: registered new interface driver snd-usb-audio
uvcvideo: Found UVC 1.00 device <unnamed> (046d:0825)
input: UVC Camera (046d:0825) as /devices/pci0000:00/0000:00:1d.7/usb5/5-4/5-4:1.0/input/input4
usbcore: registered new interface driver uvcvideo
USB Video Class driver (1.1.1)
uvcvideo: Failed to query (GET_CUR) UVC control 2 on unit 2: -110 (exp. 2).
uvcvideo: Failed to query (GET_CUR) UVC control 7 on unit 2: -110 (exp. 2).
Yves

Can you try to get the GDB backtrace when it's actually segfaulting (ie when the webcam is not connected)?
Thx

Keywords: (none) => NEEDINFO
Summary: Webcam Logitech not working => Webcam Logitech not working & cheese is segfaulting

Here the result from gdb.

Created attachment 1660 [details]
gdb results

You need to install latest glibc-debug, gtk+3.0-debug cheese-debug & cogl-debug and try again

(In reply to comment #13)
> You need to install latest glibc-debug, gtk+3.0-debug cheese-debug & cogl-debug
> and try again

After installing, I get :
** WARNING **: La connexion est fermée

** WARNING **: La connexion est fermée

** WARNING **: cheese-window.vala:1624: Error: Aucun périphérique détecté

[New Thread 0xa51a5b70 (LWP 2001)]

Program received signal SIGSEGV, Segmentation fault.
_cogl_pipeline_copy (src=0x400, is_weak=0) at ./cogl-pipeline.c:370
370	  pipeline->real_blend_enable = src->real_blend_enable;

I'm not sure that the version are the latest.
Yves

This looks promising!

Please paste all lines from "Program received signal SIGSEGV, Segmentation fault" in some file.
Then type "bt" and paste the trace printed by gdb into that file too.
Then attach that file here.
thanks

Created attachment 1668 [details]
Gdb output after crashing when video device not present

OK it looks like a bug in libcogl then with a pointer in the first page which should not happen.
Can you install cogl-debug & clutter-debug and try again to get the trace?

CC: (none) => fundawang
Assignee: olav => jani.valimaa
Summary: Webcam Logitech not working & cheese is segfaulting => Webcam Logitech not working & cheese is segfaulting in cogl
Source RPM: cheese => cogl

Created attachment 1671 [details]
Gdb output again and more complete

I haven't see that the was more screens as the first.
cogl-debug was already present. The other has been added.
Yves

Removing NEEDINFO keyword, because requested information has been given

Keywords: NEEDINFO => (none)

I do new tests with my webcam and Cauldron uptodate.
guvcview does not detect the webcam.
I get :
guvcview 1.5.3
Cannot connect to server socket err = Aucun fichier ou dossier de ce type
Cannot connect to server socket
jack server is not running or cannot be started
video device: /dev/video0 
ERROR opening V4L2 interface for /dev/video0
unable to detect video devices on your system (0)
ERROR opening V4L interface: Permission non accordée
Init video returned -1
VIDIOC_REQBUFS - Failed to delete buffers: Argument invalide (errno 22)
cleaned allocations - 100%
Closing portaudio ...OK
Terminated.

permission non accordée means rights not allowed.
I have added the user to the group video, but the problem is the same.

With cheese, I get a segfault :
** (cheese:4464): CRITICAL **: cheese_camera_device_get_uuid: assertion `CHEESE_IS_CAMERA_DEVICE (device)' failed
Erreur de segmentation

When connecting the webcam, and after launching cheese, dmesg gives:
[   99.177038] usb 2-2: new high-speed USB device number 3 using ehci_hcd
[   99.511712] usb 2-2: New USB device found, idVendor=046d, idProduct=0825
[   99.511724] usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=2
[   99.511734] usb 2-2: SerialNumber: B9B963A0
[  100.297937] Linux media interface: v0.10
[  100.355174] Linux video capture interface: v2.00
[  101.472124] 3:3:2: cannot get freq at ep 0x86
[  101.612682] 5:2: cannot get min/max values for control 2 (id 5)
[  101.613678] usbcore: registered new interface driver snd-usb-audio
[  101.616970] uvcvideo: Found UVC 1.00 device <unnamed> (046d:0825)
[  101.651744] input: UVC Camera (046d:0825) as /devices/pci0000:00/0000:00:10.4/usb2/2-2/2-2:1.0/input/input5
[  101.653218] usbcore: registered new interface driver uvcvideo
[  101.653229] USB Video Class driver (1.1.1)
[  104.047305] cheese[1330]: segfault at 0 ip b6b8d258 sp bfe919fc error 4 in libc-2.14.1.so[b6b19000+177000]
[ 5749.356176] cheese[4464]: segfault at 0 ip b6b55258 sp bfab14dc error 4 in libc-2.14.1.so[b6ae1000+177000]

udev/systemd may not set up appropriate ACLs

CC: (none) => mageia

Can you post the output from: "udevadm info -q all -n /dev/video0" and "getfacl /dev/video0"

Created attachment 1890 [details]
getfacl and udevadm info output.

I'm having similar problems with my webcam, as reported in bug 5031,
although I haven't seen any segfaults.

@Dave. Well it's certainly not a permissions problem in your case. That output all looks good.

Have you tried with final 3.40 version?

Created attachment 1891 [details]
getfacl and udevadm info

The version is already 3.4.0.
I have setfacl to add the user, and then guvcview works. For cheese, it's OK but very slow.
Yves

(In reply to comment #26)
> Created attachment 1891 [details]
> getfacl and udevadm info
> 
> The version is already 3.4.0.
> I have setfacl to add the user, and then guvcview works. For cheese, it's OK
> but very slow.


OK, so your user is not in the ACL, but the device is clearly labelled as having the uaccess tag.

So this tells me something is messed up below this. However you should be having many more problems than just this (e.g. your audio should not work either).

Can you also check:

1. getfacl /dev/snd/pcm*
2. ck-list-sessions
3. systemd-loginctl (or loginctl if using latest systemd just uploaded a short while ago)

Cheers

Created attachment 1907 [details]
Results of ck-list-sessions

Created attachment 1908 [details]
results of getfacl

Indeed your user is not in the ACL for your audio devices either, so your audio is likely broken too (unless you've added your user to the audio group as a hack?).

Either way something is not working right.

Can you also the final thing requested in my comment above (point 3)?

In pulseaudio, the output is dummy (sortie factice). This confirm that the sound is not working.
Yesterday, when I try the command system-loginctl, I got "0 sessions listed".
But today, after an update, I must use the command loginctl.
I get :
   SESSION        UID USER             SEAT            
         1        500 yves                             

1 sessions listed.

Does this now help in terms of permissions (i.e. now that you have your session listed, do all the permission problems go away - is your user in the ACLs etc. etc.?)

No.
getfacl /dev/video0 
getfacl : suppression du premier « / » des noms de chemins absolus
# file: dev/video0
# owner: root
# group: video
user::rw-
group::rw-
other::---

OK, so some more debug:

loginctl session-status 1 (or whatever value is listed from loginctl)


Can you also describe your setup a bit?

e.g. how do you start X? Which login manager do you use? If you use e.g. slim or lxdm etc., can you try using gdm or kdm and see if you get the same results, especially fro the getfacl command).

I'm pretty certainly this is nothing to do with cheese and 100% to do with how your X session is started.

Today, there is no session listed.
My display manager is xdm. lxdm is also installed but not used.
The connection is automatic at boot.
I will try lxdm.

Both with lxde and xdm, loginctl give no sessions when I have an automatic connection.
I get 1 sessions when I connect no automatically.
Should I really test  with kdm or gdm? They are not yet installed.

With the manual connection, I get the good ACLs :)
getfacl /dev/video0
getfacl : suppression du premier « / » des noms de chemins absolus
# file: dev/video0
# owner: root
# group: video
user::rw-
user:yves:rw-
group::rw-
mask::rw-
other::---

Ahh yes, autologin tends to break things :s

Can you tell me how you configure autologin? Different DMs sometimes implement their own, but we also have a generic autologin system too. Do you know which is in use in your case? How do you configure autologin?

hello Colin,
I use only the tools from MCC. Thus, I do not know which application configures the autologin.

OK, I'll see if I can reproduce. I think I know where the problem is.

OK, so there are several problems here.

Firstly autologin source used tty0 when speaking to PAM for it's login session but this is not valid (login sessions should start from tty1). This meant that no session was ever registered as logind simply rejected it.


In addition to this, when X was subsequently started, it switched VT to 7 which corresponds to vt7 which meant that the original session registered was considered no longer active.

I've worked around this by forcing both the login session used in autologin and the X to start on tty1/vt1

This seems to work in my testing.

It should be noted that this is somewhat fragile, but the way in which autologin works is pretty broken. It start X, get allocated an X display and a vt and then use this when talking to pam when creating a session for the user.

So for mga3 autologin should be dropped in favour of an alternative (e.g. gdm's autologin capabilities) or completely rewritten.

Please let me know if this updated package works for you.

Status: NEW => ASSIGNED

autologin is for dms other than gdm or kdm that handles that fine.
until xdm/lxdm/... do not handle autologin, we've to do it

AFAICT, it still kicks in when configured even if used under gdm or kdm, so maybe the prefdm script needs looked at (it is entirely possible that it was me who broke this during an old prefdm refactor, but if so, it was a looong time ago).

After an update this morning, the ACL's are OK, even with autologin.
Thanks
Yves

So just to confirm, is there still a problem with the camera stuff or was it all down to the ACLs?

With my logitech quickcam messenger, which uses the gspca_stv06xx module,
cheese still gets the "failed to negotiate format" error, and does not
have a permission problem.

CC: (none) => davidwhodgins

The webcam works fine with guvcview.
Cheese works, but takes a long time to be launched (2 minutes).

Yves

While I know this bug was originally opened against cheese, it's gone through the spin cycle to get to where it is now!

It might be clearer if you open a new bug for the delay in startup with cheese just so the maintainer can clearly see the problem rather than wading through 50 comments? (tho' FWIW, I cannot reproduce). 

If that's OK with you can you open the new bug, paste a reference here and close this one?

Ok

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED