vfs301
vfs301 copied to clipboard
andree182
i have a problem
maybe this helps
(gdb) run Starting program: /home/william/fingerprint/andree182-vfs301-baab9d9/cli/cli [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault. __pthread_mutex_lock (mutex=0x63430b) at pthread_mutex_lock.c:51 51 unsigned int type = PTHREAD_MUTEX_TYPE (mutex);
Unfortunately that doesn't help much. Can you try command "backtrace" in the gdb, if it prints some additional stuff? If nothing is printed, you can still add some debug printf's to cli.c...
I will assume the problem is either gone or sir wvzimmer is gone :-) If there are further problems, please reopen the issue...
Same here (VFS300) :
(gdb) bt #0 __pthread_mutex_lock (mutex=0x20) at pthread_mutex_lock.c:50 #1 0x00007ffff7bd0e6f in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0 #2 0x00007ffff7bd7fac in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0 #3 0x00007ffff7bd837e in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0 #4 0x00007ffff7bd10db in libusb_get_device_list () from /lib/x86_64-linux-gnu/libusb-1.0.so.0 #5 0x00007ffff7bd1ec5 in libusb_open_device_with_vid_pid () from /lib/x86_64-linux-gnu/libusb-1.0.so.0 #6 0x00000000004026da in usb_init () at cli.c:69 #7 0x0000000000402b24 in init (dev=0x60e9c0) at cli.c:188 #8 0x0000000000402ca7 in main (argc=1, argv=0x7fffffffe348) at cli.c:229
To avoid the segfault, the following patch works. However, it doesn't seem to work for me (reading fingerprint and then nothing... blocking at vfs301_proto.c:64).
diff --git a/cli/cli.c b/cli/cli.c
index 4de42b9..5d51eed 100644
--- a/cli/cli.c
+++ b/cli/cli.c
@@ -67,7 +67,7 @@ static void usb_init(void)
for (i = 0; i < sizeof(usb_ids_supported) / sizeof(usb_ids_supported[0]); i++) {
devh = libusb_open_device_with_vid_pid(
- NULL, usb_ids_supported[i][0], usb_ids_supported[i][1]
+ ctx, usb_ids_supported[i][0], usb_ids_supported[i][1]
);
if (devh != NULL)
break;
Hm, for me it looks like the patch (still) works, so what about you (other) guys, does it help? From the libusb documentation it seems like it shouldn't really matter, probably.
Other thing is that the integration with libfprint should be possible - so if it works there, maybe it's useless to debug this probably-not-so-much-used-in-the-near-future utility...
Well, the device is now recognized but it does not seem to work, unfortunately. (talking about fprint_demo)
you could maybe add #define DEBUG to cli/vfs301_proto.c, and maybe also some debug prints to libfprint/vfs301.c - and check where it stops / first fails? If the vfs301_proto_init() is reached, you could post the debug output here, maybe there'll be some hint...
Just a note - do you have the access permissions set up? cli/Makefile should set it up, so this shouldn't be the cause of the problem - but who knows...
% ./cli
send, rv 0, len 1
recv, rv 0, len 38
send, rv 0, len 39
recv, rv 0, len 6
send, rv 0, len 39
recv, rv 0, len 7
send, rv 0, len 1
recv, rv 0, len 64
recv, rv 0, len 4
send, rv 0, len 2401
recv, rv 0, len 2
send, rv 0, len 1
recv, rv 0, len 38
send, rv 0, len 1
recv, rv 0, len 2
send, rv 0, len 1905
recv, rv 0, len 2
send, rv 0, len 2247
recv, rv 0, len 2
recv, rv 0, len 256
recv, rv 0, len 32
send, rv 0, len 1
recv, rv 0, len 2
send, rv 0, len 785
recv, rv 0, len 2
send, rv 0, len 1
recv, rv 0, len 38
send, rv 0, len 2737
recv, rv 0, len 2
recv, rv 0, len 11648
send, rv 0, len 2529
recv, rv 0, len 2
recv, rv 0, len 53248
send, rv 0, len 2542
recv, rv 0, len 2
recv, rv 0, len 19968
send, rv 0, len 2768
recv, rv 0, len 2
recv, rv 0, len 5824
send, rv 0, len 2638
recv, rv 0, len 2
recv, rv 0, len 6656
send, rv 0, len 2651
recv, rv 0, len 2
recv, rv 0, len 6656
send, rv 0, len 570
recv, rv 0, len 2
recv, rv 0, len 832
send, rv 0, len 57
recv, rv 0, len 2
send, rv 0, len 1
recv, rv 0, len 2
send, rv 0, len 1905
recv, rv 0, len 2
send, rv 0, len 2587
recv, rv 0, len 2
recv, rv 0, len 5760
send, rv 0, len 1
recv, rv 0, len 2
send, rv 0, len 2401
recv, rv 0, len 2
send, rv 0, len 1
recv, rv 0, len 2
send, rv 0, len 3057
recv, rv 0, len 2
send, rv 0, len 119
recv, rv 0, len 2
send, rv 0, len 1
recv, rv 0, len 38
send, rv 0, len 2591
recv, rv 0, len 2368
recv, rv 0, len 36
recv, rv 0, len 5760
waiting for next fingerprint... send, rv 0, len 2615
recv, rv 0, len 2
send, rv 0, len 1
recv, rv 0, len 7
send, rv 0, len 1
recv, rv 0, len 7
reading fingerprint... recv, rv 0, len 64
recv, rv 0, len 84032
recv, rv 0, len 84096
recv, rv 0, len 84096
(continue flooding the same thing...)
The permissions are fine, I just need to rerun make access after running ./cli because the owner is reinitialized to root. vfs301_proto_init() is reached.
hey, that actually looks promising - the device seems to accept the the initialization (there are no errors in the log you sent), you are getting the fingerprint data, only for some reason the device doesn't stop reading the fingerprint (maybe there should be some calibration or something).
Seems you aren't a newbie, so here's the hint - try replacing the 'while (1)' loop in vfs301_proto_process_event() for something like 'for (int i = 0; i < 5; i++)'. That should at least return the first fingerprint (hopefully also some following ones).
reading fingerprint... recv, rv 0, len 64
recv, rv 0, len 84032
recv, rv 0, len 84096
recv, rv 0, len 84096
recv, rv 0, len 84096
recv, rv 0, len 84096
send, rv 0, len 1
recv, rv -7, len 0
recv, rv 0, len 864
recv, rv 0, len 2
send, rv 0, len 2587
recv, rv -7, len 0
recv, rv 0, len 2
recv, rv 0, len 5760
fingerprint too short (200x1 px), ignoring...
If I put my finger on the sensor while it reads the fingerprint, I don't have this last error.
And before the first "reading fingerprint..." message, does it wait (i.e. repeat "send, rv 0, len 1"; "recv, rv 0, len 7") until you put the finger on the sensor?
No, it does not wait (I did not put my finger on the sensor):
waiting for next fingerprint... send, rv 0, len 2615
recv, rv 0, len 2
send, rv 0, len 1
recv, rv 0, len 7
send, rv 0, len 1
recv, rv 0, len 7
reading fingerprint...
Hmm, that's not good news... Do youhave windows on your machine? If so, you could do some usb-sniffing and send the log (I'd nagivate you) for some debugging...
Yes, and the only thing installed on it is a usb-sniffer :D. Let me know what you want me to do. I'll do it later tonight.
I suppose you are using 64-bit windows. So you can use e.g. http://www.usblyzer.com/ , it can produce quite nice csv logs... Just don't forget to set 64kb buffers in the settings, otherwise the logs are quite useless I think...
The logging is quite straight-forward. I suggest you disable the device in the device manager, then start logging in usblyzer, and reenable the device. If nothing is still logged, you'll probably have to restart some biometrics service(s) and/or start some program using the scanner.
You can then send me the logs (either ulz or exported to csv, gzipped please :) ) - you can find my email at andree.sk / email.html :) Or get back here if you have trouble obtaining the logs...
Another way to work around this issue is do not use context at all at libusb_init() and libust_exit(), just passing NULL also on both.
