Control: tags -1 + upstream fixed-upstream patch
Dear Maintainer,
the issue seems to be with newer gcc versions string literals
get not put into memory mappings " r-xp ",
instead they are mapped " r--p ".
Such a string literal is used to determine the location
of the executable.
Upstream fixed
Dear Maintainer,
I tried to get some more information and was able
to record a crash with rr.
When continuing from below backtrace [2] it continues
into a recursion until the segfault is reached.
Therefore this might not be an nmap bug.
This led me to this bug report [1], which mentions
upstream
Control: tags -1 + moreinfo
Hello Parleur,
is this still an problem with current version in unstable?
If yes, you could maybe supply some more informations.
One way would be to install the package systemd-coredump
and see if in 'journalctl --no-pager' appear some backtraces
of the issue, which
Control: tags -1 + moreinfo
Hello dinar,
I tried to reproduce the crash inside a minimal
i386 buster VM, but could not get xchm to crash
on my downloaded version of php_enhanced_en.chm [1].
Is this the file you are using, too?
Without further information the maintainer is maybe
not able to
Hello Lars,
> in fact they all happen with the same program (claws-mail).
> Besides the claws-mail crashes I did not notice any other unexpected behavior.
Yes, if crashes are just in one application then it seems less
likely to be an hardware issue.
Maybe it is of some help, following seem to
Hello Lars,
just a wild guess - is claws-mail doing these ldap queries
in parallel in different threads? This in combination with
the unsteady connection to the server could make two threads
operate on the same structures?
In that case following gdb output would show all
threads with their
Hello Nicolas Patrois,
following page demonstrates better what I tried to say:
https://buildd.debian.org/status/package.php?p=gimp
There the architecture dependent packages for i386 got built
and "installed" to unstable, but the arch :all packages,
like gimp-data, failed to build because of an
Hello Alex Riesen,
I am not the maintainer of edid-decode, but was just
looking through some random issues.
Your attached output of the current upstream might
point to this commit [1].
But to be sure either you should attach a copy of
your input file, or if that is now wanted,
a backtrace like
Hello Steve Newcomb,
I am not the mailutils maintainer, but just came across you report.
The information you supplied might not be enough
for the maintainer to track down the issue, and
it might be related to the content of your mail directory.
You supplied the dmesg output, but even when the
Hello Nicolas Patrois,
not being a gimp maintainer, but might this just the
the nature of unstable - gimp:i386 got installed for some
reason, but gimp-data:all did not get installed
to the FTPs, maybe because of an failure of gegl, I guess,
which failed on most of the architecures except i386.
Hello Lars,
because you mention repeating crashes which, as far as I see, are
in different programs in different backtraces.
Maybe the problems are created by a bad memory module?
Therefore could you please run a tester like memtest86+, just
to rule out an hardware issue?
Kind regards,
Bernhard
On Sun, 17 Nov 2019 10:33:10 -0800 Ryan Tandy wrote:
> On Sun, Nov 17, 2019 at 05:11:13PM +0100, Lars Kruse wrote:
> > #0 0xb77acbea in ldap_unbind_ext () at
> > /usr/lib/i386-linux-gnu/libldap_r-2.4.so.2
>
> Please could you install libldap-2.4-2-dbgsym and obtain the backtrace
> again:
>
Hello Markus, hello Enrico,
I am sorry to be late, but I guess I have found the issue.
The function SetThreadPriority does not return properly
therefore the following function gets executed which writes
to somewhere, that causes later the crash below.
The build logs show a warning for this issue:
Dear Maintainer,
I tried to find out what happens and I think it is
related to the changes from #928467.
Because of these the configure script searches now
for libdb-5.3.a in directory /usr/lib/i686-linux-gnu
(in configure "$dir/lib/${host_cpu}-${host_os}").
Unfortunately that library lives in
Dear Maintainer,
the above backtrace lacks symbols but should
match something like below.
Kind regards,
Bernhard
>From submitter: | Reconstructed:
fcitx(+0x1927)[0x5568b6236927] | 0x55b5bef8e927
in OnException at
Hello,
this seems to be caused by a build failure in 1:9.0.0-1
for i386 while amd64 succeeded.
The build failure seems related to #942864.
Next upload 1:9.0.0-2 succeeded for both architectures.
Kind regards,
Bernhard
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-9=i386
Control: forcemerge 939754 940931
On Sun, 22 Sep 2019 10:19:59 +0530 Darshan Narayan
wrote:> ```
> ...
> using GEGL version 0.4.12 (compiled against version 0.4.14)
> ...
> #7 0x561237ca0411 in gimp_gegl_mask_is_empty ()
> ...
Hello Darshan Narayan
this issue is tracked in Debian bug
Control: forcemerge 939754 941275
On Fri, 27 Sep 2019 19:28:25 +0530 Lalit Kumar
wrote:
> ...
> using GEGL version 0.4.12 (compiled against version 0.4.14)
> ...
> #7 0x5634ba3aa411 in gimp_gegl_mask_is_empty ()
> ...
Hello Lalit Kumar,
this issue is tracked in Debian bug #939754 and
Dear Maintainer,
I guess this has to do with the package libgtkd-3-0.
Currently testing contains the version 3.8.5-1+b2.
That one got compiled with ldc 1:1.17.0-2.
The version 3.8.5-1 got compiled with ldc 1:1.12.0-1.
Installing that version from [1] makes tilix at least
run and open its window.
Control: forcemerge 939754 940907
Hello Stefan Pietzonke,
this issue is tracked in bug #939754 and should
disappear by installing latest updates
to libgegl-0.4-0 in version 0.4.14-2.
This was caused by gimp 2.10.8-2+b1 being built
against libgegl-0.4-0 in version 0.4.14-1,
but running with
Control: forcemerge 939754 940808
Hello Jeff,
this issue is tracked in bug #939754 and should
disappear by installing latest updates
to libgegl-0.4-0 in version 0.4.14-2.
This was caused by gimp 2.10.8-2+b1 being built
against libgegl-0.4-0 in version 0.4.14-1, but
running with version 0.4.12-2
Dear Maintainer,
upstream issue [1] got closed with commit [2] in the master branch,
and should be contained in the upcoming release 1.9.0.
Unfortunately I guess the upstream 1.8.x branch will not
get an update for this, so either the patch in my previous
mail should work, or the change proposed
Control: forcemerge 939754 939768 939876 939977 939985 940008 940011 940042
940044 940088 940174 940177 940285 940472 940525 940561 940610
Hello,
I hope it is ok to merge all such bugs.
All of them show gimp_gegl_mask_is_empty at an
instruction address ending in 411.
Now that gegl 0.4.14-2
Dear Maintainer,
just in case it may be of any help.
I guess the dmesg line points to function screen_write_collect_end
in screen-write.c:1240.
Kind regards,
Bernhard
# Bullseye/testing amd64 qemu VM 2019-09-16
apt update
apt dist-upgrade
# testing -> unstable
apt update
apt dist-upgrade
Hello,
I have created a new upstream issue:
https://gitlab.gnome.org/GNOME/gegl/issues/206
Kind regards,
Bernhard
Dear Maintainer,
I guess this issue caused also gegl not transitioning to testing and
therefore another issue within the package gimp e.g. bug #939768
and a few more.
I tried to reproduce it in a qemu VM for mips64el
and hit the same issue.
Running just the mentioned test it returns a timeout
Hello Stephen, hello Claude,
following that previous idea of just replacing the aligned
instruction with the unaligned one the hacky patch below got
created, just replacing vmovapd by vmovupd.
Not considering any side effects and maybe other
instructions with alignment requirements.
At least a
Hello Stephen, hello Claude,
following discussion seems also related and raises the question
if the variable cannot be aligned, could then mingw-w64 just emit
the unaligned instructions, even if slower than the aligned ones,
which are faster but also crash.
Hello Martintxo,
your last attachement confirms we get into a recursion in
mwxWindow::DoClientToScreen in the suspected line [L3158].
Further it looks like this==m_parent at this state, so
this window is its own parent ?
I guess entering the recursion in that case is clearly wrong,
therefore
Control: tags -1 + upstream
Hello Claude Heiland-Allen,
I tried just to collect some more information for the maintainer.
The issue could be reproduced in a qemu VM
with '-cpu host' on a Ryzen 7 1700.
The resulting binary crashes on Windows at the same instruction,
so I guess Wine can be ruled
Hello sixerjman,
the maybe same bug #934105 got closed and mentions the issue
is no longer visible in 4.14, I guess you upgraded too and
I want to ask if you still can observe that crash.
If not you could also close this bug by sending your answer
to 933202-d...@bugs.debian.org
Kind regards,
Hello Stephane,
sorry for the delay, you might use for Debian bugs reply all, to
get the information recorded in the bug and notify the real person.
As not being involved in packaging gimp I really just tried to get
some more information from the backtrace, which led to the
bug reports in gimp's
Dear Maintainer,
I guess the actual segmentation fault is fixed since kamoso 3.2.4-1.
Instead it should print this message:
The webcam controller was unable to find or load wrappercamerabinsrc plugin;
please make sure all required gstreamer plugins are installed.
The last question would
Dear Maintainer,
migth this be related to this bug:
https://bugs.debian.org/935496
Kind regards,
Bernhard
Hello Ondrej Zary,
while looking through bug reports for some random
packages I got to your report.
I guess your system got updated at least from Stretch to Buster,
therefore you might have freerdp-x11 installed while that
is not part of the official Buster release.
It got also removed from Sid,
fixed 932550 4.19.67-1
Dear Maintainer,
this backtrace is identical to that one reported in #935604.
Also the expected message appears in this report:
...
"[xcb] Unknown sequence number while processing queue"
This time I found also this upstream bugs that may be related:
Hello,
this sounds related to these bugs:
https://bugs.debian.org/935496
https://bugs.debian.org/935972
https://bugs.debian.org/935916
Kind regards,
Bernhard
Control: submitter 939029 Nicola
Control: fixed 939029 librsvg/2.44.14-1
Control: tags 939029 + upstream fixed-upstream
Hello,
this clone is just to handle the issue described in
messages #18, #36, #48, #73.
Last contains upstream bug and patch.
This should be fixed in testing already and just
reassign 914150 libfm/1.3.0-1
Hello Chris,
I added it to your report guessing that it might be the issue
you observed. Now I see your setup is way more complex than my test.
To reveal some more information about your issue, you could install
the package systemd-coredump, then in the journal should a
backtrace appear after a
Dear Maintainer,
I tried to reproduce the issue, but unfortunately I
receive no segmentation fault, instead a floating point exception.
(By using the button with the play symbol at the middle bottom.)
This happens there because the divisor frame_rate is zero.
For this issue I could not find an
Hello,
this sounds related to these bugs:
https://bugs.debian.org/935916
https://bugs.debian.org/935496
Kind regards,
Bernhard
Control: reassign -1 fuse 2.9.9-1
Dear Maintainer,
installing fuse in a minimal Bullseye qemu VM fails the same way.
It seems that /var/lib/dpkg/info/fuse.postinst contains a
call to udevadm that fails like this:
root@debian:~# udevadm test --action -p /devices/virtual/misc/fuse
test:
Hello,
I guess #921959 describes also the same problem.
Attached patch tries to workaround that issue by not
using the the original buf pointer increased by the
offset of member th_msg.
That way at least the warning "overflows the destination"
is not written anymore at build time and a package
Hello Martintxo,
I am just looking at crashes of some random packages and
found your backtrace. Thats already a good start.
As I it looks like you had installed the package
amule-utils-gui-dbgsym maybe you could also install these packages:
libwxbase3.0-0v5-dbgsym libwxgtk3.0-0v5-dbgsym
Hello steph,
I tried to get some more information from the backtrace and think
it would look like shown below [1].
It would show at least that there was some issue with the communication
to the X-server and it points to xcb_io.c, line 260 [2]:
Hello Alf Gaida,
I am just looking through crashees of some random
packages and stopped on this bug.
I found that you used at least following packages from experimental:
evolution libglib2.0-0 libsoup2.4-1
And unfortunately there are no dbgsym packages for the
versions of that time of
Control: tags -1 + upstream
Control: fixed -1 4.89+dfsg-0.1
Dear Maintainer,
I just tried to find some more informations about this issue.
The lsof version 4.89+dfsg-0.1 did not show this issue, therefore
Stretch is not affected. It started with version 4.91+dfsg-1 which
is already contained in
Hello,
maybe the following report is related:
https://bugs.debian.org/928736
Kind regards,
Bernhard
Control: reassign -1 src:linux 4.19.37-5
Control: affects -1 qemu-system-x86
Control: fixed -1 4.19.37-4
Hello Guido,
thanks for the confirmation.
So I try to reassign this bug to the kernel package.
Kind regards,
Bernhard
Control: tags -1 + upstream
Dear Maintainer,
I tried to get some information to this issue.
The error is given within this backtrace [1].
This is also present in the upstream git 1.8.x branch.
A git bisect points to upstream commit 82fce18.
However that commit seems to just add some checks to
Hello Seth Foley,
if possible you could now install gdb
and the following debug symbol packages.
The latter are stored in a separate
repository, more details in [1]:
handbrake-dbgsym libavformat58-dbgsym
Then if you have not rebooted since the last
handbrake crash, you can use following
Control: reassign -1 libcurl4 7.65.1-1
Control: affects -1 + rtorrent
Control: tags -1 + upstream fixed-upstream
Control: fixed -1 7.65.3-1
Dear Maintainer,
I just tried to find some more information from the given backtrace.
That I guess would translate to something like below [1],
if it would
Package: cdrom
Severity: wishlist
Tags: d-i
Hello,
when I tried to find something about #932149,
which got closed because the submitter received spam,
I found something that may still of interest.
When RAM is limited it might happen, that not the whole
initrd fits into RAM. But the kernel gets
Hello Seth Foley,
sorry for the delay.
I guess that "Core file was truncated to 2147483648 bytes." means that
the current configuration probihited to save the whole process.
So first you could try to start handbrake the following way:
ulimit -c 0
handbrake
(That might raise that limit
Dear Maintainer,
this issue seems to start since patch:
features/all/lockdown/0031-tracefs-Restrict-tracefs-when-the-kernel-is-locked-d.patch
Therefore a vanialla build does not show this issue.
With either of the following changes on top of all
debian patches, the exception does not
Hello Jose Ortiz,
without deeper knowledge of unknown-horizons I tried to reproduce
this issue, but it did not show up for me.
It might be possible to install the package systemd-coredump.
Then in the journal should a backtrace be printed when you
repeat the checkconfig, which you could forward
Hello Ray Klassen,
without deeper knowledge of libreswan I tried to reproduce
this issue, but it did not show up for me.
It might be possible to install the package systemd-coredump.
Then in the journal should a backtrace be printed when you
repeat the checkconfig, which you could forward to
Control: found -1 linux/5.2.6-1
Dear Maintainer,
the bugreport https://bugs.debian.org/934292
seems about the same issue.
The issue can be reproduced by just accessing the file below.
root@debian:~# strace -f powertop
execve("/usr/sbin/powertop", ["powertop"], 0x7fff5df92d08 /* 11 vars */) =
Dear Maintainer,
it seems this issue got reported now
also against package src:linux in:
https://bugs.debian.org/934304
Kind regards,
Bernhard
Weitergeleitete Nachricht
Datum: Thu, 8 Aug 2019 08:45:58 -0400
Von:sixerjman
Indeed it does. I will see if I can get more information after
installing debug syms
as instructed in #934105.
Hello Jun Jiang,
thanks for the additional information.
> As for for question at the end about changing display resolution, I don't
> follow you. Pardon me if I am misunderstanding, are you asking whether I
> changed screen resolution when it happened? If that's what you mean, then
> no, I
Dear Maintainer,
this bug looks similar to following bug:
https://bugs.debian.org/934105
Kind regards,
Bernhard
Hello Damon Anton Permezel,
this USB disk, has it a gpt or msdos partition table?
Also, maybe if it is possible, you could install
the package systemd-coredump.
Then some more information about a crash would be
collected in the journal, and a the process state would
be saved into
Control: tags -1 - moreinfo
Dear Maintainer,
I think the top frames with debug symbols would look like this:
(gdb) bt
#0 memcpy () in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7feaa926d05d in Baloo::PostingCodec::decode () at
./src/codecs/postingcodec.cpp:42
#2
Hello Leoš Pohl,
thanks for the additional information.
Please use the reply-all in your email program, to have
the ...@bugs.debian.org recipient in every answer, so
the debian bug tracker receives the messages too.
Just for future crashes (or if the Mainainter will requests it),
if you install
Weitergeleitete Nachricht
Datum: Wed, 7 Aug 2019 15:44:44 -0400
Von:Leoš Pohl
Hello Bernhard,
since I could not find a way to forward the report directly
to this bug, please find screenshots here
https://snag.gy/mpTyWe.jpg and here https://snag.gy/lUKpRc.jpg
and the
Dear Maintainer,
might this issue be the same as described in this bug:
https://bugs.debian.org/932767
Kind regards,
Bernhard
Control: tags -1 + moreinfo
Hello Leos Pohl,
you write when you execute "balooctl enable" you receive
some lines starting with "KCrash: ...".
When this happened, is there a small sad smiley [1] in the
system tray (normally at the bottom, left of the clock)?
If yes, you should receive by
Dear Maintainer,
I found that I could also reproduce this issue on my AMD Ryzen 7.
Based on the modification date of my VM it was working
with Buster/testing at least at 2018-08-24 at this hardware.
I tested the binaries qemu-system-x86_64 down to 2.12+dfsg-2 and
also current qemu git, all show
Dear Maintainer,
this seems related to the ATA_DMA=y configuration.
With a seabios package built with ATA_DMA=n,
a directory listing of the install cdrom is possible again.
Also this setting seems to be introduced just with seabios
package version 1.12.0-1.
A google search returned following
Hello Jiang Jun,
I just tried to reproduce the crash. Unfortunately it
did not happen in a minimal VM.
This package google-chrome-stable is from a third-party repository?
Therefore you might be able to have a look at the
output of "coredumpctl list".
There should be a line for the crash with pid
Dear Maintainer,
I tried to get some more information to this crash and
could reproduce it on a Raspberry 3 running a Debian Buster armhf
image created by following script (with "arch: armhf" and linux-image-armmp):
https://salsa.debian.org/raspi-team/image-specs
The crash seems to happen
Control: fixed -1 tigervnc/1.9.0+dfsg-1
Dear Maintainer,
I tried to have another look at it and collected some more details.
I found version 1.9.0+dfsg-1 did not suffer from this crash
(and had no dependency to libunwind8).
I wondered how there the exception handling worked there and found
Dear Maintainer,
in the meantime upstream got this bug report [1] that
seems to describe the same issue.
The applied fix seems similar to my previous patch
and 1.8.2 should include it.
Kind regards,
Bernhard
[1] https://bugs.kde.org/show_bug.cgi?id=407829
Am 22.07.19 um 15:44 schrieb Kevin Otte:
> As soon as I disconnect the client, the server again crashes with a
> backtrace:
I was told in the upstream report [1], mentioned in #923962,
that the crash on disconnect is known and handled upstream in [2].
[1]
Am 22.07.19 um 03:28 schrieb Kevin Otte:
> That is correct.
Strange, because in my VM I received just the
Backtrace when using no view-only password.
One thing to note, I used the same password for
regular and view-only ...
Hello Kevin Otte,
Am 21.07.19 um 17:23 schrieb Kevin Otte:
> I have now tried with and without a view-only password. I receive the
> same error in both cases.
just to be sure, you got also the "Backtrace" message when
you answered the following question on vncserver start with yes?
Would
Dear Maintainer,
this looks like the same issue reported in #923962.
I have reassigned that bug to libunwind8, but that
did not receive an answer yet.
More details in [1].
@Kevin Otte: Could you confirm that you did not set a view-only password?
Because doing so could be a workaround.
Kind
Control: tags -1 + upstream fixed-upstream
Dear Maintainer,
I could reproduce a crash in csd-backlight-helper too.
Had not installed a complete cinnamon desktop - just the
cinnamon-settings-daemon package, running a plasma desktop.
It looks like upstream handled the issue already in [1] [2].
Hello Saša Janiška,
sorry for the delay.
The versions match what I tested previously, but could
not reproduce the crash.
Found also no upstream bug matching this one.
Next step, if you can still reproduce the crash, would be
to attach an debugger like this:
script -a gdb-gnome-maps_$(date
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
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 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
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,
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 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
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
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
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
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:
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
Hello
the issue you observed might be already reported in:
https://bugs.debian.org/924925
Kind regards,
Bernhard
Hello David,
that was not the link I sent in my mail,
I sent a plain link to bugs.debian.org.
Maybe you are viewing my mail via google webmail client,
and that is adding something unwanted?
Kind regards,
Bernhard
Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-77017
Dear Maintainer,
I created an upstream bug report and forward this bug to it.
Kind regards,
Bernhard
Hello David,
I could find an issue with konsole freezing
and reported it in this bug:
https://bugs.debian.org/931844
Maybe you want to have a look if you find your issue there.
Kind regards,
Bernhard
Package: libqt5gui5
Version: 5.11.3+dfsg1-1
Severity: wishlist
Tags: upstream
Affects: konsole orca
Dear Maintainer,
I noted some recent additions to bug #594506 which I guess
describe a different problem. I did some investigations and
tripped on the issue with following steps:
- Installed in a
Package: orca
Version: 3.30.1-1
Severity: normal
Dear Maintainer,
I was trying to triage another bug by using orca
inside a minimal Buster amd64 qemu VM.
On that minimal system I installed just:
apt install systemd-coredump xserver-xorg sddm plasma-desktop orca
When I tried to start orca in
Hello Francis Laniel,
I am just looking at some crashes in some random packages,
and found this nouveau issue familiar.
I guess __pthread_cond_wait_common should be able to
handle a NULL for abstime - e.g. should "Block without a timeout".
601 - 700 of 1271 matches
Mail list logo
