Control: notfound -1 4:18.04.1-1
Control: found -1 4:19.08.1-1
Control: tags -1 unreproducible moreinfo
Hello Hans,
I tried to reproduce inside a minimal plasma testing VM.
But I could not see a noticeable amount of messages in
.xsession_errors while playing kpat.
If this is still visible on y
Control: tags -1 + patch upstream
Dear Maintainer,
I tried to have a look at this crash and I guess I found the reason.
The plugin calls into libgs.so.9 by gsapi_new_instance/psapi_new_instance.
Unfortunately the instance pointer is given to that function
uninitialized. But documentation states
Short addition:
this upstream issue seems to match better:
https://gitlab.gnome.org/GNOME/gimp/issues/3630
Which got fixed in branches master and gimp-2-10
by these upstream commits:
https://gitlab.gnome.org/GNOME/gimp/commit/bbcc7ca5f55e62404bd69bf2e5b198039ad3f568
https://gitlab.gnome
Hello Antonio,
could you please add to which windows version you
were trying to connect.
Maybe you could also try to start it that way:
catchsegv rdesktop ...
Even better would be if you could install debug symbols like
described in [1] and systemd-coredump.
Then after an application crashed
Package: rdesktop
Version: 1.9.0-1
Severity: normal
Dear Maintainer,
attempting to support triaging another rdesktop bug I found
there does not yet exist a dbgsym package.
I tried to find out why and guess this is caused by the
strip command done in the Makefile.
As stripping would be done by de
Hello Antonio,
thanks for your comprehensive investigation.
I was not aware that rdesktop did not yet have a dbgsym package,
have opened bug #948126 for this.
And unfortunately if the backtrace in catchsegv ommits function
names, its output is just of help when using the debian binary
with a dbgs
Hello David,
I guess the package "thunar-dbgsym gdb" are installed
on your system, but could you please recheck if
packages "libglib2.0-0-dbgsym libgtk-3-0-dbgsym"
are really installed, too?
Kind regards,
Bernhard
Dear Maintainer,
I tried to reproduce it also on amd64 and found it
crashing at the following location.
My knowledge of vala is limited, but is here the member
"suggestion_row.item.database" not yet set, but already accessed?
Kind regards,
Bernhard
Thread 1 received signal SIGSEGV, Segmentation
Short addition:
upstream changed that line urlbar.vala:109 in commit [1].
A locally built package including that patch
did not crash for me.
Kind regards,
Bernhard
[1]
https://github.com/midori-browser/core/commit/525f76c68fdde8a2d974c6975d9cc5ebe0cd594b
Dear Maintainer,
I just tried to reproduce the issue, but always
got a kernel oops instead of a usermode exception.
Therefore I guess this issue might be reassigned to src:linux?
By further looking it seems that in crypto_tfm_alg_blocksize
the __crt_alg member is dereferenced unconditionally while
Hello Milan,
thanks for the fast response - I currently try to build a
package with your patch, but I guess this could take some time...
And I don't know what the usual approach is,
but the original reporter is probably Jerad?
(@Jerad maybe you could confirm your issue is the
same that I was seein
Dear Maintainer,
just as a side note, a similar bug was submitted
against the basilisk2 package.
https://bugs.debian.org/922323
Another user of slirp is qemu, which had some changes in
that area, which seems to have evolved into this library:
https://gitlab.freedesktop.org/slirp/libslirp
Dear Maintainer,
I rebuilt a linux-image package with the patch applied
and the submitters' cryptsetup command finished
without visible error to me.
(console output and dmesg in second half of attached file.)
Due to my limited knowledge of cryptsetup I guess Jerad
could better judge if the resulti
Hello Md Ayquassar,
I am not involved in packaging gnome-shell, but may have
some pointers to gather some more informations for the
maintainer.
You could try to install the package systemd-coredump.
That way the output of 'journalctl --no-pager' should give
some information where the crash happene
Hello crvi c,
could you please add an example command
that you want to have completed?
And if you have changed the environment GLIBC_TUNABLES,
to which value?
Otherwise a gdb session driven by the two commands below
could maybe point to the exact location where the overwriting
takes place, if wat
Dear Maintainer,
I could reproduce the issue in a minimal bullseye VM.
>From my observations I guess the USR2 signal is sent
by logrotate:
/etc/logrotate.d/xdm:
kill -s USR2 $(cat /var/run/xdm.pid); \
If I read [1] right, then USR2 has a default action of
process termination. Therefo
Dear Maintainer,
when comparing with a process while having debug symbols
installed, I guess the given backtrace would translate to
something like below.
Therefore I guess this crash is the same
as described in #929113.
Unfortunately I could not find a matching appearance of
function gimp_project
Dear Maintainer,
I tried to gather some more information to this issue and
found below difference [1] [2] in sizes of struct gps_data_t,
by inspecting a running process in different stack frames.
Also I found that the current navit 0.5.3+dfsg.1-2+b1 was
built against libgps-dev 3.19-2 [6].
The cur
Sorry, forgot to attach details.
# Bullseye/testing amd64 qemu VM 2020-01-08
apt update
apt dist-upgrade
apt install systemd-coredump xserver-xorg sddm openbox xterm net-tools mc
fakeroot gdb navit navit-dbgsym libgps25-dbgsym
apt build-dep navit
reboot
mkdir /home/benutzer/source/libgps2
Hello Gulfstream, hello Jean-Luc,
this report got opened mentioning a "Thinkpad P1".
Reading through some pages about that device, it looks
like it contains some "hybrid graphics".
Maybe you both could confirm that your devices have such
"hybrid graphics", and if yes, maybe you could give some mo
Dear Maintainer,
I just tried to get some more info from the
dmesg line, which seems to point to:
file ./src/retention/dump.cc, line 127. [1]
@Pascal: More information could maybe retrieved from the journal
if 'systemd-coredump' could be installed, even better if additionally
package 'centreon
Am 09.01.20 um 17:05 schrieb crvi c:
> gdb -q -batch -command ~/gdb-cmds.bash.txt --args bash
> Function "__pthread_tunables_init" not defined.
> Breakpoint 1 (__pthread_tunables_init) pending.
> [Detaching after fork from child process 37973]
Sorry, wasn't clear about that.
The prompt then shown
Dear Maintainer,
I got today the same crash as the submitter.
It happened short after disconnecting one android device,
connecting another and opening/retrying the MTP connection.
This upstream bug looks related:
https://bugs.kde.org/show_bug.cgi?id=415693
(Seems to be also from buster due to a
Am 09.01.20 um 17:56 schrieb crvi c:
> I am using the same bash / gnome-terminal as part of my daily work. The
> crash was random and it is not consistently reproducible. I have a
> couple of bash core files, if that would be of any help.
Ok, I see - had hoped it to be better reproducible.
In my
Am 09.01.20 um 22:18 schrieb Pascal Vibet - ADACIS:
> @Bernhard : I install 'systemd-coredump' and 'centreon-engine-dbgsym'
> packages. I restart centengine. What information do you need? When
> centengine process crashes ? Or i run a program in same time ? What do
> you want me to do?
Great. Ju
Hello Pascal,
now I see one thing that would be even better:
coredumpctl gdb
info reg
thread apply all bt full
Sorry for not saying this sooner.
Kind regards,
Bernhard
|| ...635
<+261>: pop%r12
|| ...637
<+263>: pop%r13
...639
<+265>: pop%r14
Hello Boris,
I am not involved in packaging gdm or orca
but tried to get more information.
I added also the a11y tag in the hope to get
the attention of the right people.
I tested inside a minimal VM with the gnome package installed.
In the gdm3 login screen I also got no reaction from the
Ctrl-A
Dear Maintainer,
the given code from dmesg points to this function:
LIBMTP_GetPartialObject at libmtp.c:9070
The related code [1] looks like function LIBMTP_Get_Filemetadata
returns a null pointer which get dereferenced unconditionally
in line 9070.
This part of the function seems unchanged ups
Hello Miriam,
if possible, you could install the additional package
systemd-coredump. Then in the output of 'journalctl --no-pager'
at the bottom should the known 'segfault at' line appear.
This and the following lines at that time would be of interest.
This would get better if the additional nfs-
Hello Vincent,
I tried to find some more details about this issue.
In the regular case the resulting exe seems to link
to msvcrt.dll!_vsnprintf:
$ i686-w64-mingw32-objdump --private-headers test.c.exe
DLL Name: msvcrt.dll
vma: Hint/Ord Member-Name Bound-To
63e8 76
Hello Miriam,
thanks for the backtraces, just the one from "coredumctl gdb" is enough.
Have you by any chance a file "/etc/nfsmount.conf" at this system?
If there are no secrets inside, could you attach that too?
Kind regards,
Bernhard
Dear Maintainer,
I could reproduce the crash now in an minimal unstable VM with the
given config and the command line from the coredumpctl output.
It seems that the function conf_parse_line is not prepared
for missing quotation marks for the argument in the section head [1].
Therefore, if quotes
Hello Paul,
I am not involved in packaging kicad or wxwidgets,
just trying to collect some more information.
Could you recheck - could it be that this pid 309563
was still running from a previous kicad session and
your hanging kicad was another, newer process?
Because, I guess, the __run_exit_han
Hello Горбешко Богдан,
I am not involved in packaging samba but tried to get
some more details.
Currently smblcient fails with that message:
$ smbclient --user=testuser --ip-address=127.0.0.1 //testhost/C testtest
Unable to initialize messaging context
protocol negotiation failed: NT_
Hello luca,
this bug might be related: https://bugs.debian.org/948671
Kind regards,
Bernhard
Dear Maintainer,
I could reproduce this issue.
Upstream fixed this crash with this upstream commit:
https://gitlab.gnome.org/GNOME/gnome-logs/commit/7d0062a4ab36d457b74fe17b8d494570d4a0334b
A package build with this patch applied still crashes,
which got fixed in this upstream commit:
h
Hello Asher,
maybe you want to incorporate the changes given here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944431#31
Unfortunately I was too late there.
Then the call to e.g. SetThreadPriority would not needed to get
commented out, and the "-O0" fix in #944431 could be removed
again,
Hello Paul,
in that case I guess kicad is really trying to leave
the process for some reason.
That reason is maybe written to stdout. Therefore maybe you
can run kicad from a terminal and attach its output.
Probably that could give any hints.
Otherwise maybe it is related to the used desktop envi
Hello Jean-Luc,
thanks for your information.
Please use the reply-to-all button to have the
information forwarded to the bug report.
Am 08.01.20 um 17:21 schrieb Jean-Luc Lacroix:
> Hallo Bernhard,
>
> My system only has a single GPU (Nvidia GTX 970, see attached config)
> installed on a robust
Dear Maintainer,
I could reproduce using linux-perf-5.2 and it is
also visible in linux-perf-5.4 5.4.8-1,
by just pressing enter.
The crash happens because in line 3172
function hist_browser__selected_entry returns
browser->he_selection, which is at this time a
null pointer.
This null pointer gets
Hello Gulfstream,
On Mon, 17 Jun 2019 11:17:48 +0800 (GMT+08:00) wg...@china.com wrote:
>
> I have install the proprietary nvidia drivers and it runs well.
>
Another user reported the same error and he had installed the nvidia
driver by their installer. He could solve the issue by uninstallin
Hello Asher, hello Markus,
sorry, I wasn't aware of that patch being applied at Salsa as
there was no more activity in 944431, so I thought it went
through unnoticed.
Sorry for the noise.
Kind regards,
Bernhard
Dear Maintainer, hello Benjamin,
the core seems at least related to the "Too many open files" lines.
Unfortunately I cannot get the whole backtrace (see below).
The crash seems to be the same as already reported in #851498, which
got forwarded to upstream in [1].
I guess in "Gnome - Settings - Pri
Sorry, forget the right email.
Forwarded Message
Betreff: Re: Bug#945814: audacity: various segfaults of audacity on startup
Datum: Tue, 14 Jan 2020 11:46:06 +0100
Von: Bernhard Übelacker
An: 945...@bugs.debian.org
Hello Tjeerd,
If this issue still exists on your system, you
Hello Tjeerd,
If this issue still exists on your system, you might try
to rename $HOME/.audacity-data to test if it depends on
some settings stored there.
If it still crashes then you might start it by following
and forward the output:
$ catchsegv audacity
Better would be if you could install
Hello,
I tried to locate the source line of the address shown
in the /var/log/messages output.
But that failed but I found in the strace output that
it loads for some reason two libapt-pkg.so files ...
...
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libapt-pkg.so.6.0",
O_RDONLY|O_CLOEXEC) = 3
Hello Valentin,
this looks similar to bug #953794, #953854 or #953880.
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
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,
tried to collect some more details.
Found that the failure started with the migration
of these packages into testing:
libvte-2.91-0 libvte-2.91-common (0.60.0-2)
The monitor worked before with 0.58.3-1.
Kind regards,
Bernhard
# Bullseye/testing amd64 qemu VM 2020-03-20
apt update
apt
Hello,
I just tried to get some more information from the
second dmesg line the submitter added.
I think it crashed inside function getmissingattr because
tupleDesc->constr contains an invalid pointer e.g. -1
Maybe this is of any help, but still a proper
backtrace or core would be better.
Kind r
Hello,
this seems to be caused by xrdp using glyph cache even
when the client does not advertise it.
Additionally freerdp does now stricter checks.
Upstream bugs are here [1].
A workaround could be to use xfreerdp like this:
xfreerdp +glyph-cache /relax-order-checks /v:hostname
Kind regards
Hello Andrew,
On Sun, 8 Dec 2019 15:17:45 -0500 Andrew Engelbrecht wrote:
> I was able to reproduce and to get a backtrace, which I attached to this
> email.
Your backtrace with full debug symbols should read like below [4].
This seems to point to the upstream issue [1].
Unfortunately I could
Hello Christian,
if you still see this crash, maybe you could install the
package systemd-coredump.
If then a process crashes again some more information
should be visible at the end of:
journalctl --no-pager
Kind regards,
Bernhard
Hello Ludovic,
I tried to collect some more information from your crash dump.
With debug symbols this backtrace should look like below.
I guess you are running a nvidia graphics card
with the nouveau drivers?
As a workaround it may work if you start the client
from a terminal by following:
e
Hello Mladen Mijatov,
if you still get this crash, maybe if you start it like below
there would be more information about the crash.
catchsegv gnome-control-center
Alternatively you could install systemd-coredump and look
at the end of 'journalctl --no-pager' if there is some debug
informatio
Hello local10,
if you still get this crash, maybe if you start it like below
there would be more information about the crash.
catchsegv gnome-control-center
Alternatively you could install systemd-coredump and look
at the end of 'journalctl --no-pager' if there is some debug
information of th
Control: tags -1 + patch upstream fixed-upstream
Hello Mladen Mijatov, dear Maintainer,
the first frames would be translated by addr2line to following [1].
This looks like the crash is caused by an invalid pointer pself/self
in function cc_display_mode_dbus_is_supported_scale [112].
This pointer
s=run_dtors@entry=true) at exit.c:108
#10 0x77c87eba in __GI_exit (status=) at exit.c:139
#11 0x555883f6 in main (argc=, argv=,
env=) at perlmain.c:166
(gdb) kill
Kill the program being debugged? (y or n) y
[Inferior 1 (process 607) killed]
(gdb) q
cd /home/ben
Hello David,
I fear that output is not sufficient for that
type of application.
Maybe you could install following packages:
thunar-dbgsym gdb libglib2.0-0-dbgsym libgtk-3-0-dbgsym
For this you would need to add a matching package archive
like described in this link:
https://wiki.debian
Hello Jack Barns,
I am not involved in packaging spacefm, but just tried
to reproduce the issue. "Unfortunately" for my test it
did not freeze.
If you still can reproduce it, maybe you can execute
following command while a single spacefm process is in
the system and hangs:
script -a "spacefm-
Package: libc-bin
Version: 2.29-3
Severity: wishlist
Tags: upstream patch
Dear Maintainer,
since upstream commit in 2012 [1] the function __backtrace_symbols_fd
seems to outputs in one of this formats:
program(+)[]
program(function+)[]
Therefore the /usr/bin/catchsegv cannot find the ba
Dear Maintainer,
while I was at it, I attempted to change the output to
deliver the before mentioned information for addr2line too.
Attached is a improved patch, that would now output following:
Backtrace:
[0x55f317f9175b] main at
/usr/share/doc/libsoxr-dev/examples/3-options-input-fn.c:79 (dis
Dear Maintainer,
sorry, did attempt to output the build-id unconditionally,
fixed in attached patch version.
Kind regards,
Bernhard
>From 0a4a73d4eeaa45acdbeb6ea8fea878e134cbc11b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?=
Date: Wed, 11 Dec 2019 19:56:39 +0100
Subject: Ma
Hello Adrian, hello Paul,
I could reproduce the issue in a minimal
revertable Unstable qemu VM with this command:
/usr/bin/autopkgtest libsoxr -- null
As far as I see the test is called this way:
src/debian/tests/inst-check
src/inst-check
src/inst-check-soxr
$gen
Hello Karl,
I am not involved in the packaging of phonon, but
still a few questions.
Have you any Qt4 applications installed?
Because src:phonon in version 4:4.10.3-2 was the last
version that built the Qt4 parts.
Since src:phonon 4:4.10.3-3 just the Qt5 packages
get build anymore.
And therefor
Control: tags -1 - upstream
Hello Felix,
maybe the information from following bug is
relevant in this case too.
https://bugs.debian.org/942860
Kind regards,
Bernhard
Package: stops
Version: 0.3.0-2
Severity: wishlist
Dear Maintainer,
I was trying to look at 943335, tried to look at it
with the rr debugger which is in the archive just for amd64.
Therefore tried to install aeolus:i386 which required
a package stops:i386.
Marking stops as 'Multi-Arch: foreign'
(Forgot to attach some more debugging details.)
From submitter
Dec 12 09:40:11 lambda kernel: [55486.381334] iwd[202645]: segfault at 38 ip
55b1995e2056 sp 7ffc966c5360 error 6 in iwd[55b1995c4000+84000]
Dec 12 09:40:11 lambda kernel: [55486.381374] Code: 48 83 c4 20 e9 58 fe ff ff
0f 1
Control: tags -1 + upstream fixed-upstream patch
Dear Maintainer,
I tried to have a look at this crash
and I guess I found something.
The "Code:" sequence points to src/scan.c:1706.
There it seems like variable sr got a null pointer
and therefore the assignment crashes.
(gdb) list src/scan
Hello Daniel,
Am 12.12.19 um 18:27 schrieb Daniel James:
> Hi Bernhard,
>> Marking stops as 'Multi-Arch: foreign' should make
>> that installation possible.
>
> The package 'stops' contains binary instrument data, which as far as I
> know, is uniquely created by the undocumented and well-hidden i
Dear Maintainer,
I tried to have a look at this issue. I got this also on amd64 [2].
It looks like this is related to aeolus requesting its
memory never getting swapped out. [1]
Without this line a process does not give this fault.
But there is a "max locked memory" of 65536 kbytes
in place (ulim
Hello Jesús,
> Version: 2.10.12-0.1~mx19+1
Could not find a dbgsym package for that gimp version.
Is your system a MX Linux installation or a plain Debian?
At least in the first case, I guess, the MX Linux forums
can give better support.
And if the crash is reproducible it would help if you
coul
Hello Wolfgang,
I am not involved in packaging wine in debian, but
may have some hints.
Unfortunately I could not find any download for a trial version,
is there one known? Otherwise this can just be debugged
by users having access to that software.
Then a file containing some more output could
Dear Maintainer,
tried to reconstruct the given backtrace with debug symbols
in a gdb session and came to following, maybe it could be
of some help.
(Still a proper backtrace with dbgsym packages
installed would be better.)
Kind regards,
Bernhard
Reconstructed:
#0 0x7f78b4cfb92f in gnutls_a
Hello Wolfgang,
Am 16.12.19 um 11:42 schrieb Wolfgang Rosner:
> Hi Bernhard,
>
> Thanks for the debug instructions.
>
> I'll go to try them, maybe the next weekend.
>
> Notes is an essential tool of my daily work, so extended trials block
> me from productive offfice work for some hours, since
Hello Wolfgang,
Am 16.12.19 um 18:18 schrieb Wolfgang Rosner:
> -8<---
> script: Ungültige Option
> -- Try 'script --help' for more information.
> -8<---
Sorry, there was a -a too much inside the quotation marks.
> I get a log file of 13 MB in Size.
>
Dear Maintainer,
I just tried to reproduce the crash but did not get it.
Maybe some more details of the configuration details of
host.cfg and DNS server setup could help,
because in my test I never reached with my IPv6 config
the faulting instruction.
At least the instruction, at that address wher
Hello Wolfgang,
could you please count how many true type fonts you have installed,
e.g. by 'find /usr/share/fonts/truetype -iname "*.ttf" | wc -l'.
Because in a minimal test environment the application started to
behave strange after that number went over ~1250.
That test was done with these deb
Hello Dave,
I am not involved in packaging lshw, just looking
at some random crash bug reports.
First, when reporting crashes that line from dmesg is most
of the time not sufficient. Therefore a simple way to retrieve
some more information could be to run it by 'catchsegv lshw'.
Better woudl be i
Control: tags -1 + upstream
Control: forwarded -1 https://www.ezix.org/project/ticket/755
Dear Maintainer,
I tried to forward this issue upstream, where it is tracked
in this bug report: https://www.ezix.org/project/ticket/755
Hope it is ok to set this bug to forwarded.
Kind regards,
Bernhard
Control: tags -1 + fixed-upstream patch
Dear Maintainer,
upstream fixed this issue in git by following commit:
https://ezix.org/src/pkg/lshw/commit/89b3b6b9ed03f22ca98954712db5a90acf2c6755
Kind regards,
Bernhard
Control: reassign -1 zynaddsubfx-dssi 3.0.3-1
Control: affects -1 + audacity
Hello Tjeerd,
> Thanks for coming back, I'm not in a hurry...
>
> The problem is that I can not trigger specific bugs (they seem to happen
> somewhat random). So a made some more valgrinds: valgrind.dat
Because the e
Dear Maintainer,
today I received this stack smashing also in one of my VMs.
I could reproduce the isse when ever a bash is started
while 2.29-7 got started and left open.
Then in a different shell the packages get upgraded,
especially glibc packages to version 2.29-9.
Then get back to the open
Package: grub-common
Version: 2.04-5
Severity: wishlist
Dear Maintainer,
I noticed some moths ago a delay between Grub gets
started ("Welcome to GRUB!") and Grub shows the menu.
I switched a few days ago from stable to Bullseye/testing
at this device and tried to find out where this 23 seconds
de
Control: found -1 plasma-workspace/4:5.14.5.1-5
Dear Maintainer,
I found today another device affected by this issue.
It got switched a few days ago from stable to current testing.
It shows the same 30 second splash screen.
A package build with the given patch did show the
splash just 14 seconds
Hello Md Ayquassar,
sorry, I did not recognize that you
seem to have a usrmerge'd system.
Then I get following backtraces from your
core dump, with and without debug symbols.
It looks like a function pointer gets called
unconditionally, while containing NULL.
Seems to be graphics driver related.
Hello Md Ayquassar,
Am 31.01.20 um 02:23 schrieb Md Ayquassar:
> Second, is a reassignment to some Mesa package required?
I guess mesa maintainer would have more insight if
that function pointer is allowed to be NULL, there
possibly yes.
I wonder if the content of /var/log/Xorg.0.log* would
re
Hello Birger Schacht,
I tried to get some more information from this issue.
To be sure where your tilix aborts you would need to
install gdb and at least tilix-dbgsym [1] and
run it this way:
gdb -q -ex 'set pagination off' -ex run -ex bt -ex detach -ex quit --args
tilix
Then I guess you se
Dear Maintainer,
I found this upstream bug report [1].
The SIGILL causing instruction seems to consist
just of four zeros. [2]
The instruction before is [3].
Version 68.4.2esr-1 in unstable does not show this crash.
Kind regards,
Bernhard
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=16095
Hello Jan,
your issue might originate not from the terminal but from su itself.
This might be an interesting read:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904988#20
But in short, is instead of 'su' using 'su -' working
for you like expected?
Kind regards,
Bernhard
Hello Jan,
please leave the bugs email in the recipients or cc list to
have all information attached to the bug e.g. by using "reply all".
Nice to hear it works.
You can close a bug by just changing the email recipient from
'950...@bugs.debian.org' to '950537-d...@bugs.debian.org'.
Kind regards,
Control: reassign -1 libc6 2.29-9
Control: affects -1 bash
Dear Maintainer,
reassigning to get hold of libc6 maintainer about the issue
of incompatible tunables indices between libc6 versions.
Therefore applications could crash when libc is from
previous package version, then a package update ge
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 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
>
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 Sarah,
I am sorry, but the given information might not be enough
for the maintainers to solve the crash.
Usually when a segfault happens in 'dmesg' output should
appear two lines about this event. Maybe you could forward
these to the report too.
If it is possible to install systemd-coredump
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,
Dear Maintainer,
I tried to collect some more information and got
the following backtrace with the restore command
from the submitter.
It looks like "expr->ops" contains a null pointer
that gets dereferenced.
Unfortunately I still see the same crash after
upgrading to the versions in backports in
701 - 800 of 1320 matches
Mail list logo
