Hi,
that's nice!
the thing is "why does it only happen with pwc" ?

anyways, what you found confirms what someone else told me a few weeks ago, I just never had time to look into it... here's more info about the linked list problem and maybe a fix for it :
original post (see the comments) :
https://sourceforge.net/tracker/?group_id=54091&atid=472655&func=detail&aid=1281369

and here's a transcipt of the discussion with him on the pwc forum thread :

By: Willem Monsuwe - monsuwe
 RE: segfault when trying to start webcam
2005-10-02 15:20        
To be more exact, the driver doesn't support changing all the properties that the program wants to. For example, on a LT Quickcam 4000, you can set brightness and contrast just fine, it just doesn't happen to have a hue setting. IMHO, the webcam plugin should check what properties the driver supports and be able to change those, but that's a lot of work to do, so that's for later. In any case, the reason for the crash is a fault in the way linked lists are handled in libng(*). If that is remedied, the webcam works better, although not okay, because then the function returns an error, which the tcl code doesn't handle.

*) Linked lists in libng are built by linking to a root pointer, that is allocated by the caller. This means that if you have a linked list as member of a struct, the first item in the list will actually be that member. Furthermore, it's a doubly linked, circular list. This is all fine, as long as you use the original root pointer. As soon as you copy it, for example by assigning the struct, the root pointer will be at a different address. However, inside the linked list there are two pointers pointing to the old address, so as soon as a function traverses the entire list, you will have a dangling pointer bug.

        

By: Alaoui Youness - kakaroto
 RE: segfault when trying to start webcam
2005-10-02 15:41        
Hi,
Try doing this :
./configure --disable-libng
then recompile with make clean all
This way, it will use my own extension instead of libng.. but be aware that it works only for v4l devices, not v4l2. If you found the bug in libng and were able to correct it (i.e. it now works fine with your fix), I would appreciate having the diff so we can patch the CVS version. I personnally don't have time to work on that at the moment... You can also post that bug report to the xawtv team because libng is a library internal to xawtv, it's not our own work. About a webcam's capabilities, I'm not sure if we can now if the webcam supports brightness/hue/color settings.. I think the capabilites only tell us whether the webcam has a tuner, or channels, or supports capturing, etc...

Thanks.
KaKaRoTo

        

By: Willem Monsuwe - monsuwe
 RE: segfault when trying to start webcam
2005-10-06 17:14        
If I do that, I get another segfault, which seems to be resulting from a conversion from YUV420 to RGB, it seems that it's expecting the buffer to be larger than it is. I haven't really dug into this one though.

Anyway, in libng, there is a linked list available, with all the settings that it supports (this is the linked list that causes the crash) so you shuold be able to get it from there. If I get some more free time, I'll try to get a patch together.

Problem is, the fix I wrote causes the SetHUE function to return an error (instead of a float) which amsn currently doesn't handle. So I'll have to learn tcl as well to fix it properly. :) Meaning that might take a few weeks.

        

By: Willem Monsuwe - monsuwe
 RE: segfault when trying to start webcam
2005-10-06 18:01        
Okay, here's a quick workaround/fix that seems to work for me (except that the settings are a bit screwed):

--- capture.c 2005-07-03 20:25:59.000000000 +0200
+++ /usr/share/amsn/utils/linux/capture/capture.c 2005-10-06 23:22:21.000000000 +0200
@@ -421,6 +421,9 @@
captureItem->gfmt = gfmt;
captureItem->conv = conv;
captureItem->handle = handle;
+
+ captureItem->dev.attrs.next->prev = &captureItem->dev.attrs;
+ captureItem->dev.attrs.prev->next = &captureItem->dev.attrs;

// If a converter was used, setup the converter and allocate a new rgb_buffer if(handle) {
@@ -742,6 +745,8 @@
value = attr->read(attr);
Tcl_SetObjResult(interp, Tcl_NewIntObj(value));
}
+ } else {
+ Tcl_SetObjResult(interp, Tcl_NewIntObj(0));
}

return TCL_OK;




I guess we should fix that, can someone review this diff and commit it if it fixes everything ? I'd also like the name of "Willem Monsuwe" in the 'Thanks to' section of the CREDITS if his fix really did the job.

Thanks to anyone willing to do this.
KaKaRoTo



On Sat, 26 Nov 2005 13:15:08 -0500, Harry Vennik <[EMAIL PROTECTED]> wrote:

Hi,

Sorry to say so, but capture.c is a real mess!!!
I'll try to rewrite it sometime.
For now I just made a little patch to make it use ng_attr_byid instead of
looping through the list by itself. (see attachment)

But, whatever way we do it, the bug stays the same. It just crashes in similar code in ng_attr_byid now. But, this has an advantage: I couldn't inspect some variables in Capture_AccessSettings (don't know why), but I can inspect the
equivalent variables in ng_attr_byid. So now I was able to get this
information out of gdb (removed some runs through the loop, and added some
comments):

Breakpoint 3, ng_attr_byid (dev=0x8c20664, id=8)
    at utils/linux/capture/libng/grab-ng.c:246
246             if (attr->id == id)
(gdb) inspect attr
$48 = (struct ng_attribute *) 0x8be9810
(gdb) inspect *attr
$49 = {id = 1, priority = 0, name = 0xb7663b02 "norm",
  group = 0x8bf47cc "Logitech QuickCam Pro 4000", type = 2, defval = 0,
  choices = 0x8c813d0, min = 0, max = 0, points = 0,
read = 0xb77ceb50 <v4l2_read_attr>, write = 0xb77cee10 <v4l2_write_attr>,
  handle = 0x8bf47a8, priv = 0x0, device_list = {next = 0x8be9898,
    prev = 0xbfa176f4}, dev = 0xbfa176e4, global_list = {next = 0x0,
    prev = 0x0}, app = 0x0}
(gdb) step
244         list_for_each(item, &dev->attrs) {
(gdb) step
245 attr = list_entry(item, struct ng_attribute, device_list);
(gdb) step

---------------------- skipping a lot of runs through the loop here -------- ---------------------- Watch the device_list.next pointer now!!!! ----------

246             if (attr->id == id)
(gdb) inspect attr
$70 = (struct ng_attribute *) 0x8be9b80
(gdb) inspect *attr
$71 = {id = 16, priority = 2, name = 0x8bf5ec4 "Gain Level",
  group = 0x8bf47cc "Logitech QuickCam Pro 4000", type = 1, defval = 0,
  choices = 0x0, min = 0, max = 256, points = 0,
read = 0xb77ceb50 <v4l2_read_attr>, write = 0xb77cee10 <v4l2_write_attr>,
  handle = 0x8bf47a8, priv = 0x8bf5ebc, device_list = {next = 0xbfa176f4,
    prev = 0x8be9b68}, dev = 0xbfa176e4, global_list = {next = 0x0,
    prev = 0x0}, app = 0x0}
(gdb) step
244         list_for_each(item, &dev->attrs) {
(gdb) step
245 attr = list_entry(item, struct ng_attribute, device_list);
(gdb) step
246             if (attr->id == id)
(gdb) inspect attr
$72 = (struct ng_attribute *) 0xbfa176bc
(gdb) inspect *attr
$73 = {id = -1210010412, priority = 134522568, name = 0x8c20620 "capture0", group = 0xbfa17738 "ÈŠ\004\bæEØ·", type = -1210164927, defval = -1218031252, choices = 0x0, min = -1079937224, max = -1218059300, points = 146933348, read = 0x8, write = 0x1, handle = 0x1, priv = 0x804a6c8, device_list = { next = 0x804a6c8, prev = 0x804a6c8}, dev = 0xb7dd9424, global_list = {
    next = 0x18, prev = 0xb7e0b4d4}, app = 0x804a6c8}

--------------- I think the above is rubbish already, outside of list!!! -----

(gdb) step
244         list_for_each(item, &dev->attrs) {
(gdb) step
245 attr = list_entry(item, struct ng_attribute, device_list);
(gdb) step
246             if (attr->id == id)
(gdb) inspect attr
$74 = (struct ng_attribute *) 0x804a690
(gdb) inspect *attr
$75 = {id = 0, priority = 0, name = 0x0, group = 0x0, type = 0, defval = 0,
  choices = 0x0, min = 0, max = 0, points = 0, read = 0, write = 0x9,
handle = 0x0, priv = 0x201, device_list = {next = 0x804a7e0, prev = 0x0},
  dev = 0x1, global_list = {next = 0xb7e10180, prev = 0x804b230},
  app = 0x804b240}
(gdb) step
244         list_for_each(item, &dev->attrs) {
(gdb) step
245 attr = list_entry(item, struct ng_attribute, device_list);
(gdb) step
246             if (attr->id == id)
(gdb) inspect attr
$76 = (struct ng_attribute *) 0x804a7a8
(gdb) inspect *attr
$77 = {id = 4096, priority = 4342,
  name = 0x3000 <Address 0x3000 out of bounds>,
  group = 0xfff <Address 0xfff out of bounds>, type = 0, defval = 0,
  choices = 0x0, min = 134742120, max = 80, points = 475026859, read = 0,
write = 0x804f930, handle = 0x804b358, priv = 0x804b1f8, device_list = { next = 0x65746600, prev = 0x35322372}, dev = 0x2e726500, global_list = {
    next = 0x63626577, prev = 0x2e006d61}, app = 0x20392e31}

------ Okay, pointer out of rubbish points to rubbish... ----

(gdb) step
244         list_for_each(item, &dev->attrs) {
(gdb) step
245 attr = list_entry(item, struct ng_attribute, device_list);
(gdb) step
246             if (attr->id == id)
(gdb) inspect attr
$78 = (struct ng_attribute *) 0x657465c8

----------- Okay, there we are!!!! ------

(gdb) inspect *attr
Cannot access memory at address 0x657465c8
(gdb) bt full
#0  ng_attr_byid (dev=0x8c20664, id=8)
    at utils/linux/capture/libng/grab-ng.c:246
        item = (struct list_head *) 0x65746600
        attr = (struct ng_attribute *) 0x657465c8
#1 0xb765e3dc in Capture_AccessSettings (clientData=0x0, interp=0x804a6c8,
    objc=2, objv=0x804b384) at utils/linux/capture/capture.c:724
        attr = Variable "attr" is not available.
(gdb) step

Program received signal SIGSEGV, Segmentation fault.
ng_attr_byid (dev=0x8c20664, id=8) at utils/linux/capture/libng/grab-ng.c:246
246             if (attr->id == id)

-------------------- end of gdb output -------------

Okay, that's the problem: a corrupted list pointer in libng!
I looked at the code for quite some time, but I couldn't find what causes this
problem.

Harry



--
KaKaRoTo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Amsn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Reply via email to