Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AirSane inconsistently segfaults on init with the default list of backends enabled in dll.conf #24

Closed
patters-syno opened this issue Sep 11, 2019 · 10 comments

Comments

@patters-syno
Copy link

commented Sep 11, 2019

This one confused me. In my testing I had commented out all the backends except my own scanner's plustek one and airsaned was very reliable - starting and stopping as expected hundreds of times as I developed the package for Synology NAS.

However, now that I am close to release-ready, when testing a fresh installation of the very same sane-backends 1.0.28 (with libusb 1.0.23 since the system has a pre-v1.0 version) airsaned would not start:

enumerating local devices...
sane_init(nullptr, nullptr)
Segmentation fault (core dumped)

Oddly, it would start if sane was removed from the inetd config. This is the same system I have used since the start, and the only difference I can find is that now the list of enabled backends is back to the very inclusive default state.

AirSane returns to a reliable working state once all the unwanted backends are commented out from etc/sane.d/dll.conf.

Trying again several times I find that sometimes it works fine despite all the backends remaining enabled. In summary then it appears to be inconsistent with all backends enabled, and reliable when most of them are commented out. I notice that your README recommends to comment out unused ones, so is there a timeout issue in airsaned perhaps during device detection? Ideally I want this to be a package that requires no manual configuration, so most users will in fact have the default inclusive list.

sane-find-scanner -q and scanimage -L worked fine throughout - and presumably AirSane's device enumeration will be using those same sane library functions so I think it's unlikely the cause of the issue lies with sane-backends.

Any ideas?

@patters-syno patters-syno changed the title AirSane inconsistently segfaults on init with the default list of backends enabled AirSane inconsistently segfaults on init with the default list of backends enabled in dll.conf Sep 11, 2019
@SimulPiscator

This comment has been minimized.

Copy link
Owner

commented Sep 12, 2019

Oddly, it would start if sane was removed from the inetd config.
So could it be related to the net backend being enabled? This would be quite strange though, as the net backend should be excluded when scanning for local devices, as airsaned does.

I notice that your README recommends to comment out unused ones, so is there a timeout issue in airsaned perhaps during device detection?
No, the recommendation is there to minimize downtime when adding or removing USB devices, as airsaned will re-run the device scan then.

Unfortunately, I was unable to reproduce the issue on a Debian Stretch system in a virtual machine. Do you think you could try to narrow down the issue to a particular backend by binary exclusion?

@patters-syno

This comment has been minimized.

Copy link
Author

commented Sep 12, 2019

I can try. The main ask was to determine if there was a technical reason you recommended excluding unused backends, but from your answer I guess not. I'm not familiar with debugging but would the core dump be in any way useful for you? Or is it a case that you would need to write a lot more error handling code?

@SimulPiscator

This comment has been minimized.

Copy link
Owner

commented Sep 13, 2019

The segfault happens during or immediately after searching for devices. I improved logging so we can see whether it's during or after. Could you give it a try with the current version in my repo? Thank you so much.

@patters-syno

This comment has been minimized.

Copy link
Author

commented Sep 13, 2019

root@NAS:/volume1/public# /var/packages/AirSane/target/bin/airsaned --debug=true
enumerating local devices...
sane_init(nullptr, nullptr)
sane_get_devices() ...
... sane_get_devices() -> SANE_Status Success
sane_exit()
found: plustek:libusb:001:005 (Canon CanoScan N670U/N676U/LiDE20)
sane_init(nullptr, nullptr)
sane_open(plustek:libusb:001:005) -> 0xb5e008a8
sane_close(0xb5e008a8)
sane_exit()
uuid: 705c14c7-033d-5ec3-a814-2f44454d30aa
published as 'Canon CanoScan N670U/N676U/LiDE20'
listening on 127.0.0.1:8090
listening on 192.168.xxx.xxx:8090
listening on ::1:8090
listening on xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:8090
listening on xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:8090
listening on xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:8090
^C
root@NAS:/volume1/public# /var/packages/AirSane/target/bin/airsaned --debug=true
enumerating local devices...
sane_init(nullptr, nullptr)
sane_get_devices() ...
Segmentation fault (core dumped)
root@DS214play:/volume1/public#

Does this mean it's out of your hands?

@SimulPiscator

This comment has been minimized.

Copy link
Owner

commented Sep 13, 2019

Right, it's out of my hands. Chances are that one of the sane backends has a bug that is triggered by something on the airsaned side. By disabling either half of the backends, one could try which half displays the bug, then again disable either half of that part, etc. If it is not too cumbersome for you, a small number of halving steps can narrow down which backend is to blame.

@patters-syno

This comment has been minimized.

Copy link
Author

commented Sep 13, 2019

There really doesn't seem much of a pattern to it unfortunately. I did just randomly get this though:

enumerating local devices...
sane_init(nullptr, nullptr)
sane_get_devices() ...
process 14875: arguments to dbus_message_unref() were incorrect, assertion "message->generation == _dbus_current_generation" failed in file dbus-message.c line 1618.
This is normally a bug in some application using the D-Bus library.
  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)

I'll try compiling SANE without avahi (which will remove the dbus dependency I think).

@patters-syno

This comment has been minimized.

Copy link
Author

commented Sep 13, 2019

Yes that does seems to have fixed the stability issues. So a workaround more than a fix, but saned can't use avahi when invoked by inetd in any case, so no great loss in my use case.
In order to avoid having to build the whole dependency chain I was linking to the system's existing libavahi and libdbus versions. I suppose they could be somewhat outdated. Seems to work fine for AirSane though.

@SimulPiscator

This comment has been minimized.

Copy link
Owner

commented Sep 13, 2019

Great work, thank you!
Seems there is nothing we can do about it, except for disabling saned, right?

@patters-syno

This comment has been minimized.

Copy link
Author

commented Sep 13, 2019

saned can run (and the issue goes away) when it's compiled without avahi support. It's no loss in my use case since most front ends need to statically bound to the specific USB bus ID of the backend and when that changes the front end usually has to be reconfigured anyway, so avahi doesn't really add any utility for SANE by itself. That's why AirSane is so great - it removes all that configuration complexity.

So now I'm ready to release. Just got to build the binaries for each architecture. Done 2/7...

@SimulPiscator

This comment has been minimized.

Copy link
Owner

commented Sep 14, 2019

I'll close the issue then. Thanks again for all your help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.