Am 21.09.21 um 18:36 schrieb Florence Birée:
Hi,
I applied the patch and try it on hplip 3.21.6+dfsg0-1.
No more stack smashing. But at a random point during the scan,
simple-scan stop and display a message : « Failed to scan - Error
communicating with scanner ».
Nothing in the terminal nor in
regards,
Bernhard
Description: Resize buffer and try not to overrun it
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/992721
Forwarded: no
Last-Update: 2021-09-20
Index: hplip-3.21.6+dfsg0/scan/sane/bb_ledm.c
Am 16.09.21 um 00:29 schrieb Bernhard Übelacker:
exceeds what
is with these 7 places possible (would be 268 MB ?)
Short correction:
6 bytes for the hex number and 1 byte termination.
Would just give something around 16 MB as a maximum?
Kind regards,
Bernhard
Hello Florence, dear Maintainer,
Stack trace of thread 113079:
#0 0x7f858b12ae71 raise
(libc.so.6 + 0x3ce71)
Hello Florence,
there might be still something that could be done
to retrieve some more information (if you have still
the versions installed that show the issue).
The easiest first thing might be to install the package
systemd-coredump, if possible.
Then open in another terminal 'journalctl -f'
Am 31.05.21 um 21:49 schrieb Adrian Bunk:
#975977 comes into my mind as a similar bug in a different package.
Unfortunately in this bug it was possible to do a side by side
debugging, that way the exact instruction could be identified,
and the relation to the alignment was found.
But with gho
Hello Guilhem, hello Jonas,
might this be a similar or the same issue as in #942055 ?
I took the example file from this issue,
created an armel buster chroot and ran it once at my arm5tel device,
and once at a armv7l cpu android device (unfortunately with
a non-debian kernel).
- with the arm5tel
Hello Didier,
I have retried with the patch in #974828, but it still
crashed with the test files from this bug, therefore
I guess #974828 is similar but unrelated.
Then I took another look at the valgrind runs and found
that these invalid reads and writes also appear at amd64.
After some diggin
Hello Ian,
Am 27.02.21 um 08:49 schrieb Ian Campbell:
On Fri, 2021-02-26 at 15:41 +0100, Bernhard Übelacker wrote:
The attached patch is an attempt to grow the buffer size
if the header changes on a new page.
This is just tested for the given crash, nothing more, therefore
there might be side
argv=0x7ffc2a13fd48) at prnt/hpcups/HPCupsFilter.cpp:617
...
Description: Grow m_pPrinterBuffer if needed on each page
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/974828
Bug-Ubuntu: https://launchpad.net/bugs/1904318
Last-Update: 2021-02-26
In
Sorry missed your email.
Weitergeleitete Nachricht
Betreff: Re: Bug#974828: printer-driver-hpcups: SIGABRT with "free():
invalid next size (normal)" in HPCupsFilter::cleanup
Datum: Thu, 25 Feb 2021 17:03:02 +0100
Von: Bernhard Übelacker
An: 974...@bugs.debian.or
Hello Ian,
I tried to collect some informations for the
maintainer in the other report #972339.
Therefore I tried to reproduce this issue now too, because
my amd64 hardware is much faster as my armhf systems...
But I failed to reproduce maybe because I use the wrong ppd file,
or something else mi
Dear Maintainer,
I could reproduce this issue too.
Attached is a valgrind run showing one invalid write
and a gdb session showing the issue.
It looks like mallocs management data, which resides in the 8 bytes
before a returned pointer, gets overwritten and therefore
the free fails because "mchunk
Dear Maintainer,
tried to have a look at this one, found the segfault [1],
and can point to the place where the pointer gets overwritten [2].
Unfortunately Valgrind or ASAN gave me not more details.
Kind regards,
Bernhard
[1]
Program received signal SIGSEGV, Segmentation fault.
0x7fa54364fc1
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.
>
>
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 samba-prn-01.graysofwestmins
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,
Bernha
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 se
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 v
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 0x5F44D23F
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 +# Ex
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
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?
A
Hello Karsten,
Am 21.08.20 um 18:21 schrieb Karsten:
>> Unfortunately I did not get the message
>> "Gesamte Anfrage zu gross" / "Request Entity Too Large".
>
> Hmmm - there are many details not working in Debian 10.
> Maybe because this version has been upgraded.
>From which debian version did
Hello Karsten,
I am no involved in the packaging cups but I tried to
reproduce your cups issue inside a minimal VM.
Unfortunately I did not get the message
"Gesamte Anfrage zu gross" / "Request Entity Too Large".
Therefore it seems you need to supply some more informations like
- with which user
Dear Maintainer,
after additionally re-reading the merged bugs I think I
realized that function IsChromeOs searches the line "NAME=...",
but finds the line "PRETTY_NAME=...",
which overflows the variable os_name.
Kind regards,
Bernhard
Dear Maintainer,
I was able to reproduce this issue, kind of.
I guess the debian release name stored in /etc/os-release is too long.
Therefore in /usr/lib/cups/filter/hpcups in function IsChromeOs
the local array os_name with length 30 is overwritten by 1 byte.
At least that issue I received whe
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 regar
Sorry, the file I attached in message #10 was for a
different bug, unrelated to this one.
Created upstream bug: https://bugs.ghostscript.com/show_bug.cgi?id=702346
Dear Maintainer,
I tried to collect some more information and might have found something.
The allocator aborts at the backtrace below.
A valgrind run points to the same function txt_add_fragment.
There is seems that in line 2121 the allocation takes place with
12 bytes total, then a memset is do
Hello Till,
I am not the initial reporter of the issue and I cannot reproduce it,
therefore cannot test the suggested change.
Just tried to share my results.
Kind regards,
Bernhard
Hello,
the stack trace should look like this with line numbers, if it helps:
0x7...671 in __strlen_avx2 at
../sysdeps/x86_64/multiarch/strlen-avx2.S:65
0x7...2f4 in _cups_strlcpy at string.c:739
0x5...a31 in main at rastertopwg.c:274
0x7...e09 in __libc_start_main
Package: cups
Version: 2.2.10-6+deb10u2
Severity: normal
Dear Maintainer,
I found today some suspicious segfault line in dmesg output and
could reproduce it every time I loaded the finished jobs of a printer
with this URL:
http://localhost:631/printers/Samsung_CLX-3180_Series?which_jobs=co
Hello Thorsten,
Am 06.02.20 um 19:19 schrieb Thorsten Glaser:
> On Thu, 6 Feb 2020, Bernhard Übelacker wrote:
>
>> Hello Thorsten,
>> getting the source of such an address is possible, even with ASLR,
>> if the library versions are known and dbgsyms are available,
Hello Thorsten,
getting the source of such an address is possible, even with ASLR,
if the library versions are known and dbgsyms are available,
like in attached file.
It looks like a null pointer is given to strncasecmp_l.
But you are right, this information might still not be very useful,
becaus
Hello Jonas,
thanks for taking time for this bug.
Am 05.02.20 um 11:02 schrieb Jonas Smedegaard:
> Hi Alexander,
>
> Quoting Alexander Reichle-Schmehl (2020-02-05 08:45:05)
>> Am 2020-02-04 22:09, schrieb Jonas Smedegaard:
>>
>>> Most notable change between 9.22 and 9.24 - and also applied to
>
Control: fixed -1 9.26a~dfsg-0+deb9u6
Control: fixed -1 9.26a~dfsg-0+deb9u1
Control: fixed -1 9.25~dfsg-0+deb9u1
Control: found -1 9.27~dfsg-3.1
Control: found -1 9.27~dfsg-3
Control: found -1 9.26a~dfsg-2
Control: found -1 9.26a~dfsg-1
Control: found -1 9.26~dfsg-2
Control: found -1 9.26~dfsg-1
Co
Hello Jeffrey Hundstad,
your supplied backtrace would most likely look with debug symbols like this:
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:79
#1 0x77dcbdae in __GI___strdup () at strdup.c:41
#2 0xb795 in cgiGetArray () at var.c:171
#3 0x000
Hello Jeffrey Hundstad,
sorry, I forget to mention that it would help with the
backtrace if the debug symbols would be installed.
For jobs.cgi I assume this would be cups-dbgsym.
These packages are in a separate repository.
Details are about it are in this page:
https://wiki.debian.org/HowToGetAB
Hello Jeffrey Hundstad,
just looking at some crashes in some random packages,
I just tried to reproduce this issue inside a minimal qemu VM.
But hit just the line "Couldn't open...", not the segfault.
Also with a simple test printer configured and a test page job.
If it is possible you could insta
Hello Brian Potkin,
you might have a look at following commands to build a
complete local cups-browsed package with the upstream
patch included.
That may work better, as a plain make built shared lib
might be not enough compatible with the executable from
the debian package.
Just if you do not wa
Hello Brian Potkin,
> You got exactly what I was shown.
You are right, and I just wanted to make a point how someone
who want to help can start right away with all the needed information.
> Do you really think reportbug would have added an imortant clue? It
> was clear that my original report wa
Control: found cups-browsed 1.11.6-3
And probably I was not clear in my message #36:
- I may have found something that could lead to your sitation,
and attached a change that might avoid it.
- I could not reproduce the crash because I do not have such printers.
- Maintainer or Upstream are need
Hello Brian Potkin,
> Does the efficient and correct operation of a program depend on whether
> the system is amd64 or i386? Most of my machines are i386 only and, to
> my knowledge, Debian has not abandoned this architecture.
>
> I was probably incorrect in thinking I had tested the offending di
Dear Maintainer, hello Brian Potkin,
> Thanks. All this is very new to me. I hope it is what is needed and
>
> someone can interpret it!
Thanks for the information, in my first attempts I was under the impression
you are on a amd64 system becau
Hello Brian Potkin,
I tried to have a look in a unstable VM, but unfortunately
I get different offsets ...
You might add the output of this command:
dpkg -l | grep -E "cups-browsed|libc6|libglib|libavahi|libdbus" | sort
And what output did you receive from this command
coredumpctl list
and f
Hello Brian Potkin,
you might want to install a core dump collector like systemd-coredump.
With that in place you might get a more verbose message in journalctl.
Also a later inspection of the coredump might be possible:
coredumpctl list
coredumpctl gdb [PID]
bt
quit
And even better when hav
Hello,
was not sure what to test also.
At least these steps led me to a crashing cups-browsed:
- Rebuilt cups-browsed and installed to know the issue remains in the rebuilt
package:
dpkg-buildpackage -b
dpkg -i cups-browsed_1.21.1-1_amd64.deb
cups-browsed-dbgsym_1.21.1-1_amd64.deb libcu
Hello,
just a short addition.
Attached patch might already be enough to fix this issue.
It makes DomainSocket gets assigned a copy of the string literal.
That copy should be possible to free later.
This patch is untested except the package can be built.
Kind regards,
Bernhard
Description: Avoid
Hello,
I had a closer look to the core dump.
The backtrace shows as follows:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x7fd5463d62f1 in __GI_abort () at abort.c:79
#2 0x7fd546417867 in __libc_message (action=action@entry=do_abo
Hello Francois Marier,
you could try to get more information from that crash
by installing the package systemd-coredump.
When the next crash happened you might call following:
$ coredumpctl gdb
Probably with the following debug symbol package installed [1]:
cups-browsed-dbgsym
Kind regards
Hello Michelle Konzack,
not being maintainer I was just curious about
this problem, so I tried to reproduce ...
- Installed a amd64 Wheezy VM
- Inside installed cups-pdf printer.
- Changed in /etc/cups/cupsd.conf from "LogLevel warn" to "LogLevel debug"
Then following commands led not to the same
52 matches
Mail list logo
