Closed bgamari closed 10 years ago
basvandijk
commented
10 years ago Hi @bgamari, thanks for reporting this.
Could you check if the same error occurs if you change the condition in the mkDev function from:
if parentDevPtr == nullPtrto:
if TrueI suspect it might have some to do with the parent device feature I added.
It would also be useful if you can share your faulty program with me.
bgamari
commented
10 years ago I also suspected the parent device patch. I'll let you know when I get a chance to test this.
The failing program can be found here. In particular, the USB-facing code is Tracker.LowLevel. Unfortunately I doubt this will be of much use to use as the only instances of the associated hardware in existence exist in my lab and in a box in my apartment ;).
basvandijk
commented
10 years ago Hi @bgamari, did you already had a chance to test this?
bgamari
commented
10 years ago Indeed this fixes the Valgrind warnings.
Despite Valgrind being clean the library appears to deadlock after a few USB transactions. This also occurs when the memory issues are left unfixed. This is with GHC 7.8; usb-1.2.0.1 is known to work in this configuration.
bgamari
commented
10 years ago Actually, I take it back, it seems that usb-1.2.0.1 is also affected by the deadlock issue with GHC 7.8. I've opened #7 to track this unrelated issue.
basvandijk
commented
10 years ago I pushed https://github.com/basvandijk/usb/commit/89ae21d787f8840e99dedba13e15be4bb47b7388 which removes the parent device feature. This should clear up the Valgrind warnings.
Thanks for testing this.
I will close this and continue working on a fix for #7.
While testing 1.3 with a package of mine I noticed some strange behavior and occassional crashes. Running in valgrind made it very clear that there were some object lifetime issues introduced between 1.2.0.1 (which works well) and eba5bcc552caa282441185995a76f1d059374448,