Closed tillkamppeter closed 1 month ago
Debug log of lpstat
as mentioned above:
log.txt
TIll, can you try with current CUPS master? There were some Avahi-related issues that I think I have resolved now...
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
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...
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...
So running this code on ARM doesn't crash, Intel does...
Till, try the latest changes I've pushed:
[master a1d98525c] 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.
Also: [master 0cb721585] More Avahi changes to fix threading issues (Issue #936)
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.
Describe the bug I have several IPP print destinations which are advertised via DNS-SD (Avahi):
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:
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 oflpstat -l -e
. This is not a problem of the timeout (_CUPS_DNSSD_GET_DESTS
incups/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
and run
lpstat -l -e
with extra debug output: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 functioncupsDNSSDQueryNew()
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 functioncups_dest_query_cb()
gets never called.The problem seems only concern queries, as
ippfind
of CUPS 2.5.x (and thedriverless
used above callsippfind
, 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:
ippeveprinter
. There should be at least one driverless IPP print which is not covered by a permanent CUPS queue. Make surecups-browsed
is NOT running.driverless
andlpstat -v
whether everything needed is there.lpstat -l -e
. Only your permanent queue(s) is/are shown, not your driverless IPP print destinations.lpstat -l -e
shows everything, permanent queues AND IPP print destinations.System Information: