Avahi query in CUPS 2.5.x does not work

[tillkamppeter]

Describe the bug
I have several IPP print destinations which are advertised via DNS-SD (Avahi):

$ driverless
ipp://HP%20OfficeJet%20Pro%208730%20%5B5B78A3%5D%20(USB)._ipp._tcp.local/
ipps://Canon._ipps._tcp.local/
ipps://HP%20OfficeJet%20Pro%208730%20%5B5B78A3%5D._ipps._tcp.local/
ipps://abc._ipps._tcp.local/
ipps://dnssd._ipps._tcp.local/
ipps://hostname._ipps._tcp.local/
ipps://hp4050._ipps._tcp.local/
ipps://psc2500%20(E313F0)._ipps._tcp.local/
ipps://snmp._ipps._tcp.local/
ipps://test._ipps._tcp.local/
ipps://test-query._ipps._tcp.local/
ipps://test10%20(D7FE90)._ipps._tcp.local/
ipps://test2%20(460BFB)._ipps._tcp.local/
ipps://test3%20(CN783F60W1&interface=1)._ipps._tcp.local/
ipps://test4%20(F7866E)._ipps._tcp.local/
ipps://test5%20(9EA687)._ipps._tcp.local/
ipps://test6%20(59CD60)._ipps._tcp.local/
ipps://usb._ipps._tcp.local/
ipps://utax._ipps._tcp.local/
ipps://x._ipps._tcp.local/
ipps://xyz123._ipps._tcp.local/
$
$ driverless --std-ipp-uris
ipp://HP489EBD5B78A3.local/ipp/print
ipp://till-x1nano.local:60000/ipp/print
ipps://HP489EBD5B78A3.local:443/ipp/print
ipps://till-x1nano.local:8002/ipp/print/Canon
ipps://till-x1nano.local:8003/ipp/print/abc
ipps://till-x1nano.local:8003/ipp/print/dnssd
ipps://till-x1nano.local:8003/ipp/print/hostname
ipps://till-x1nano.local:8003/ipp/print/hp4050
ipps://till-x1nano.local:8004/ipp/print/psc2500
ipps://till-x1nano.local:8003/ipp/print/snmp
ipps://till-x1nano.local:8002/ipp/print/test
ipps://till-x1nano.local:8001/ipp/print/test-query
ipps://till-x1nano.local:8002/ipp/print/test10
ipps://till-x1nano.local:8002/ipp/print/test2
ipps://till-x1nano.local:8002/ipp/print/test3
ipps://till-x1nano.local:8002/ipp/print/test4
ipps://till-x1nano.local:8002/ipp/print/test5
ipps://till-x1nano.local:8002/ipp/print/test6
ipps://till-x1nano.local:8003/ipp/print/usb
ipps://till-x1nano.local:8001/ipp/print/utax
ipps://till-x1nano.local:8003/ipp/print/x
ipps://till-x1nano.local:8001/ipp/print/xyz123
$

These are 21 destinations, an HP OfficeJet Pro 8730, connected both via network and via USB (IPP-over-USB, via ipp-usb) and several PAPPL-based Printer Applications.

I have also some classic, permanent CUPS queues with PPD files:

$ lpstat -v
device for Printer: ipps://HP%20OfficeJet%20Pro%208730%20%5B5B78A3%5D._ipps._tcp.local/
device for PrinterVV: ipps://HP14CB19D68D1E.local:631/ipp/print
device for testprinter: /tmp/printout
$

If I run the command lpstst -l -e on CUPS 2.4.7 as it comes with Ubuntu 24.04 LTS I get a list of the 3 permanent queues , as "permanent" and the 21 IPP destinations, as "network" or "temporary", so a total of 24 entries. CUPS 2.5.x (GIT master) gives me only the 3 permanent queues as output of lpstat -l -e. This is not a problem of the timeout (_CUPS_DNSSD_GET_DESTS in cups/dest.c). It is already on 1 sec in 2.5.x and I also tried 5 sec.

I have build 2.5.x with

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-tls=gnutls --enable-debug-printfs

and run lpstat -l -e with extra debug output:

CUPS_DEBUG_LOG=log.txt CUPS_DEBUG_LEVEL=99 lpstat -l -e

The debug log log.txt shows that for each of the 21 IPP print destinations a DNS-SD query with the CUPS DNS-SD API function cupsDNSSDQueryNew() was done. The function is asynchronous and so in a loop it is waited for the result, until the timeout expires. The debug log makes the impression, that the queries get never answered, so probably the initial formulation of the queries has some problem. The callback function cups_dest_query_cb() gets never called.

The problem seems only concern queries, as ippfind of CUPS 2.5.x (and the driverless used above calls ippfind, just with a search command line to only display driverless IPP printers) works. It does not use the query API functions, but functions for browsing and resolving.

To Reproduce
Steps to reproduce the behavior:

1. Make sure to have a driverless IPP print destination (network printer, Printer Application, ...) If not, use the simple test Printer Application ippeveprinter. There should be at least one driverless IPP print which is not covered by a permanent CUPS queue. Make sure cups-browsed is NOT running.
2. Create a permanent CUPS queue which does not point to your iPP print destination(s).
3. Check with driverless and lpstat -v whether everything needed is there.
4. Run lpstat -l -e. Only your permanent queue(s) is/are shown, not your driverless IPP print destinations.
5. With CUPS 2.4.7 lpstat -l -e shows everything, permanent queues AND IPP print destinations.

System Information:

• Ubuntu 24.04 LTS
• CUPS version 2.5.x (GIT master)

[tillkamppeter]

Debug log of lpstat as mentioned above:
log.txt

[michaelrsweet]

TIll, can you try with current CUPS master? There were some Avahi-related issues that I think I have resolved now...

[tillkamppeter]

I tried now, being on Ubuntu 24.04 LTS at the time of release. Rebuilt CUPS 2.5.x from GIT master:

make distclean
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-tls=gnutls --enable-debug-printfs
make
make install

Checked whether libcups is at the right place and actually used by the components (ldd). driverless still gives the shown 21 lines. cups-browsed is not running.

lpstat -v and lpstat -l -e both segfault, starting cpdb-text-frontend results in the CPDB backend for CUPS segfaulting.

Checked both lpstat and the CPDB backend for CUPS with gdb. Both show the same backtrace:

(gdb) bt
#0  __strcmp_evex () at ../sysdeps/x86_64/multiarch/strcmp-evex.S:314
#1  0x00007ffff7a39420 in avahi_record_browser_event ()
    at /lib/x86_64-linux-gnu/libavahi-client.so.3
#2  0x00007ffff7a35299 in ??? () at /lib/x86_64-linux-gnu/libavahi-client.so.3
#3  0x00007ffff6fc91b9 in dbus_connection_dispatch ()
    at /lib/x86_64-linux-gnu/libdbus-1.so.3
#4  0x00007ffff7a3bd8b in ??? () at /lib/x86_64-linux-gnu/libavahi-client.so.3
#5  0x00007ffff7a49e40 in avahi_simple_poll_dispatch ()
    at /lib/x86_64-linux-gnu/libavahi-common.so.3
#6  0x00007ffff7a4a145 in avahi_simple_poll_loop ()
    at /lib/x86_64-linux-gnu/libavahi-common.so.3
#7  0x00007ffff7f13f7f in avahi_monitor (dnssd=0x5555556021f0) at dnssd.c:2252
#8  0x00007ffff789ca94 in start_thread (arg=<optimized out>)
    at ./nptl/pthread_create.c:447
#9  0x00007ffff7929c3c in clone3 ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb)

So the call of avahi_simple_poll_loop() in the function avahi_monitor() of cups/dnssd.c leads to a segfault. I have gotten this after several attempts, I always get this segfault.

So I ran:

$ export CUPS_DEBUG_LOG=/tmp/log.txt
$ export CUPS_DEBUG_LEVEL=99
$ lpstat -l -e
Segmentation fault (core dumped)
$

and I am attaching the file /tmp/log.txt.
log.txt

[michaelrsweet]

I can reproduce when I run outside the debugger, but not in the debugger... :/

Trying to get a better sense of what is happening from the logs...

[michaelrsweet]

OK, re-enabling core dumps and debuginfod got me a little farther. It looks like Avahi isn't initializing the "path" variable in the browser object. Digging deeper...

[michaelrsweet]

So running this code on ARM doesn't crash, Intel does...

[michaelrsweet]

Till, try the latest changes I've pushed:

[master a1d9852] Fix threading and callback issues with Avahi (Issue #936)

There were a couple issues with missing locking around the creation of new browsers and the flags that were being passed to the callback functions... Seems to be working as expected now.

[michaelrsweet]

Also: [master 0cb7215] More Avahi changes to fix threading issues (Issue #936)

[tillkamppeter]

I have tested it now again, current GIT with the mentioned 2 commits and all is working as expected. No crashes and the bug I originally had reported is fixed. So this one is done.