Dear Maintainer,
I tried to reproduce the issue and got a segfault [2]
when trying to vgremove inside a i386 qemu VM
with version lvm2 2.02.168-2.
Attached file contains the steps taken.
This upstream commit sounds related. [1]
Kind regards,
Bernhard
[1] lvmetad: fix segfault on i386
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
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
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
Index: hplip-3.20.11+dfsg0/prnt/
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
Control: fixed -1 vte2.91/0.62.1-1
Hello,
marking fixed as mentioned in message by submitter to upstream bug [1].
Kind regards,
Bernhard
[1] https://gitlab.gnome.org/GNOME/vte/-/issues/270#note_1037042
Am 14.02.21 um 11:37 schrieb Drew Parsons:
The dolfinx comments go on to say you might want to set 64 for
user-compilation on AVX-512 systems. Would that AVX comment apply to
your specific system?
Hello Drew,
my specific system is an amd64 kvm/qemu VM running at a AMD Ryzen 1700.
So as far
This flag is already in use, see https://salsa.debian.org/science-team/gmsh/-/
blob/master/debian/rules#L34
Hello everyone,
the ENABLE_SYSTEM_CONTRIB=1 seems not to be sufficient.
The build log shows this line:
-- Found Eigen
With this include given to c++:
Am 12.02.21 um 16:06 schrieb Drew Parsons:
That could be the mismatch, if gmsh used its own copy of eigen different
from 3.3.9. Alternatively if libdolfinx-dev was built against an older
version of eigen then it might make a discrepancy.
Dolfinx has just been updated in unstable. Bernhard,
Am 12.02.21 um 12:12 schrieb Drew Parsons:
Version mismatch could cause problems.
Bernhard, can you provide the versions of each of the packages you're
reporting on
(dolfinx, eigen3, gmsh) ?
Hello,
these are the versions I have used in this test VM.
Would it be possible that libgmsh should
Dear Maintainer,
I tried to have a look at this issue and I saw
that the allocation takes place inside libdolfinx_real.so.2019.2,
inside /usr/include/eigen3/Eigen/src/Core/util/Memory.h.
But the failing free is done in libgmsh.so.4.7,
which uses ./contrib/eigen/Eigen/src/Core/util/Memory.h.
Hello Hans,
great that it works.
So I suppose, we should and could safely close this bug.
This can be achieved by sending the
mail to 980103-d...@bugs.debian.org.
(I hope this is ok with smb4k maintainers.)
Best regards, thank you very much again and stay healthy!
Thank you, the same to
Hello Hans,
However, no icon. Smb4k is starting, then crashing. There is also no
process running which is named smb4k or similar.
Ah, ok, from the description I was under the impression the process is
running but not showing a window.
So what does it write to the konsole when started from
Hello Hans,
(please leave the bug address in the CC field
to add the information in the bug too.)
I did not mean in the taskbar, I meant the systemtray near the clock.
Please see the green marks in the picture below.
Kind regards,
Bernhard
Am 06.02.21 um 13:03 schrieb Hans:
Am Samstag,
Hello Hans,
I had also used smb4k some months/years ago, so I tried to start it now.
I also got no entry in the window list, but I got a symbol in the system
tray near the clock. It was kind of hidden as there are already plenty
icons I had to extend the system tray via the triangle (plasma
Package: qemu-system-x86
Version: 1:5.2+dfsg-3
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I was playing around with a qemu VM with a virtio vga to see
how far I could get with accelerated graphics inside a VM.
I was watching the VM via remote-viewer.
But on several
Dear Maintainer,
I am sorry but I missed the offset of 42 in the kernel output,
which shows 42 bytes before the crashing instruction marked with "< >".
The location where the crash happened would therefore
not be in line 351, instead it would be in 355.
0x00438186 <+102>: push 0x14(%ebp)
Dear Maintainer,
from the dmesg line from the submitter I think the crash happens
save_thumbnail_in_cache_thread in [1], between the calls to
cairo_image_surface_get_height and -width.
Tried to reach that function just showing some random PDF
but did not get there.
@Nicolas: I assume Simon
Am 15.12.20 um 23:00 schrieb Mack Stanley:
Dear Bernhard,
Thanks so much for your interest and your message. I very recently
realized that my bug report is in error and hoped that I would be able
to correct or withdraw it before troubling anyone.
Here is how to reproduce the segfault I
Hello Peter,
Am 16.12.20 um 11:08 schrieb Peter Palfrader:
Hi Bernhard!
Can you try to rebuild tor with __attribute__((aligned(8))) for the
keccak_state as suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44
and then let us know if the issue is still there?
I rebuilt
Hello Otto,
if you still can reproduce the segfault then it might
also be possible to install the package systemd-coredump.
That way a backtrace should show up in 'journalctl -e' giving
some more details of where the segfault happens.
This should get more informative if the fdupes-dbgsym gets
Dear Maintainer,
I tried to get a backtrace containing the source line
information from the core provided by the submitter.
It shows the backtrace below.
This backtrace leads to some upstream issues. Some
of them showing "proxy" being a null pointer.
In this case it shows 0x1 which seems causing
Dear Maintainer,
this crash shows the following backtrace
and leads to this upstream issue:
https://github.com/JoeDog/siege/issues/104
Kind regards,
Bernhard
(gdb) bt
#0 0x7f6066705b51 in __GI_getenv (name=name@entry=0x0) at getenv.c:39
#1 0x559b8b01a190 in evaluate
Dear Maintainer,
due to having in the backtrace the same offsets from function
nouveau_pushbuf_data, I assume this is similar to the bug #975990,
which is currently assigned to the xorg package and contains now
the line information I added with the help of the dbgsym packages.
Kind regards,
Dear Maintainer,
I tried to reconstruct the line number information with
the dbgsym packages from the backtrace provided by the submitter.
This points to the assert in this line of code: [1]
There are already some other references showing a similar assert below:
../nouveau/pushbuf.c:723:
Control: forcemerge 974826 975580
Dear Maintainer,
I just noticed this issue on some devices here too,
and found it leads to the same upstream as #974826 does.
So I hope it is ok to merge them.
As far as I see this error message path triggers the segfault
because "error" is a null pointer.
The
Hello Mack Stanley,
I am not involved in packaging a2ps, but I guess there are some more
information needed to even start investigating.
I tried several files in a VM to send to a2ps and I could
not observe a crash.
Therefore could you supply to this bug which command line is used
to trigger
Dear Maintainer,
I tried to have a look and could reproduce the crash.
As far as I see a virtual method is called through a shared library
boundary and somehow returns with a wrong value in the $sp register.
Therefore an instruction in memory without executable mapping is
tried to be executed,
Dear Maintainer,
I tried to collect some more information and compared this
situation on real hardware armv5tel with an armv7 and
it looks like in keccak_finalize the following instruction
stores different data to memory depending on the arm hardware:
0x005c4ac0 :f0 20 c4 e1 strd
Dear Maintainer,
the patches got accepted upstream hit now testing
with xserver-xorg-core 2:1.20.10-1.
I made a test similar to the initial attached file and
function addresses printed by gdb match now xservers backtrace.
Therefore I guess this bug can then be closed?
Kind regards,
Bernhard
Dear Maintainer,
I tried to have a look at this crash and could it reproduce it
inside a minimal testing amd64 VM.
A backtrace with full debug symbols in [1].
The crash itself happens because of a stack exhaustion, because in
_celt_autocorr a 2015 MB array should be constructed.
But this seems
Dear Maintainer,
this is a backtrace of the crash:
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x55a9f3c9e5d0 in set_current_wd (path=) at
../path.c:235
#2 0x55a9f3c906b7 in main (argc=1, argv=0x7fffa8fcd4b8) at
../main.c:196
It
Dear Maintainer,
I tried to have a look at the core file.
If a dbgsym package would be available I would be more
confident about the following information.
Please consider to build the dbgsym package.
The crash seems to happen in the stack below.
It seems the function mc_clear_window_simple
Hello Paul,
is it possible to install the package systemd-coredump on
the systems showing this crash?
Then after the next crash in the output of 'journalctl --no-pager'
should the segfault appear followed by a backtrace
that you could forward to this bug.
This should clarify which function
Hello Chris,
thanks for the pointers.
By enabling fixfilepath [1] the build it is automatically using
-ffile-prefix-map.
This seems also the case for the reproducible-builds.org results already [2].
Therefore I assume the compilation of the .c* files is already good.
And the -ffile-prefix-map
Am 07.11.20 um 11:00 schrieb Chris Lamb:
Hi Bernhard,
I guess attached patch would at least remove the embedded
build path from the files, which is mentioned in [2] too.
Thanks for working on this. Looking at your solution though, I believe
it implies that CFLAGS set by the dpkg-buildflags
/system)
LSM: AppArmor: enabled
Versions of packages rr depends on:
ii libc6 2.31-4
ii libc6-i386 2.31-4
ii libcapnp-0.7.0 0.7.0-7
ii libgcc-s1 10.2.0-16
ii libstdc++6 10.2.0-16
ii python3 3.8.2-3
Description: Remove embedded build paths
Author: Bernhard
Dear Maintainer,
I could reproduce this issue with version 2.26.20160125+Atmel3.6.2-1.
Program terminated with signal SIGILL, Illegal instruction.
#0 0xe70f20e8 in e843419@0011_0103_e2c ()
(gdb) bt
#0 0xe70f20e8 in e843419@0011_0103_e2c ()
#1
-core/src/gatb/tools/misc/impl/Tool.cpp:112
#13 0x00555bad97bc in main (argc=7, argv=0x7fd3195848) at
/usr/include/c++/10/ext/new_allocator.h:79
[2]
https://sources.debian.org/src/gatb-core/1.4.2+dfsg-5/gatb-core/src/gatb/system/impl/FileSystemCommon.hpp/#L103
Description: Use int as re
Dear Maintainer,
I just came across this report and want to note that since ASLR
got quite common the addr2line method is unreliable.
Therefore I want to point to here [1], were another method is
described to find out the source line where a crash happened.
Attached file contains this exercised
to %2520.
I guess upstream needs to have a look at this epub.
Kind regards,
Bernhard
Description: Avoid crash on certain epub files
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/972715
Forwarded: no
Last-Update: 2020-11-01
Index: atril-1.24.0/backend/epub/epub-document.c
Hello Ryutaroh Matsumoto,
I just tried to reproduce this and got such a "Bus error" while
running an armhf testing chroot on a physical armv7l system,
unfortunately not running a stock debian kernel, instead
a lineageos kernel.
Here the "Bus error" is given because of an stmib instruction
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux debian 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17)
x86_64 GNU/Linux
aces the use of long by CHRPOS in the places where
they cause the tests to fail. With it applied they succeed when
building at i386 and armhf with current testing.
Kind regards,
Bernhard
Description: Use a variable type that is 8 bytes in size on 32 bit systems too.
Author: Bernhard Übelacke
Dear Maintainer,
a short addition.
The backtrace that I received building with CC=gcc-10 seems
to be the same as in #972665, therefore they might be related?
Kind regards,
Bernhard
Dear Maintainer,
this issue seems to be reported upstream already.
There is also a workaround mentioned to modify a "Styli=@..." setting.
Kind regards,
Bernhard
https://github.com/linuxmint/cinnamon-control-center/issues/250
https://github.com/linuxmint/cinnamon-control-center/issues/245
Hello Karsten,
thanks for the information - that explains why my emulated pentium
failed already at 0x...6bb because not supporting sse at all.
>From wikipedia [1] the pminud instruction at 0x...6fb got
introduced with sse4.1 which seem not supported from your
flags line (while on the other side
Hello Karsten,
I tried to collect some more information for the maintainer and
could reproduce this (or nearly) the same SIGILL with a qemu VM limited
to a pentium class CPU.
The instruction in question might these below:
0xb78816bb <+75>:movd 0x4(%esi),%xmm2 (here I received the
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
Am 19.10.20 um 23:43 schrieb Adam Borowski:
> On Mon, Oct 19, 2020 at 10:52:45PM +0200, Bernhard Übelacker wrote:
>> Dear Maintainer,
>> tried to track where the time is set/retrieved for a remote file
>> and came up with this location [1].
>&g
Dear Maintainer,
tried to track where the time is set/retrieved for a remote file
and came up with this location [1].
I am not sure if flag SSH_FILEXFER_ATTR_ACMODTIME/SSH2_FILEXFER_ATTR_ACMODTIME
is the only possible way ssh has to transfer the date, but at
least that way seems to just use 32
Dear Maintainer,
could reproduce this inside a minimal amd64 qemu VM in current testing.
In my test Xorg consumed on CPU completely, another thread
xfce4/panel/wrapper-2.0
used 6% when this menu is opened.
It looked like this process triggers redrawing in a fast loop, which
seem most expensive
Dear Maintainer,
tried to reproduce but found pcmanfm not crashing.
Instead the process "just" exits without error or crash.
As we leave the main loop without error I tried setting a
breakpoint to g_main_loop_quit and it got hit multiple times.
I guess this last call to g_main_loop_quit is
Dear Maintainer,
I could reproduce it with the state of Debian testing at 2020-07-24.
Upstream bugs seem to be these:
https://bugs.kde.org/show_bug.cgi?id=407338
https://gitlab.freedesktop.org/poppler/poppler/-/issues/766
The issue seems to be resolved since poppler 0.77 and above.
Kind
not be queried.
Therefore and because the last upstream version is from 2006
one might ask if this package is really still useful?
(At least on amd64?)
Kind regards,
Bernhard
Description: Get number of CPUs
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/966638
Forwarded: no
Last
> #6 0x7f3e13f61730 in () at
> /lib/x86_64-linux-gnu/libpthread.so.0
> #7 0x7f3e1424ceba in g_type_check_value_holds () at
> /lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #8 0x7f3e142526f9 in g_value_get_int () at
> /lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #9
Dear Maintainer,
from the submitters attached log I guess
the part in [2] is relevant.
This led to the upstream bug in [1].
Downstream there seem to be also some duplicates:
#953880, #953854, #953794, #954095, #954739
This seems to be fixed in testing since gimp 2.10.14-3,
but due to this
rotating by zero degrees
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/971428
Forwarded: no
Last-Update: 2020-10-15
Index: xloadimage-4.1/options.c
===
--- xloadimage-4.1.orig/options.c
+++ xloadimage-4.1/options.c
, arg=arg@entry=0x7fffe380) at src/conf/conf.c:285
#8 0x5556d0c1 in module_init (conf=0x555ac760) at src/module.c:151
#9 0x55569950 in conf_modules () at src/conf.c:385
#10 0xf467 in main (argc=, argv=) at
src/main.c:242
Description: Use right size for ioctl
A
Hello Kevin,
I don't know the details, but I guess there will no automatic
rebuild of baresip triggered on migration.
As far as I see [1], the only users of libre0 are
baresip and librem0, so I guess both might need a rebuild.
Maybe someone with more shared library packaging knowledge
might give
Dear Maintainer,
I could reproduce the issue and it looks like there is a ABI break
of libre0 because the size of struct sip_addr has changed
from 152 bytes to 168, and therefore overwrites the stack canary here [1].
A baresip built agains libre0 1.1.0-1 did not show this problem.
Kind regards,
Dear Maintainer,
I could reproduce this crash and first lines of the backtrace
with full debug symbols shows like in [1],
while trying to dereference a null pointer.
This might be a use after free because when trying to reverse execute
to the point where the memory holding the null pointer is
Dear Maintainer,
tried to have a look at it and found that this might be caused by
the wine binary being pointed to by Debians alternatives system.
Therefore winedbg does not find the loader shared object of the target
process and cannot map it (elf_read_wine_loader_dbg_info).
That module would
Dear Maintainer,
I tried to track down the segfault and I guess it is related to
the usage of "-shared" when linking wminput [1].
Therefore, I guess, the resulting wminput binary is build like
a shared object instead of an executable.
A binary built without "-shared" shows a version info with
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.
Dear Maintainer,
I could reproduce this stack smashing inside a testing amd64 VM.
The stack canary gets overwritten in the stack below.
It looks like there is a disagreement of wesnoth and wolfssl in
the size of sha/hasher wc_Sha/WOLFSSL_SHA_CTX, the first allocates
112 bytes, the latter thinks
Hello John,
a short addition.
If you want to start it from a terminal I guess
following command might do what you want:
$ pkexec lightdm-settings
Kind regards,
Bernhard
Hello John,
I fear that the package gksu, which provided gksudo, is not
part of unstable, testing or buster.
https://packages.debian.org/stretch/gksu
Therefore I assume this package is installed since quite some time
and was then removed from debian.
Does starting it from the application
On Wed, 16 Sep 2020 10:16:49 +0200 SZALAY Attila wrote:
> Hi Jean-Marc,
>
> Please check if a core file is available related to the segmentation
> fault. If there is any please make it available for me/us.
>
> Also, can you run syslog-ng-debun with the -r parameter and send the
> generated
Hello Jörg,
just a suspicion, but the "trap" might
point to a intentional process exit.
Is there something interesting near that
trap line visible in "journalctl -e"?
Otherwise if you have a coredump handler
like e.g. systemd-coredump installed, these
trap line should trigger a core to be
More details here: https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html
Some related discussion here: https://lists.sr.ht/~sircmpwn/public-inbox
An upstream patch here:
https://git.sr.ht/~sircmpwn/scdoc/commit/26bbd972dd3bdc73baa9362a2794dfc3ec3ad085
Am 28.09.20 um 09:45 schrieb Michel Dänzer:
> Can you create an upstream merge request at
> https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests ?
Hello Michel,
thanks for looking at the issue.
I created this merge request:
Package: xserver-xorg-core
Version: 2:1.20.8-2
Severity: wishlist
Dear Maintainer,
in the past I was trying to make sense of some backtraces written
by Xorg, but failed, e.g. in #969739.
I did now some debugging and found that in function xorg_backtrace
the function begin retrieved by
Dear Maintainer,
I could not reproduce the crash, but I could modify the process under
gdb to reach a point of execution, which prints a similar backtrace.
Therefore I guess the crash described in Christophe's first message
is really located in [1], caused by "xf86_platform_devices[i].pdev"
On Tue, 8 Sep 2020 15:26:14 +0100 Claude Heiland-Allen
wrote:
> I resolved these problems with
> sudo apt install --reinstall libssl1.1
> no clue why/how it was damaged
> sorry for the noise
Hello Claude Heiland-Allen,
you might want to let a memory checker run
to exclude that as the source of
Hello Jason,
> #0 0x7efbfb5f3204 n/a (libgtk-3.so.0)
> #1 0x7efbfb779a53 n/a (libgtk-3.so.0)
> #2 0x7efbfb779b11 n/a (libgtk-3.so.0)
> #3 0x7efbfb779ff1 n/a (libgtk-3.so.0)
> #4 0x7efbf96c38ee ffi_call_unix64 (libffi.so.6)
> ...
I assume you updated inkscape to current
Dear Maintainer,
the issue reported in #950646 might be a similar or the same.
Kind regards,
Bernhard
Dear Maintainer, hello Bruce Momjian,
with the last informations the issue is perfectly reproducible.
It looks like a use after free caused by statically stored
function pointers in libengine-pkcs11-openssl / libp11.
That led to following upstream bug:
Control: fixed -1 1:2.26.0-1
Dear Maintainer,
I tried to have a look and found that it
showed the message: Error: can't read "::main_status": no such variable
But starting with version 1:2.26.0-1 I could not see
this message anymore.
Therefore I guess this bug could be closed?
Kind regards,
Hello Bruce Momjian,
thanks for the details and confirmation.
Am 05.09.20 um 17:32 schrieb Bruce Momjian,,,:
> (gdb) print pmeth->init
> $1 = (int (*)(EVP_PKEY_CTX *)) 0xf0e0d0c0b0a0908
> gdb) print *pmeth
> $8 = {pkey_id = 50462976, flags = 117835012, init =
Dear Maintainer,
I tried to reproduce this fault, but did not get a segfault.
However, I think the backtrace points to these lines:
(gdb) bt
#0 0x7769dbce in int_ctx_new () at ../crypto/evp/pmeth_lib.c:160
#1 0x7769dcfa in EVP_PKEY_CTX_new () at
Dear Maintainer,
this buffer is caused by a variable of length 256 being
snprintf'ed to with a length of 512.
This got fixed upstream in [1] and was also reported here [2].
This issue is visible in the build log [3] with this warning:
at proto_xboard.cc:1086:13:
... specified bound 512
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.
>
Package: kmix
Version: 4:20.08.0-1
Severity: normal
Forwarded: https://bugs.kde.org/show_bug.cgi?id=425469
Tags: upstream fixed-upstream
Dear Maintainer,
I found several kmix cores lately and investigated a bit.
It crashes when attempting to do some cleanup on process exit.
There unfortunately
Dear Maintainer,
the patch "949003_explicit_extern_declaration.patch" attached in [1],
should help against the exact issue this bug is about.
Kind regards,
Bernhard
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949003#35
7ffddbe504f8) at ./main.c:95
Description: 949003
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/949003
Forwarded: no
Last-Update: 2020-09-02
Index: slirp-1.0.17/src/options.c
===
--- slirp-1.0.17.orig/src/options.c
Hello,
searched the upstream issue tracker and found following,
that seems to match your situation.
https://gitlab.com/sane-project/backends/-/issues/275
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958074
Kind regards,
Bernhard
Hello Patrick,
I found another environment to increase verbosity
another little bit, please see below.
Your output points also into the direction of an permission
problem like what Stefan described in the first message.
The unit file starts the saned server with user and group saned.
On the
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
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,
Hello Patrick,
you might add in the sane unit file a backend specific
logging environment too. That should give much more details
for the plustek module.
Kind regards,
Bernhard
/lib/systemd/system/saned@.service:
Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255 SANE_DEBUG_PLUSTEK=12
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
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
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
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 +#
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 Jason,
thanks for the information, just some notes before.
You might want to use reply all, otherwise the answer
might get through unnoticed.
And for some reason your email did not convert sufficiently
to plain text for some reason, so it appears kind of
short at
Dear Maintainer,
my d knowledge is very limited, but it looks like a d runtime library
tries to do some destructor calls at process exit.
Unfortunately that tries to get a mutex lock, but that fails with
EOWNERDEAD, therefore then hits the assert(0) in maybe [1].
If that assert(0) just translates
Hello David Grajal,
find the ldd output of ldd inside a up-to-date buster amd64 VM below.
So either your /usr/bin/PosteRazor does not match the
current debian packaged binary, or it loads some
shared object which has this dependency.
At least the version in Debian posterazor 1.5.1-2+b1 got built
301 - 400 of 1271 matches
Mail list logo
