Dear Maintainer,
I tried to have a look at this issue and could reproduce
it in a buster amd64 qemu VM.
But this is also observable with current Bullseye/testing.
This seems to be based on the fact that all xfce4-terminal
windows are owned by the same parent process.
I could observe if a second
Hello Jason,
one small additional note. The dmesg lines you provided would have been
followed by lines "Code:". With that line it would be possible to
find at least the current instruction and source code line when the
executables are from the debian archive and the package version is
known. So
Hello Ronny,
sorry for the delay.
You wrote you recompiled - then I guess your build directory should
also contain the libcups2-dbgsym and cups-daemon-dbgsym packages.
If you still get this crash, could you install these dbgsym packages
from your build and recreate that backtrace in coredumpctl?
Hello Karsten,
Am 21.08.20 um 18:21 schrieb Karsten:
>> Unfortunately I did not get the message
>> "Gesamte Anfrage zu gross" / "Request Entity Too Large".
>
> Hmmm - there are many details not working in Debian 10.
> Maybe because this version has been upgraded.
>From which debian version did
Dear Maintainer,
I tried to collect some more information about this issue
and could reproduce it (details in attached file).
It looks like this issue appears just when running
gkrellm within XFCE.
The issue also shows in current testing.
When switching gkrellm to the external downloadable
theme
Hello Karsten,
I am no involved in the packaging cups but I tried to
reproduce your cups issue inside a minimal VM.
Unfortunately I did not get the message
"Gesamte Anfrage zu gross" / "Request Entity Too Large".
Therefore it seems you need to supply some more informations like
- with which user
Dear Maintainer,
the attached file in message #5 contains
a backtrace with this part [1].
I am quite sure that the call to __fdelt_chk in g_spawn_sync is
at this source location [2] in gspawn.c line 442.
Because __fdelt_chk checks if the fd outpipe is either
negative or below FD_SETSIZE, and
Package: rr
Version: 5.3.0-2
Severity: normal
Tags: upstream fixed-upstream
Dear Maintainer,
while investigating a different bug I found rr failed for
me inside a current testing VM inside a call to clock_getres,
while inside a similar stable VM it succeeds.
I think this got reported and fixed
Hello Max, hello Simon,
after some sleep I thought why this next variable gets assigned
that soon ... so I tested following patch, which just moves the
assignment to below the process call, and I could not reproduce
the crash in some guake restarts.
If this is enough, or if the garbage collector
Hello Max, hello Simon,
I thought this issue might be a case for mozilla/rr, a time-travel-debugger.
It allows record a process and then replay that process forward and backward
inside a debugger.
And the segfault was reproducible within rr.
Attached file contains some notes about my test
Hello Stefan, hello Patrick,
I am not specifically involved in packaging sane but tried
to reproduce your issue.
These were the steps I tested:
- systemctl enable saned.socket
- systemctl start saned.socket
- activated the backend "test" in /etc/sane.d/dll.conf
- added the "remote" server
Hello Novak Frantisek,
I am just trying to reproduce crashes on random packages,
so I tried on this bug report, too. But I was not able
to come anywhere near the crash you are describing.
You might want to add some more information to that report,
about which TPM version you have 'dmesg | grep -i
Dear Maintainer,
I tried to have a look, but can just tell the location,
the dmesg output points to, is the following location.
And at this point the register rdi contains the value of "this",
at the submitters system 0x50, therefore causing the segfault.
Maybe install debug symbols and running
Hello Michel Le Bihan,
found this issue interesting and tried to get more information.
First the "trap int3" originates from here [1], and seems just
a consequence of missing packages.
When installing following packages the user interface
could successfully start, without changing the VM vga
Dear Maintainer,
following is a backtrace where the crash happens.
This seems to affect just stable.
Testing shows a permission denied warning.
By default it seems iptables is not contained in the path,
nevertheless it crashes when executed by full path.
Kind regards,
Bernhard
Program received
Dear Maintainer,
after additionally re-reading the merged bugs I think I
realized that function IsChromeOs searches the line "NAME=...",
but finds the line "PRETTY_NAME=...",
which overflows the variable os_name.
Kind regards,
Bernhard
Dear Maintainer,
I was able to reproduce this issue, kind of.
I guess the debian release name stored in /etc/os-release is too long.
Therefore in /usr/lib/cups/filter/hpcups in function IsChromeOs
the local array os_name with length 30 is overwritten by 1 byte.
At least that issue I received
1d8 <__xstat64+88>: jmp*%eax
(rr) print true_xstat64
$1 = (int (*)(int, const char *, struct stat64 *)) 0x0
Description: Force initialize for xstat64
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/964458
Forwarded: no
Last-Update: 2020-08-15
Index: checkinst
Dear Maintainer,
I could reproduce it inside a i386 VM and found the crash
happens in [1], when it tries to dereference the "state".
This state is retrieved from the renderer of type _PangoRendererPrivate.
I tried to follow where this state is last set and found
this memory is last written in
Dear Maintainer,
encountered again such a crash of a bash that was started
while the old libc6 was installed, then installed a libc6 update,
and then the "old" bash crashed after a tab completion.
libc6:amd64 (2.30-8, 2.31-3)
bash:amd64 (5.0-6, 5.0-7)
Kind regards,
Bernhard
$ cp log*** stack
ame':
ScottCurses.c:696:17: warning: format '%d' expects argument of type 'int *',
but argument 4 has type 'short int *' [-Wformat=]
fscanf(f,"%ld %d %hd %d %d %hd\n",
~^
%hd
,
~
##
cd /home/benutzer/source/scottfree
Dear Maintainer,
this bug sounds similar to this one:
https://bugs.debian.org/927163
Kind regards,
Bernhard
Dear Maintainer,
this bug might be related to bug #940839.
At least the frames Json::Reader::parse appear there too.
Kind regards,
Bernhard
Dear Maintainer,
bug #925424 seems to be about the same issue.
Kind regards,
Bernhard
Am 02.06.20 um 16:06 schrieb Mail Delivery System:
>The mail system
>
> : host mx.wowway.com[64.8.71.111] said: 550 5.1.1 [R2]
> Recipient n...@wideopenwest.com does not exist here. (in reply to RCPT TO
> command)
My email could not be delivered to the submitter.
Hello nbi,
I am not involved in packaging gimp, but
this might be related to the debian-multimedia
packages you have installed:
> ii libbabl-0.1-01:0.1.74-dmo1
> ii libgegl-0.4-01:0.4.16-dmo1
Is this error also visible when using these packages
from the debian testing
Hello Stephen,
Am 31.05.20 um 22:52 schrieb Stephen Kitt:
> On Sun, 31 May 2020 18:03:01 +0200, Bernhard Übelacker
> wrote:
>> Unfortunately I found recording not working in a small test [1].
>>
>> A git bisect led to a helper function introduced by upstream in
Package: rr
Version: 5.3.0-3
Severity: normal
Dear Maintainer,
thank you for building i386 again.
Unfortunately I found recording not working in a small test [1].
A git bisect led to a helper function introduced by upstream in [2].
This helper uses a function parameter of type off_t.
But the
Package: rr
Version: 5.2.0-4
Severity: wishlist
Dear Maintainer,
in bug #915337 the i386 support got dropped because of
the i386 baseline violation.
Would it be enough to depend just on i386 on
the package sse2-support.
That way the user gets an error when attempting to install
on an
Dear Maintainer,
tried to reproduce the steps and found neovim crashing too.
Used a minimal testing VM, created a test video with ffmpeg.
This led to the backtrace below.
In the meantime someone created this upstream bug describing a
similar situation and showing the same backtrace:
Am 25.05.20 um 12:38 schrieb meht...@protonmail.com:
> While trying to get the core file I renamed "https" to "https.bin" and
> created a shell script "https" which had "ulimit -c unlimited;
> /path/https.bin $@"
> or something like that..
Another way to receive core files might have been to
Dear Maintainer,
I tried to collect some more information and found that
version 0.9.3-1+b1 got built against
libboost-python1.67.0 in version 1.67.0-10.
Up to 1.67.0-11 this package provided both, a lib *python36* and *python37*.
Since 1.67.0-12 it looks like there is just a *python37* lib.
A
Hello Peter,
I am not involved in packaging cups, just trying to help
to collect some information.
If possible you could install the package systemd-coredump.
Then in the journal might then appear additional information
where the problem occoured, that could help identifying the issue.
Kind
Dear Maintainer, hello Mehturt,
I guess the missing debug information is contained in libcurl3-dbg [1].
I tried to find out to which line this address in Mehturt's backtrace
points to and came to this location:
(gdb) bt
#0 0x777cd4d7 in Curl_close (data=0x5579f6c0) at url.c:399
Dear Maintainer,
if a targetted fix for buster would be desired, following
upstream commits seem to be the last changes to the
download URL in question.
https://github.com/Winetricks/winetricks/commit/ac51cdb pptfonts: use a
helper function
> On Tue, 2020-05-19 at 22:05 -0300, Mauro Dionisi wrote:
> > Versions of packages mkvtoolnix-gui depends on:
> > ii libebml4v5 1:1.3.9-dmo0+deb9u1
> > ii libmatroska6v5 1:1.4.5-dmo1
Hello,
might this be related to the above packages being
from the debian multimedia
Hello Md,
not involved in packaging or development I was just trying
to collect more information about the crash for the maintainer.
I guess reassigning might not be a bad idea and might
give some feedback.
Another option would be to open an issue in the upstream
bug tracker (please put links here
Dear Maintainer,
I further tried to get some more logging output by "set debug=all".
There I found that the loopback command actually returns after
around 2 minutes for my 335 MB ISO file.
>From the logging is looks like the whole ISO is read
to memory, if the tpm module is loaded.
If it is not
Dear Maintainer,
I could reproduce this issue with these grub images
inside a QEmu EFI enabled VM (no secureboot enabled).
grub-efi-amd64-signed: /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
grub-efi-amd64-bin:/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi
Further tried to track it
Dear Maintainer,
the given backtraces are similar to the ones attached in this message:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955747#15
Kind regards,
Bernhard
Hello Francisco Gómez,
not deeper involved in packaging of gdm3, I might have a hint
to get a better backtrace from the core file.
You seem to opened the core just with gdb, therefore the
backtrace is lacking module information.
Could you please add the executable to the gdb command line e.g.
control: found -1 1:4.2.9.7-3
control: notfound -1 4.2.9.7-3
Dear Maintainer,
I tried to collect some more information form the backtrace at
the end of the information in the submitters linked diagnose.
Below are the source locations where the backtraces points to.
Kind regards,
Bernhard
Dear Maintainer,
if it may be of any help, below is the backtrace from
the submitter, with line information manually added.
Could not find a complete match in upstream bugs, just one
mentioning OpenCL is not yet stable - is this still the case?
Kind regards,
Bernhard
0x779c0398 in
Dear Maintainer,
looking at the backtrace from message 13 and at the changes
done by upstream, following commit sounds related:
https://github.com/OpenPrinting/system-config-printer/commit/b9289dfe105bdb502f183f0afe7a115ecae5f2af#diff-d3f2f90b6e176486d4b8dfe3222577f7
Kind regards,
Bernhard
Dear Maintainer,
I could reproduce the issue on i386 and tried to collect
some more information.
It crashes with the backtrace below.
The crash seems to be caused by using the wrong data type
in the calls to variadic functions goo_canvas_ellipse_new
and goo_canvas_polyline_new.
The
Dear Maintainer,
I tried to have a look at the first call stack, and
could reconstruct it using the dbgsym package to the
backtrace below.
@Bob Ham:
could you supply some information about the CPU you are using.
If it is an AMD Ryzen 3xxx the first two links below might describe
your issue and
Sorry, the file I attached in message #10 was for a
different bug, unrelated to this one.
Created upstream bug: https://bugs.ghostscript.com/show_bug.cgi?id=702346
merge 934680 934770
Dear Maintainer,
I tried to extract from the submitter's dmesg line the
source location of the crash.
I assume it happened here [1], with
variable s containing an invalid pointer:
0x77f5bb90 in update_rx_timing at t38_gateway.c:2244
2242 static void
Dear Maintainer,
I tried to have a look and it looks like being related
to the libgrpc++1 package.
The _ZN4grpc13ClientContextC1Ev symbol was included in
libgrpc++1 versions up to 1.17.2-1.
Since version 1.22.0-2 it is missing from that library.
Because 1.26.0-2 is the first version after
Hello Felix Rublack,
I do not know if the maintainer are able to reproduce this issue,
but instead or additional to the strace a backtrace of the crash
might help them. The easiest way might be to install systemd-coredump
and look at "journalctl -e" after a crash. More info in [1].
(Even better
Dear Maintainer,
I observed such logging, too. My system is similar to the submitters one.
Found two occourences in still available kern.log* files. (See attached file.)
One was most probably related to a "GPU fault" 25 seconds before,
running 4.19.0-8-amd64/4.19.98-1.
The other was while not
Hello,
tries to find a way to underclock the gpu of an HP elitebook 8460p
with a radeon HD 6470M, because it does not handle well the 3d
requirements of a current plasma desktop and leads to the laptop
turning just off. (Turning off the compositor as a workaround.)
So "rovclock -i" leads on that
Package: kodi-bin-dbgsym
Version: 2:18.6+dfsg1-1
Severity: normal
Dear Maintainer,
I attempted to add line information to bug 954782.
Unfortunately I found that kodi-bin-dbgsym does not contain
the debug information for the kodi-x11 binary.
It does just contain debug information for
kodi-xrandr
Hello Michael,
that is great news, just two points I want to mention:
If you want to forward information to certain people,
please send email to both, the bugs address and the person,
e.g. use "reply all" in your mail client.
And if you get e.g. "/lib/libdislocker.so.0.7" in your backtrace
> #6 0x5614726b3f04 in gimp_param_spec_layer_id ()
> #7 0x5614725cea67 in gimp_pdb_compat_param_spec ()
> #8 0x5614725db487 in gimp_plug_in_handle_message ()
Hello Andre,
I think this is the same thing as #953880, #953854, #953794. Please
upgrade the gimp package to version
Dear Maintainer,
I tried to collect some more information and might have found something.
The allocator aborts at the backtrace below.
A valgrind run points to the same function txt_add_fragment.
There is seems that in line 2121 the allocation takes place with
12 bytes total, then a memset is
Dear Maintainer,
I tried to start looking at the given backtrace, but could
not find the winbind-dbgsym packages for 2:4.9.5+dfsg-5+deb10u1
like they are availabe for 2:4.9.5+dfsg-5.
At least apt did not find it in buster-proposed-updates-debug
and at snapshot.debian.org they are also not listed.
Hello Michael,
I am not involved in packaging dislocker but might have some points.
This "error 14" should mean it cannot read from memory the next
instruction to execute. This makes sense as the "ip" or "RIP" has
a value of 0xbb6 which is unlikely to contain program code.
If it is possible to
Hello Gulfstream,
> Thanks for your reply! My next question is How to connect the xrdp server
> using remmina client? I don't find where to set the glyph cache.
in the previous mentioned upstream link to the remmina bug
tracker in comment [1] is written that they added such flags,
but I guess
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
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
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
Hello Till,
I am not the initial reporter of the issue and I cannot reproduce it,
therefore cannot test the suggested change.
Just tried to share my results.
Kind regards,
Bernhard
Hello,
the stack trace should look like this with line numbers, if it helps:
0x7...671 in __strlen_avx2 at
../sysdeps/x86_64/multiarch/strlen-avx2.S:65
0x7...2f4 in _cups_strlcpy at string.c:739
0x5...a31 in main at rastertopwg.c:274
0x7...e09 in __libc_start_main
Hello Valentin,
this looks similar to bug #953794, #953854 or #953880.
Kind regards,
Bernhard
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) =
Package: cups
Version: 2.2.10-6+deb10u2
Severity: normal
Dear Maintainer,
I found today some suspicious segfault line in dmesg output and
could reproduce it every time I loaded the finished jobs of a printer
with this URL:
Dear Maintainer,
I tried to debug this issue.
(gdb) bt
#0 tidy_path (path=0x55f0c81ea140 "/../") at symlinks.c:96
#1 0x55f0c7fe6908 in fix_symlink (my_dev=2049, path=0x55f0c81ec1e0
"/tmp/tmp.tlVVwIgOZQ/mylink") at symlinks.c:185
#2 0x55f0c7fe6e81 in dirwalk
Hello Tomas,
Am 16.02.20 um 17:30 schrieb Tomas Janousek:
> So unless that palloc tries to allocate way more memory than it should,
> I don't think that's the problem.
Unfortunately that allocation seems just "sizeof(pr_response_t)",
so I guess it is not an unusual big allocation.
Kind regards,
Dear Maintainer,
I just tried to reconstruct the line informations from a
running process with an attached gdb and installed dbgsym package.
0x7f373b3ad458 in __memset_sse2_unaligned at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:120
0x55d7e2f68a64 in pcalloc at pool.c:620
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
Hello Thorsten,
Am 06.02.20 um 19:19 schrieb Thorsten Glaser:
> On Thu, 6 Feb 2020, Bernhard Übelacker wrote:
>
>> Hello Thorsten,
>> getting the source of such an address is possible, even with ASLR,
>> if the library versions are known and dbgsyms are available,
Hello 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
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,
Hello Jonas,
thanks for taking time for this bug.
Am 05.02.20 um 11:02 schrieb Jonas Smedegaard:
> Hi Alexander,
>
> Quoting Alexander Reichle-Schmehl (2020-02-05 08:45:05)
>> Am 2020-02-04 22:09, schrieb Jonas Smedegaard:
>>
>>> Most notable change between 9.22 and 9.24 - and also applied to
Control: fixed -1 9.26a~dfsg-0+deb9u6
Control: fixed -1 9.26a~dfsg-0+deb9u1
Control: fixed -1 9.25~dfsg-0+deb9u1
Control: found -1 9.27~dfsg-3.1
Control: found -1 9.27~dfsg-3
Control: found -1 9.26a~dfsg-2
Control: found -1 9.26a~dfsg-1
Control: found -1 9.26~dfsg-2
Control: found -1 9.26~dfsg-1
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
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,
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
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]
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
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
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.
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
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
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
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
Hello Tjeerd,
sorry for the delay.
I would have expected more output from catchsegv.
I guess the first valgrind run would have been better
placed in an attachement too.
The file audacity_coredumps.log points to
libzynaddsubfx_dssi.so that belongs to package zynaddsubfx-dssi.
That seems to be
Hello Paul,
> That was my first thought; as explained in my initial bug report:
>>> If run from the terminal there is no printed output of any kind.
Sorry I missed that one.
>> Otherwise maybe it is related to the used desktop environment,
>> if xorg or wayland is in use
>
> I'm using xorg and
Dear Maintainer,
crash happened again today when stopping a qemu VM with
the quit command at the qemu prompt.
Found the "refcount_t: underflow" already once at 2020-01-07,
but there the system could continue to run more than a day.
All occourences are with:
[0.00] Linux version
Dear Maintainer,
a short addition. I got some help that AddressSanitizer
and Valgrind could be squeezed to delay returning previously
free'd addresses from the allocator.
Then both tools point to the mentioned first allocation directly.
Kind regards,
Bernhard
AddressSanitizer: export
Control: forwarded -1 https://marc.info/?l=linux-kernel=157973791626377=2
Control: tags -1 + upstream
Hello Salvatore,
thanks for the link.
I tried to get in contact with upstream.
Kind regards,
Bernhard
https://www.spinics.net/lists/kernel/msg3384013.html
Dear Maintainer,
I tried to look into this issue without being involved
in packaging fontforge.
I found it most reproducible when building with
"-fsanitize=address", and then always failing on accessing
the same address. [1]
As far as I see this is what happens:
- Address 0x6048a210 gets
Hello Salvatore,
> Can you report the issue directly upstream?
Will do, but I am not sure exactly to where.
I found the MAINTAINERS file and I guess if there
is no "B:" line it has to be reported to the "L:" list ?
Kind regards,
Bernhard
Hello Jamie Heilman,
I just tried to retrieve some line information from the backtrace.
Unfortunately I could not match the addresses with the
binary from the debian repository.
Was this backtrace by any chance built with a local
rebuild of the xserver-xorg-core package?
Kind regards,
Bernhard
Hello Md Ayquassar,
could you please additionally run following and attach the
output to this bug:
reportbug --template gnome-shell
I am asking because trying to open the coredump shows
following warning inside a minimal uptodate Buster/stable
VM, which could point to a incompatibility of
Hello Bernd,
I could further isolate the cmake failing issue.
It starts failing when the package qtbase5-dev is installed.
This gets installed as build dependency for libgps26.
A workaround would be to temporarily uninstall qtbase5-dev.
Maybe better would be to add following to navit to
allow
Hello Bernd,
my navit know-how is also limited, but I remebered I saw this
while having build-deps of navit and libgps installed.
Below are the packages which got installed additionally in
a minimal test VM on top of navit's build-deps.
If there are just build-deps's of navit installed the build
Control: found -1 0.17.0-1
Dear Maintainer,
I tried to collect some more information and could
reproduce the issue.
I guess the interesting thread is not that with
the main function.
Instead it is that thread with the tox_kill / __GI_abort.
There I think that tox_kill in libtoxcore2 is reached
401 - 500 of 1271 matches
Mail list logo
