Bernhard Übelacker wrote on 03/09/2020 13:42:
>
> that's great, I have opened an issue upstream, let's see what they
> think.
Thanks. I'll monitor the issue.
Ronny
--
Ronny Adsetts
Technical Director
Amazing Internet Ltd, London
t: +44 20 8977 8943
w: www.amazinginternet.com
Registered
Am 02.09.20 um 10:20 schrieb Ronny Adsetts:
> Hi Bernhard,
>
> Good news. I don't see any "invalid free" reports.
>
> Can I thank you again for your time and energy in solving this. It really is
> appreciated.
>
> Let me know if there's anything I can do to help get this patch upstreamed.
>
Hi Bernhard,
Bernhard Übelacker wrote on 01/09/2020 17:55:
[...]
>> So running with the patched cups packages seems to fix the "invalid
>> free" on a test print. I've restored the systemd service file to
>> remove valgrind so let's see how we go on a day's printing. :-).
>
> Any news in this
Hello Ronny,
> Incidentally, stopping the cups service (new packages) after a single print
> job when under valgrind gave this in case it's related:
>
> Aug 28 10:03:59 samba-prn-01.graysofwestminster.co.uk systemd[1]: Stopping
> CUPS Scheduler...
> Aug 28 10:04:00
Bernhard Übelacker wrote on 26/08/2020 23:10:
>
> I tried to have a look and I get the feeling that there is a
> disagreement if the attribute "printer-alert" is of type IPP_TAG_TEXT
> or IPP_TAG_STRING.
>
> Also it is the only line I found at a glance that calls ippAddString
> with a
Bernhard Übelacker wrote on 27/08/2020 12:00:
> unfortunately I don't have any pointers on that httpAddrGetList.
>
> So you were able to build a package?
Yes, I patched out the fail (typo included for free):
Index: cups-2.3.3/cups/testhttp.c
Hello Ronny,
unfortunately I don't have any pointers on that httpAddrGetList.
So you were able to build a package?
One additional note: I guess with "quilt refresh" any new changes
get added to the last patch. A 'dpkg-source --commit' would create
a new separate patch file.
Kind regards,
Bernhard Übelacker wrote on 26/08/2020 23:10:
[...]
>
> Below patch is an attempt to add "printer-alert" in
> copy_printer_attrs by using ippAddOctetString.
>
> The important change is in scheduler/ipp.c, the changes to
> backend/ipp.c should just mark another questionable place.
>
> I could
Hello Ronny,
I tried to have a look and I get the feeling that there
is a disagreement if the attribute "printer-alert" is of type
IPP_TAG_TEXT or IPP_TAG_STRING.
Also it is the only line I found at a glance that calls
ippAddString with a IPP_TAG_STRING.
Other attributes of type IPP_TAG_STRING
Bernhard Übelacker wrote on 25/08/2020 22:07:
> Am 25.08.20 um 14:40 schrieb Ronny Adsetts:
>> In which case a backport of valgrind would be dead handy. :-).
>
> You might be able to build one yourself:
> (maybe inside a VM too, because several build dependencies get installed ...)
[...]
Thanks.
Am 25.08.20 um 14:40 schrieb Ronny Adsetts:
> In which case a backport of valgrind would be dead handy. :-).
You might be able to build one yourself:
(maybe inside a VM too, because several build dependencies get installed ...)
# Buster/stable amd64 qemu VM 2020-08-25
apt update
apt build-dep
Bernhard Übelacker wrote on 25/08/2020 11:50:
> Am 25.08.20 um 11:02 schrieb Ronny Adsetts:
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x13076D: ???
>> (in /usr/sbin/cupsd)
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5AC5261: ???
>> Aug 25 09:56:32
Bernhard Übelacker wrote on 25/08/2020 11:50:
> Am 25.08.20 um 11:02 schrieb Ronny Adsetts:
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x13076D: ???
>> (in /usr/sbin/cupsd)
>> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5AC5261: ???
>> Aug 25 09:56:32
Am 25.08.20 um 11:02 schrieb Ronny Adsetts:
> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x13076D: ???
> (in /usr/sbin/cupsd)
> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by 0x5AC5261: ???
> Aug 25 09:56:32 samba-prn-01 valgrind[28088]: ==28088==by
Bernhard Übelacker wrote on 25/08/2020 09:34:
>
> Adding the line above would just appear in 'journalctl -e -u cups.service'.
> Otherwise one could add the option '--log-file=/tmp/valgrind' to redirect
> and separate the additional output of valgrind.
>
> I have also not yet run valgrind that
Hello Ronny
Am 25.08.20 um 10:14 schrieb Ronny Adsetts:
>> I tried to run it in a VM and tested with some virtual PDF and PS
>> printer. Following were the configuration changes to have it run
>> under valgrind.
>>
>> nano /lib/systemd/system/cups.service
>>
>> -ExecStart=/usr/sbin/cupsd -l +#
Morning Bernard,
Bernhard Übelacker wrote on 25/08/2020 02:18:
> Am 24.08.20 um 13:12 schrieb Ronny Adsetts:
>>> Otherwise running cupsd within valgrind could also give some
>>> hints.
>>
>> I'll see if I can do this. I'll have to schedule some down time so
>> it won't be immediate (or possibly
Hello Ronny,
Am 24.08.20 um 13:12 schrieb Ronny Adsetts:
> The "bt full" on a recent crash:
Unfortunately I cannot find something striking.
>> Otherwise running cupsd within valgrind could also give some hints.
>
> I'll see if I can do this. I'll have to schedule some down time so it won't
Bernhard Übelacker wrote on 22/08/2020 13:33:
>
> sorry for the delay.
No problem at all.
> You wrote you recompiled - then I guess your build directory should
> also contain the libcups2-dbgsym and cups-daemon-dbgsym packages.
Yes. I'd already installed libcups2-dbgsym. I've now installed
Hello Ronny,
sorry for the delay.
You wrote you recompiled - then I guess your build directory should
also contain the libcups2-dbgsym and cups-daemon-dbgsym packages.
If you still get this crash, could you install these dbgsym packages
from your build and recreate that backtrace in coredumpctl?
Package: cups
Version: 2.3.3-1~bpo10+1
Followup-For: Bug #961345
Dear Maintainer,
I'm running the Testing version of cups recompiled for Buster. I'm seeing the
same "invalid pointer" issue as the reporter.
Backtrace for a coredump is below. Please let me know if there's any other
information I
Hello Peter,
I am not involved in packaging cups, just trying to help
to collect some information.
If possible you could install the package systemd-coredump.
Then in the journal might then appear additional information
where the problem occoured, that could help identifying the issue.
Kind
Package: cups
Version: 2.2.10-6+deb10u3
Severity: normal
After upgrading to Debian 10, the CUPS daemon keeps crashing when I try to
print. This did not happen with the version in Debian 9.
$ journalctl -u cups
-- Logs begin at Thu 2020-05-21 14:59:37 CET, end at Sat 2020-05-23 14:52:11
CET. --
23 matches
Mail list logo
