Hello Mr. T,
I tried to reproduce the issue inside a small VM.
I hit an issue when copying something, mostly larger areas, in gimp.
If I started gimp from a terminal I got this message [1].
Maybe you could confirm when you start gimp from a terminal
you see the same message, when the error happe
Dear Maintainer,
I tried to have a look and could reproduce the issue.
It seems this got already fixed upstream in [1].
Also a related upstream issue exists [2].
A package built with this patch applied does
not show the fault.
Kind regards,
Bernhard
[1] https://github.com/gwsw/less/commit/520
Hello Kody,
I had in the past also a working crash kernel setup.
But that started to fail with and after kernel 5.5.
Unfortunately I did not yet come to report this to debian.
If that is also the case for you, a workaround could be to
install the old 5.4.19 bpo kernel [1].
And modify /etc/defaul
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.
Ther
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
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,
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++:
-I/home/benutzer/source
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 as
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
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
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
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
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
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
http
Dear Maintainer,
I tried to reproduce this issue and received a backtrace like in [1].
This looks like being fixed upstream in commit [2].
A package built with this patch does not crash any more.
The reason seems to be because this macro defines a variable
in a block local scope while it should
Hello Mikael,
maybe you could install systemd-coredump and look into output
of "journalctl -e" after such a crash happened again.
For more information please have a look at [1] about several
ways to collect some more information that might help the
maintainers.
Kind regards,
Bernhard
[1] https:
Dear Maintainer,
I tried to have a look at the kernel message and if I could
retrieve some more information with the help of the dbgsym
package, like described in [1].
And I came up with the following location:
at 0x5557997c: file imap-notify.c, line 305.
0x55579976 :41
Package: libmutter-7-0
Version: 3.38.3-2
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I tried to replicate #982572, therefore
setup a qemu VM with two qxl devices [1].
This is currently running a kernel 5.2 due to #983934.
Inside I have trouble with mouse input,
therefo
Dear Maintainer,
I investigated a bit further and came across this document [1].
There it is stated that in Linux usually a single qxl device with
multiple outputs [2] is used and in Windows multiple qxl devices with
a single output each [3].
Using with a Linux guest the suggested multiple output
Hello Joe,
this information might not be sufficient for the maintainer.
Could you try following to collect some more informations?
- install packages:
gdb psmisc konqueror-dbgsym
- stop all running instances of konqueror:
killall konqueror
- then start konqueror inside a debugger:
Hello Richard,
I tried the steps below [1] but it did not trigger
a crash inside a gnome/wayland test VM.
Maybe you could install the package systemd-coredump, trigger
the crash once more and retrieve the logging from the current
boot by 'journalctl -b0 > journalctl.txt' and forward the
lines rel
Dear Maintainer,
I tried to get some more information from the kernel message.
This led me to this line:
at 0x5556ee99: file gpm-engine.c, line 540.
There the array is dereferenced unconditionally:
https://sources.debian.org/src/mate-power-manager/1.24.2-1/src/gpm-engine.c/#L540
539
Hello Richard,
thanks for the fast response.
I failed to tell you the -b0 means the current boot,
therefore if you rebooted with -b-1 might the boot that
contains the crash.
But maybe you could improve the output of coredumpctl
quite a bit.
Could you please add the debug symbol package repository
Hello Richard,
thanks for the new information, but really
the dbgsym packages were meant.
They are available in a separate repository.
Nevertheless, if adding this repository is not possible,
then there is another way, but that would download
unknown size of files into directory "$HOME/.cache/deb
Control: reassign -1 gnome-shell 3.38.3-3
Control: affects -1 python3-pygame
Hello Richard,
wonderful, thanks, thats a great backtrace.
It is highly similar to that one in upstream bug [3491]
and still quite similar to [3785].
Some commits entered the upstream 3.38 branch to fix the first bug,
f
Dear Maintainer,
this issue might be following upstream bug [1].
Because of that winepath "emits DOS-style instead of
UNIX-style line endings".
Therefore the carriage return character got part of
the filename and could therefore not be found.
This got fixed already in upstream wine-5.7.
Kind r
Dear Maintainer,
this crash happens because this executable is expecting
at command line a parameter month and year.
Doing so produces a calendar at stdout in postscript format.
Kind regards,
Bernhard
(gdb) bt
#0 __GI_strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0,
loc=0x7f3181d
Hello Celelibi,
does this happen with current version
in testing 0.228+dfsg.1-1, too?
Kind regards,
Bernhard
Dear Maintainer,
tried to reproduce this issue inside a minimal qemu VM and
found that this starts to manifest with kernel version 5.9.
Using a kernel 5.8 with current testing userland does
not show this issue.
These tests were done with qemu parameter "-cpu host".
Without any cpu parameter I cou
Hello Martin-Éric,
without being involved in packaging fwupd I tried to
have a look at this issue.
I could not reproduce it inside a i386 qemu VM (not even
with "-cpu pentium"). Have not tested on real hardware.
Looking up the endbr32 instruction, it seems it belongs to something
called "Contro
Hello Ryutaroh Matsumoto, dear Maintainer,
I am not involved in packaging valgrind, just trying to
help with some random bug reports.
For this report #983377 I cannot follow, how #928224 is blocking it?
#928224 is about valgrind not running at all,
with "a function redirection ... cannot be set u
Hello Sandro, hello Norbert,
this sounds like the feature "Highlight lines coming into view" [1].
There is an option that looks like it could be disabled in:
Profiles - Scrollbars - "Highlight the lines coming into view"
Kind regards,
Bernhard
https://invent.kde.org/utilities/konsole/-/comm
Hello everyone,
I tried to reproduce this issue inside a minimal qemu VM,
with an available X server, and investigate with the help
of rr-debugger and valgrind.
First in camp::picture::shipout3, line 1404 the process asy
forks, and following failure happens in the child thereof.
In the backtrace
Am 15.03.21 um 14:10 schrieb Bernhard Übelacker:
otherwise I got a SIGFPE
A short offtopic side note to rr sensing this SIGFPE,
not directly related to the malloc message:
This can also be seen in a process without being
recorded by rr by setting LP_NUM_THREADS to zero, so
operations take
Am 15.03.21 um 16:36 schrieb John Bowman:
A SIGFPE
Hello John,
sorry, I noted the details for the SIGFPE in my
second mail just for completeness about debugging.
The issue starting it all seems the SIGSEGV from my first mail.
On a second look it seems that the descructor of
the builtin_builde
Control: reassign -1 libvtk9 9.0.1+dfsg1-8
Control: affects -1 python3-vedo
Dear Maintainer,
I tried to reproduce this issue and got also a crash.
Digging further it looks like in FireTimers an iterator "timer"
of the map LocalToTimer currently points to the element
with id=1, which gets remove
Hello Helge,
do you still see these messages in your logging?
If yes could you maybe add the surrounding logging
of one such fault? E.g. by something like this:
journalctl | grep "traps:" -C20
Kind regards,
Bernhard
Hello Helge,
do you still see these messages in your logging?
If yes could you maybe add the surrounding logging
of one such fault? E.g. by something like this:
journalctl | grep "traps:" -C20
Kind regards,
Bernhard
Dear Maintainer,
I have tried to reproduce these segfaults and received them
when redshift-gtk is installed and lightdm is used as login manager.
It looks like redshift-gtk installs a systemd user unit,
which is executed also for the lightdm login screen.
But it looks like the 'systemd --user' pr
Dear Maintainer,
just a side note:
The visible segfaults might be related to #977945.
Unknown if they have any effect on suspending.
Kind regards,
Bernhard
Dear Maintainer,
I tried to reconstruct the given backtrace in [1].
So the actual issue seems to be a "movq" instruction which
seems to be due to [3] a SSE2 instruction, which might
the "Pentium III M" is lacking, like Stefan already noted.
I am not sure where the current Debian baseline could be
Dear Maintainer,
this segfault seems to happen in [1].
It looks like upstream is not
yet prepared to work with Wayland.
There is an upstream issue about wayland support [2].
Kind regards,
Bernhard
[1]
(gdb) bt
#0 0x7f50f93c5caf in XGetKeyboardMapping (dpy=0x55a910fa20d0,
first_key
Dear Maintainer,
I tried to reproduce, and it got it crashing too
when trying to move a window just by keyboard, before
moving any windows by mouse.
It looks like in that case the variable currentClient
never got set, therefore the access in UpdateDesktop
dereferences a null pointer.
This seems t
Hello Celelibi,
unfortunately, if I try to reproduce I reach the exact same stack,
but in case of my VM ctx->pipe->set_shader_buffers contains a
valid function pointer.
Maybe you could add some information about which graphics card
you use and maybe running with 'export LIBGL_DEBUG=verbose'
might
Hello Julian,
On Thu, 10 Dec 2020 16:52:14 +0100 Julian Andres Klode wrote:
... install libapt-pkg5.0-dbgsym and apt-dbgsym
from the dbgsym repository and try again.
Unfortunately there are just dbgsym packages for 1.4.10.
I guess the dbgsym packages for 1.4.11 never got published,
because
Am 20.03.21 um 21:44 schrieb Helge Kreutzmann:
If I should install a -dbg version or something else please
inform me.
Thank you for the additional information.
There might really be something more. If you have not, is it possible
to install the package "systemd-coredump".
If then a crash happe
Dear Maintainer,
On Mon, 08 Mar 2021 15:49:55 +0100
=?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?=
wrote:
#4 0x554359e8 in PatchageCanvas::index_port(PortID const&,
PatchagePort*) (this=0x0, id=..., port=0x557233c0) at
../src/PatchageCanvas.hpp:59
#5 0x55450837 i
Hello everyone,
I added it, and now I got one:
Tue 2021-03-23 20:20:40 CET2000 109 115 11 present
/usr/bin/sddm-greeter
If I extract it, I get:
Executable: /usr/bin/sddm-greeter
...
#9 0x7fe7b41f5def __clone (libc.so.6 + 0xfddef)
With this "coredumpctl
Dear Maintainer,
I tried to have a look at the core file and a backtrace
with all needed symbols looks like in [1].
In the end it looks like in refresh_combo_devices [2] it
is attempted to load a harddisk icon.
This failed for some reason in [3], therefore a local variable
"theme_icon" contains
Hello Nenad Cvetkovic,
I tried to have a look at your core file.
It shows a crash with following backtrace [1].
The reason seems to be an invalid function pointer in variable "prepare".
The upstream issue in [2] shows a similar backtrace, but I
am not sure if they are related about what is causin
Dear Maintainer,
I tried to have a look at this segfault.
As far as I can see the issue here is a memory access after the
php heap, where this memory was allocated from, got unmapped.
Below are the backtraces for allocation [1], unmapping [2]
and the segfault [3].
Some more details in attached f
Hello Santos,
I tried to reproduce this issue but did not see it inside a minimal VM.
Therefore tried to some more information from the Code bytes printed in
you journal/dmesg.
This should point to this instruction:
0x7f6e16bd5268
<_ZN14KWaylandServer16SurfaceInterface13frameRenderedEj+24
Control: fixed -1 1:3.0-2
Control: tags -1 + upstream fixed-upstream
Dear Maintainer,
I tried to reproduce this issue and got this backtrace:
(gdb) bt
#0 0x7f52d57cf7e4 in _IO_new_fclose (fp=0x0) at iofclose.c:48
#1 0x55884d86fec0 in shutdown_events () at
../../../src/aud
Hello Silvério,
Am 31.03.21 um 20:42 schrieb Silvério Santos:
Hallo Bernhard,
Here is it:
Mär 31 20:11:25 systemname kernel: kwin_wayland[1834]: segfault at e8 ip
7fe70ba08268 sp 7ffc9bbf64d0 error 4 in
libKWaylandServer.so.5.20.5[7fe70b9b+b6000]
Mär 31 20:11:25 systemname kern
Hello Enrico,
I am not involved in packaging python3-magics++,
just tried to reproduce this fault.
Unfortunately it did not show up in my minimal test VM.
It produced a png with a frame and a text and a symbol
at the bottom. Is there something more expected to
be in the rendered png?
Do I have mi
Hello Antonio,
was this line in dmesg maybe followed by a "Code:" line?
Could you provide that too?
Otherwise maybe you could install systemd-coredump and after
the next crash journal should contain more info about it and
collect a core for later inspection.
More details here: https://wiki.debia
Dear Maintainer,
I could reproduce the issue inside a minimal stable VM.
It crashes with following backtrace [1].
This crash does not show up with the same input in current testing.
The resulting png file shows a "mesh" on top of a map.
The method GribDecoder::visit changed a bit [2].
Kind regar
Dear Maintainer,
tried to export the example files delivered with prusa-slicer
e.g. AK_Bed.stl, but could not reproduce the fault inside
a minimal qemu VM.
My resulting process has /usr/lib/slic3r/auto/Slic3r/XS/XS.so
mapped, the function _ZN5boost6nowide6setenvEPKcS2_i
would be printed by gdb
Dear Maintainer,
I tried to have a look at this savegame and when loaded
shows these freezes to me too.
An attached gdb shows that leaving VertexPathfinder::ComputeShortPath
takes some minutes, while the game is frozen.
Upstream might have already some optimizations
for this issue in [1].
At le
Dear Maintainer,
tried to locate the exact smashing.
It looks like the ioctl(EXT2_IOC_GETFLAGS) takes an int* parameter,
but writes 8 bytes instead of just sizeof(int) to the given address.
Kind regards,
Bernhard
Old value = (void *) 0xf759b62c03711000
New value = (void *) 0xf759b62c000
Hello Chris,
Am 04.04.21 um 22:33 schrieb Chris Hofstaedtler:
Hello Bernhard, Marc,
Some more questions:
1) which kernel version is this?
My test was just inside a temporary VM with current testing.
But I can still reproduce this with current testing kernel at the host too:
Linux rechner 5
Dear Maintainer,
I tried to fill the gaps in the given backtrace with
the matching dbgsym packages, see below.
Might this be a kind of sandbox, not allowing
to allocate memory the way libopenblas.so does/did?
Kind regards,
Bernhard
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:
Hello Joël,
I guess I have a similar setup and had similar
lock-ups as your video shows.
I had opened this upstream bug [1].
Either with latest bios updates the situation improved,
or last year I started to do after each cold boot another
warm boot and have the feeling that way this issue does
o
Hello Joe,
thanks for the backtrace. It enabled me to reproduce it.
You have configured a post processing step in your printer settings?
Then this setenv function is tried to be located in the loaded
shared objects. Unfortunately Slic3r/XS/XS.so does not show to be
linked to libboost_nowide.so, w
Package: ddrutility
Version: 2.8-1.1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I found on some attempts to use ddru_findbad are
failing for me like this:
...
/usr/bin/ddru_findbad: 1027: arithmetic expression: expecting primary: "
(300-/dev/loop0:) "
I used
Hello Roderich,
I looked a little around and found Debian bug #967941.
There the media file is a video file that led
to loading libopenblas.so. This seems to be caused
by the file gstreamer-1.0/libgstlibav.so.
I could reproduce it now within a VM with current testing.
By creating a mkv video cont
Dear Maintainer,
I was trying to collect some more information for bug #973811.
There it looks like openblas does its own memory management seems
therefore affected by some sandboxing disallowing a SYS_bind syscall.
With the test VM I used there I get with current testing this
output for a manual
Hello Gregor,
I am not sure if my last mail reached you. [1]
There I did not notice a line for libboost_nowide in ldd output.
Also I tested by the last two modifications which
made XS.so to be linked to libboost_nowide and made
slic3r not fail with the unknown symbol error.
Kind regards,
Bernhar
Dear Maintainer,
I wondered why the first two allocators would fail
and tried to step into.
At least the alloc_malloc seems to use the
regular glibc-malloc, and should succeed therefore [1]?
So might there be a size restriction in place how much memory
totem-video-thumbnailer is allowed to alloc
Hello Markus,
I tried to fill in the symbol information that were missing
in the above backtrace by using the available dbgsym
packages python3-cryptography-dbgsym and libssl1.1-dbgsym.
With these installed your gdb would show line information too [3].
I found following ticket [2] that shows in l
Hello Russell,
could you still see this issue?
Stack trace of thread 120123:
#0 0x7f49c3823ce1 n/a (/lib/x86_64-linux-gnu/libc-2.31.so
(deleted) + 0x3bce1)
Were there more lines following in the "Stack trace of thread 120123"?
And as lib
Hello Antonio,
thank you for the detailed informations.
Am 01.04.21 um 19:15 schrieb Antonio:
$ gdb gsettings-data-convert
Starting program: /usr/bin/gsettings-data-convert
(gsettings-data-convert:4756): GConf-CRITICAL **: 19:00:31.514:
gconf_engine_get_local_for_addresses: assertion '
Hello Silvério,
Reading symbols from /usr/bin/kwin_wayland...
(No debugging symbols found in /usr/bin/kwin_wayland)
BFD: warning: /tmp/user/1000/coredump-ySV5m6 is truncated: expected core file
size >= 2365169664, found: 2147483648
it looks like for some reason the kwin_wayland exceeds
the
Hello Russel,
thanks for the fast answer, unfortunately the
backtrace is not yet enough expressive.
Maybe you could also install the following debug symbol packages?
libqt5qml5-dbgsym libqt5core5a-dbgsym libqt5widgets5-dbgsym libqt5gui5-dbgsym
kwin-common-dbgsym kwin-x11-dbgsym
These are locat
Hello Antonio,
this directory should contain a file: /etc/gconf/2/path
The content should most probably what is shown here:
https://sources.debian.org/src/gconf/3.2.6-7/debian/default.path/
(And can be downloaded in the upper right corner.)
Kind regards,
Bernhard
Am 09.04.21 um 15:26 schrie
Hello Nenad Cvetkovic,
> Hi Bernhard Übelacker,
> I hope I managed to create a proper backtrace, this is my first time.
>
> As for your question about rebuilt packages, I have no idea when this
happened. I didn't build many things, I remember building ubuntu's Yaru
Hello Russel,
thank you for the detailed backtraces.
Unfortunately they point into Qt's javascript module,
finally trying to copy memory to a null pointer.
I have not found a hint to similar crashes in
upstream bug tracker.
Could you please provide which theme you are using,
or if there are mayb
Hello till,
I tried to reproduce this inside a minimal VM,
but the crash did not show for me.
Maybe you could provide some more details, e.g.
by installing systemd-coredump and inspecting the
journal after a crash happened and adding the lines
of the crash time to this bug.
Please see more detail
Dear Maintainer,
I tried to have a look and the segfault is really a result of the
previous g_param_spec_is_valid_name failures.
It looks like g_param_spec_is_valid_name got tightened lately to
not accept names with dashes anymore.
The following malloc corruption seems to originate in the backtr
Dear Maintainer,
the issue reported in #950646 might be a similar or the same.
Kind regards,
Bernhard
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 ve
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 t
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"
contai
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 unw_get_pr
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:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_reque
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
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 collect
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 repo
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 menu
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
Control: tags -1 + upstream patch
Dear Maintainer,
Looking at crashes of random bugs I found that this
issue manifests at least at i386 too.
The issue seems to be a too right stack size for a
reader thread.
With doubling the stack size for this thread the
application crashes not at startup anym
Dear Maintainer,
> (On exit is another issue with the FILE structure
> in readline library, but saw it just on exit.)
I tried to follow why this crash on exit happens,
and found that this second issue is because aeolus
does a "fclose (stdin);" on purpose.
But libreadline is not prepared to that
Dear Maintainer,
just tried to have a look at the part where steal-ctty is crashing.
It looks like it may get called from [1].
81 # Run the startup scripts once, using the preferred console
82 cons=$(cat /var/run/console-preferred)
83 # Some other session may have that console as c
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,
the information might not yet be enough for
the maintainers to help.
Maybe you could install the package systemd-coredump.
In the output of 'journalctl --no-pager' should then
the segfaults appear too, followed by a backtrace
that you could forward to this bug.
Kind regards,
Bernhard
Hello Dio Putra,
the information might not yet be enough for
the maintainers to help.
Maybe you could install the package systemd-coredump.
In the output of 'journalctl --no-pager' should then
the segfaults appear too, followed by a backtrace
that you could forward to this bug.
Kind regards,
Bern
Hello Seth Foley,
I just tried to reproduce by following your steps.
Unfortunately I did not get a crash.
Therefore this report might not contain enough
information for the maintainers to help.
Maybe you could install the package systemd-coredump.
In the output of 'journalctl --no-pager' should t
Dear Maintainer,
might this be the same as I described in #923017 ?
There are two related upstream commits mentioned,
and an example gdb session pointing to
function upload_plane with visible_pitch=0 too.
Kind regards,
Bernhard
https://bugs.debian.org/923017
Hello Dio Putra,
are there still files in /var/lib/systemd/coredump/ ?
If there are any, maybe you could copy it then to a
safe place where they do not get automatically deleted.
Kind regards,
Bernhard
501 - 600 of 1320 matches
Mail list logo
