Author Topic: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here  (Read 6381 times)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« on: September 05, 2022, 07:37:29 pm »
Folks!

Just a quick FYI, I'm seeing a trap in SCANIMAGE.EXE following the deployment of libusb1 1.0.24 RPM package.

My scanner is USB attached, latest AOS drivers and was previously successfully using 1.0.21-2 release.

I went ahead and opened a NEW Issue https://github.com/bitwiseworks/libusb1-os2/issues/4, but great GitHub functionality prevents you for actually uploading any LOG files...LOL!!!

Anyways, if you're seeing strange results/traps be aware.

ivan

  • Hero Member
  • *****
  • Posts: 1557
  • Karma: +17/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #1 on: September 05, 2022, 07:51:05 pm »
Good job I changed all my scanners to be network based ones after scanimage stopped working on my usb based unit.  The big advantage with this is the fact I can get PDFs direct from the scanner as well as pictures.

Tom

  • Full Member
  • ***
  • Posts: 194
  • Karma: +5/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #2 on: September 05, 2022, 09:39:25 pm »
I went ahead and opened a NEW Issue https://github.com/bitwiseworks/libusb1-os2/issues/4, but great GitHub functionality prevents you for actually uploading any LOG files...LOL!!!

You could try uploading that logfile as a textfile with the .txt extension.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #3 on: September 05, 2022, 10:06:47 pm »
Hey Tom!
I went ahead and opened a NEW Issue https://github.com/bitwiseworks/libusb1-os2/issues/4, but great GitHub functionality prevents you for actually uploading any LOG files...LOL!!!

You could try uploading that logfile as a textfile with the .txt extension.

Actully did try that already, initially I was attempting to u/l them individually (to make it easier to look through), but when that failed I tried the ZIP way.

Anyways...I think this is that whole GitHub "totally unfriendly to anything but Chrome" issue.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #4 on: September 05, 2022, 10:10:54 pm »
Ivan!

Good job I changed all my scanners to be network based ones after scanimage stopped working on my usb based unit.  The big advantage with this is the fact I can get PDFs direct from the scanner as well as pictures.

LOL, you know, when that failure took place I went to my "Plan-B", which is the little WiFi HP Envy printer/scanner (that does JPG & PDF formatted scans), but I do prefer my dedicated HP scanner otherwise.

By the looks of it the new libusb1 DLL is misidentifying the USB "bus" that device is connected on: '003:001' vs '001:001' (which worked before). So maybe it's an easy fix? We'll see...

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #5 on: September 05, 2022, 10:38:29 pm »
No the bus number change is intentional.
It used to be hard coded to 1, now it is taking the host controller number (which effectively is the bus number).
The second number is the device number. That should be > 1 though (I am not sure,I forgot). in any case, that is purely cosmetic and not the problem. If someone could send me an exceptq report, that could help to fix the problem.
The other thing that you could do is to do a "SET LIBUSB_DEBUG=255" and pipe stderr to a file. That'll give detailed info of what Libusb is doing.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #6 on: September 06, 2022, 12:09:44 am »
Hi Lars!

No the bus number change is intentional.
It used to be hard coded to 1, now it is taking the host controller number (which effectively is the bus number).
The second number is the device number. That should be > 1 though (I am not sure,I forgot). in any case, that is purely cosmetic and not the problem. If someone could send me an exceptq report, that could help to fix the problem...

Hmm...very good, well, at least it's reassuring to know this isn't some kind of un-known that I've ran into.

So here is the output of 'usbtree':

Code: [Select]
[G:\]usbtree
USB driver version = 12.13
----- USB device tree ---------
DS 0808=7814

Controller 0: USBEHCD$
Root Hub 0 (5 ports) 1002:4396
Cannot find hub

Controller 0: USBEHCD$
Root Hub 1 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 2 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 3 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 4 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 5 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 6 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 7 (0 ports) 1002:4396

Controller 0: USBEHCD$
Root Hub 8 (0 ports) 1002:4396

...and I've attached a quick screenshot of the Hadware Manager window showing the HP Scanner and the remaining USB ports.

...The other thing that you could do is to do a "SET LIBUSB_DEBUG=255" and pipe stderr to a file. That'll give detailed info of what Libusb is doing.

I've attached the sane LOG files I was attempting to u/l to the GitHub ticket. The TRP file is in there as well.

Now, here is an interesting part that I had ran into, found the following lines in my CONFIG.SYS:

Code: [Select]
SET SANE_CONFIG_DIR=g:\etc\sane.d
SET SANE_DEFAULT_DEVICE=hp:libusb:001:001

SET SANE_DEBUG_HPAIO=4
SET SANE_DEBUG_HP=4
SET SANE_DEBUG_SANEI_USB=4
SET SANE_DEBUG_DLL=4

...and now I suspect that the "SET SANE_DEFAULT_DEVICE=hp:libusb:001:001" is the actual PROBLEM here!!!

There is a reason why I had set this up...I did this at the time that I moved to RPM based SANE setup, previously I had a separate ZIP based install.

Soooo....let me take a shot at this by figuring out why I would have used that SET statement and then re-running with the latest USBLIB1 1.0.24 drop to see if that's perhaps what has caused the problem.

Damn...nice...thank you for asking the questions...normally I look through CONFIG.SYS to rule out any of such customizations, but clearly in this case I missed that step.
« Last Edit: September 06, 2022, 12:15:09 am by Dariusz Piatkowski »

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #7 on: September 06, 2022, 12:12:44 am »
Additionally,
Libusb makes use of USBCALLS.
Have you tried to revert back to older USB drivers and see if that makes a difference?

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #8 on: September 06, 2022, 12:17:48 am »
You already gave the answer: the device is correctly detected at 3:1 but you are forcing to 1:1.
With unpredictable consequences.

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #9 on: September 06, 2022, 12:24:23 am »
...plus
the output of usbtree does not line up with what the HW manager shows. Just look at the vid:pid for the hubs.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #10 on: September 06, 2022, 03:54:03 am »
You already gave the answer: the device is correctly detected at 3:1 but you are forcing to 1:1.
With unpredictable consequences.

Indeed, that was the problem!

I rely on a home-cooked scan REXX script that allows me to pass a whole slew of different option parameters to it, and these are all selected through different SCAN program icons/objects. So in the end it's an easy drop-down/select from the WPS folder.

I suspect in my testing I discovered that I needed that SET statement and eventually just moved it to CONFIG.SYS instead of having it done at the script level.

If there is a comment I'd make, it is the following: SCANIMAGE should fail more gracefully...LOL, yeah, it can't quite stop me from shooting myself in the foot like I did...but something better than a TRP would go a long way to troubleshooing the root cause.

Anyways...FALSE ALARM everyone, my appologies.

Lars,
Thank you for the talking points b/c that's ultimatley what made me pick up that CONFIG.SYS statement.

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #11 on: September 06, 2022, 08:53:06 am »
Yes, it would be a good idea for Scanimage to check if there indeed is a device at the "default" location. It apparently does not and blindly continues.
But I don't know where to find the scanimage source code.

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: libusb1 - 1.0.24-x drop => causes a trap in SCANIMAGE here
« Reply #13 on: September 09, 2022, 11:16:16 am »
I looked at the trap report: I have the impression that a DLL was dynamically loaded (I suspect hp1.dll in this case), subsequently unloaded (because opening of default device failed) and scanimage.exe subsequently trying to call into the DLL. And BOOM it goes.
If I ever find the time, I will have a look at it.