Op zaterdag 26 november 2005 20:03, schreef Youness Alaoui: > Hi, > that's nice! > the thing is "why does it only happen with pwc" ? I think I understand. The list contains the attributes we can set. And there are some attributes that cannot be set with the pwc driver, so those attributes won't appear in the list. All other drivers we know support these attributes. So only with the pwc driver it happens that we have to loop through all the list, to know that the attribute is not available, so only with the pwc driver we get far enough to reach the bad pointer! > > 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. No, let's just have a set of attributes to set, and check if those are available, and disable them if not. (That's what we are trying to do now, but it fails because of the dangling pointer bug. Please also note that doing it the way proposed here - detect features and use those - will always fail, with every driver (!), because of the same bug.)
> 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. Hmm, have to look at it better to know if this is true. But even if it is, it probably won't hurt anyway. > > *) 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. This is how things may go, but I think the dangling pointer problem has a different cause in this case. I think so because of the unlikely value of the pointer in an otherwise correctly filled structure for the 'Gain Level' attribute. I think there is just some buggy code in libng that happens to overwrite the pointer with something else. Harry ------------------------------------------------------- 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_id=7637&alloc_id=16865&op=click _______________________________________________ Amsn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amsn-devel
