On Sat, 24 Feb 2024 23:55:18 + =?utf-8?q?Lucas_L=C3=B3pez?=
wrote:
I copied the example server file /usr/share/doc/vtun/examples/vtund-server.conf
into
/etc/vtund.conf and enabled server mode in /etc/default/vtun. When I start the
service
with systemctl I get the following error on the
Hello,
I found this one interesting and tried to reproduce it,
and hit this issue quite reliable with an unstable armel chroot,
inside an armhf unstable qemu VM,
or with a Android/LineageOS with real arm CPU.
Unfortunately valgrind is no longer built for armel, and a local armel rebuild
shows
On Wed, 08 Mar 2023 10:47:25 +0100 Laurent Bigonville wrote:
$ pkcon what-provides application/x-keepass2
Getting provides[=]
Loading cache [=]
Querying
at <0x>
at (wrapper managed-to-native) GLib.SList.g_free (intptr) <0x0005f>
at GLib.ListBase.Empty () <0x0013c>
at GLib.ListBase.Dispose (bool) <0xf>
at GLib.ListBase.Finalize () <0x0001d>
at (wrapper runtime-invoke)
Dear Maintainer,
I tried to reproduce this segfault.
Unfortunately this did not work as expected.
The segfault in multi-thread did not show up.
But I received one in multi-dict (in e.g. 3 of 6 runs).
This was done in a up-to-date unstable amd64 VM,
running at a AMD cpu, 16 threads given to the
On Wed, 14 Dec 2022 10:07:27 +0100 martin f krafft
wrote:
Package: scrcpy
Version: 1.24-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Running `apt build-dep scrcpy` and `fakeroot debian/rules binary`
results in plenty of
On Mon, 5 Dec 2022 21:33:03 +0100 martin f krafft wrote:
Package: scrcpy
Version: 1.24-1
Severity: grave
The package depends on libavdevice59, but it's apparently built
against libavdevice58:
lotus:~% ldd =scrcpy | grep libavdevice
libavdevice.so.58 => not found
Hello Martin,
can you
Forwarding, as the email from TJ possibly did not reach Felix.
On Fri, 21 Oct 2022 11:43:07 +0100 TJ wrote:
On Sat, 12 Feb 2022 08:21:55 + Felix Leimbach wrote:
> I noticed that vgamem_mb was still low (32 MB).
> So I changed to this (slightly wasteful) command-line and am now running
Am 01.01.23 um 16:55 schrieb Uecker, Martin:
This is likely a numerical error caused by reordering a
floating point sum by parallelization. It is not worth
spending time on it.
I can apply the patch, but I do not have much time now.
Is there some urgency?
Not from my side, I just tried to
Hello,
thanks for your immediate responses.
Am 01.01.23 um 15:55 schrieb Uecker, Martin:
One could just relax (or simply remove) the test from bullseye
or packport the version bookworm.
I guess that would be applying 0003-relax-failing-unit-test.patch
to the Bullseye version.
The wine
Dear Maintainer,
I could reproduce this failure in a bullseye VM.
There the "test_nufft_adjoint" fails in about 1.2 % of the runs.
Attached diff helps to make it more visible.
It looks like the float comparison fails because the
limit of "1.E-6f" is slightly not enough.
If interpret following
Am 18.12.22 um 16:58 schrieb Simon McVittie:
I was unable to reproduce this in a test VM, ...
..., but it is reproducible
on my laptop. Perhaps it's only reproducible if mutter has access to
some resource that my ssh login session to my test VM lacks, or perhaps
there's a race condition that
The software outputs: "No access to printer device file".
Normal user should be added to lp group to make `mtink` work
and it has been added to it indeed, so it is in the /etc/group file
beside the `lp` and `lpadmin` groups, yet the software seems
to be unable to access device file from the
After updating mesa from 22.2.0-1 to 22.3.0-2 (according to dpkg.log)
earlier today U.S. time as part of a routine upgrade to up-to-date sid,
the greeter stopped appearing, and over the course of the last two hours
we chased it down to that upgrade, which made X.org die with
iris_dri.so
Hello,
I tried to collect some informations.
The segfault happens because "workspace" contains a null pointer.
This null originates from "window->workspace".
Kind regards,
Bernhard
Core was generated by
`/usr/libexec/installed-tests/mutter-11/mutter-test-runner --all'.
Program terminated
Just a short addition:
There is already an upstream bug reported:
https://github.com/csound/csound/issues/1651
Kind regards,
Bernhard
Dear Maintainer,
this looks like caused by a disaggrement about the size of type OPARMS.
In libcsound64-6.0 it has 264 bytes, but in csound-plugins
only 260 bytes.
This difference is caused by the last member "mp3_mode", that is missing
in the OPARMS type used in csound-plugins.
It got
Dear Maintainer,
the original staden-io-lib seems to be built with
libhtscodecs2 in version 1.2.2-1 [1].
The rebuild seems to be using libhtscodecs2 in version 1.3.0-4.
Unfortunately htscodecs upstream integrated this commit [3],
which renamed e.g. function encode_names to tok3_encode_names.
It
Hello,
it looks like following line should expect the Get() call returning a nullptr,
which wxWidget documentation explicitly notes.
2079
wxTranslations::Get()->SetLanguage(wxLANGUAGE_DEFAULT);
I have raised this question to upstream here:
Dear Maintainer,
I tried to have a look and found unfortunately the dbgsym package
not containing useful files.
This seems related to CMAKE_CXX_FLAGS getting reset,
therefore loosing Qt related flags.
Before the application crashed already when trying to open
one leaf in the tree view, with the
Hello Christoph, hello tony,
#12 0x5586f25c0438 tucnak_crash (tucnak + 0xb0438)
#13 0x7febdc3589d4 z_sig_segv (libzia-4.36.so + 0x169d4)
#14 0x7febdaa3daf0 __restore_rt (libc.so.6 + 0x3daf0)
#15 0x7febd5ead5ee n/a
Hello Francisco, hello Albert,
this might be the same as in bug #996726
and not directly related to the nvidia driver.
I hit a crash in kwin_x11 with an AMD graphics card
and could workaround by installing
libkdecorations2-5v5_5.21.5-2_amd64.deb like
mentioned in #996726.
Kind regards,
Bernhard
On Tue, 28 Sep 2021 15:01:22 +0200 uninsubria.it
wrote:
example from 'dmesg' output:
[Tue Sep 28 11:05:22 2021] omshell[4604]: segfault at 0 ip 55623cdd06dc sp
7ffd5a2c7c78 error 4 in omshell[55623cd97000+45000]
Hello,
maybe you can add a few pairs of the
dmesg "segfault" and
Dear Maintainer,
I tried to have a look, but got no clue why a Unwind should take place
until I saw the old build log [1].
There I found this warning:
Levels.cpp: In member function ‘bool Levels::addLevel(const string&, int,
int)’:
Levels.cpp:118:1: warning: no return statement in function
Just for reference, why g++ does not error here,
this gcc bug might be interesting:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943
Kind regards,
Bernhard
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 Didier,
I have retried with the patch in #974828, but it still
crashed with the test files from this bug, therefore
I guess #974828 is similar but unrelated.
Then I took another look at the valgrind runs and found
that these invalid reads and writes also appear at amd64.
After some
Hello Ian,
Am 27.02.21 um 08:49 schrieb Ian Campbell:
On Fri, 2021-02-26 at 15:41 +0100, Bernhard Übelacker wrote:
The attached patch is an attempt to grow the buffer size
if the header changes on a new page.
This is just tested for the given crash, nothing more, therefore
there might be side
hpcups/HPCupsFilter.cpp:617
...
Description: Grow m_pPrinterBuffer if needed on each page
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/974828
Bug-Ubuntu: https://launchpad.net/bugs/1904318
Last-Update: 2021-02-26
Index: hplip-3.20.11+dfsg0/prnt/
Sorry missed your email.
Weitergeleitete Nachricht
Betreff: Re: Bug#974828: printer-driver-hpcups: SIGABRT with "free():
invalid next size (normal)" in HPCupsFilter::cleanup
Datum: Thu, 25 Feb 2021 17:03:02 +0100
Von: Bernhard Übelacker
An: 974...@bugs.debian.or
Hello Ian,
I tried to collect some informations for the
maintainer in the other report #972339.
Therefore I tried to reproduce this issue now too, because
my amd64 hardware is much faster as my armhf systems...
But I failed to reproduce maybe because I use the wrong ppd file,
or something else
Dear Maintainer,
a short addition.
The backtrace that I received building with CC=gcc-10 seems
to be the same as in #972665, therefore they might be related?
Kind regards,
Bernhard
Dear Maintainer,
I could reproduce this issue too.
Attached is a valgrind run showing one invalid write
and a gdb session showing the issue.
It looks like mallocs management data, which resides in the 8 bytes
before a returned pointer, gets overwritten and therefore
the free fails because
not be queried.
Therefore and because the last upstream version is from 2006
one might ask if this package is really still useful?
(At least on amd64?)
Kind regards,
Bernhard
Description: Get number of CPUs
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/966638
Forwarded: no
Last
Hello Kevin,
I don't know the details, but I guess there will no automatic
rebuild of baresip triggered on migration.
As far as I see [1], the only users of libre0 are
baresip and librem0, so I guess both might need a rebuild.
Maybe someone with more shared library packaging knowledge
might give
Dear Maintainer,
I could reproduce the issue and it looks like there is a ABI break
of libre0 because the size of struct sip_addr has changed
from 152 bytes to 168, and therefore overwrites the stack canary here [1].
A baresip built agains libre0 1.1.0-1 did not show this problem.
Kind regards,
Dear Maintainer,
I tried to track down the segfault and I guess it is related to
the usage of "-shared" when linking wminput [1].
Therefore, I guess, the resulting wminput binary is build like
a shared object instead of an executable.
A binary built without "-shared" shows a version info with
Dear Maintainer,
tried to have a look at this one, found the segfault [1],
and can point to the place where the pointer gets overwritten [2].
Unfortunately Valgrind or ASAN gave me not more details.
Kind regards,
Bernhard
[1]
Program received signal SIGSEGV, Segmentation fault.
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
On Wed, 16 Sep 2020 10:16:49 +0200 SZALAY Attila wrote:
> Hi Jean-Marc,
>
> Please check if a core file is available related to the segmentation
> fault. If there is any please make it available for me/us.
>
> Also, can you run syslog-ng-debun with the -r parameter and send the
> generated
Hello Jason,
> #0 0x7efbfb5f3204 n/a (libgtk-3.so.0)
> #1 0x7efbfb779a53 n/a (libgtk-3.so.0)
> #2 0x7efbfb779b11 n/a (libgtk-3.so.0)
> #3 0x7efbfb779ff1 n/a (libgtk-3.so.0)
> #4 0x7efbf96c38ee ffi_call_unix64 (libffi.so.6)
> ...
I assume you updated inkscape to current
Dear Maintainer, hello Bruce Momjian,
with the last informations the issue is perfectly reproducible.
It looks like a use after free caused by statically stored
function pointers in libengine-pkcs11-openssl / libp11.
That led to following upstream bug:
Hello Bruce Momjian,
thanks for the details and confirmation.
Am 05.09.20 um 17:32 schrieb Bruce Momjian,,,:
> (gdb) print pmeth->init
> $1 = (int (*)(EVP_PKEY_CTX *)) 0xf0e0d0c0b0a0908
> gdb) print *pmeth
> $8 = {pkey_id = 50462976, flags = 117835012, init =
Dear Maintainer,
I tried to reproduce this fault, but did not get a segfault.
However, I think the backtrace points to these lines:
(gdb) bt
#0 0x7769dbce in int_ctx_new () at ../crypto/evp/pmeth_lib.c:160
#1 0x7769dcfa in EVP_PKEY_CTX_new () at
Dear Maintainer,
the patch "949003_explicit_extern_declaration.patch" attached in [1],
should help against the exact issue this bug is about.
Kind regards,
Bernhard
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949003#35
Hello Jason,
thanks for the information, just some notes before.
You might want to use reply all, otherwise the answer
might get through unnoticed.
And for some reason your email did not convert sufficiently
to plain text for some reason, so it appears kind of
short at
Dear Maintainer,
my d knowledge is very limited, but it looks like a d runtime library
tries to do some destructor calls at process exit.
Unfortunately that tries to get a mutex lock, but that fails with
EOWNERDEAD, therefore then hits the assert(0) in maybe [1].
If that assert(0) just translates
Hello 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
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
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
> 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
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,
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
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
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
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
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
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
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
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
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 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 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
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
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
5
<+261>: pop%r12
|| ...637
<+263>: pop%r13
...639
<+265>: pop%r14
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
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.
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
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:
Dear Maintainer,
the given valgrind backtrace should translate to something
like below (which did not crash for me).
The crashing instruction tries to read memory pointed by register $rdi,
that held in my test the address in parameters "v" / "key" / "name".
So I assume for some reason this
Dear Maintainer,
I tried to have a look and might have found something.
The crash happens because coroutine_stack_init returns NULL.
This is because of a buffer size check.
Building a package with doubled "DEFAULT_STATE_SIZE" went
through without crash (just tested on aarch64).
However, I am
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
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
(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
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
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:
Am 07.12.19 um 18:20 schrieb Colin Watson:
> On Sat, Dec 07, 2019 at 04:52:19PM +0100, Bernhard Übelacker wrote:
>> I could reproduce the issue in a i386 qemu VM with
>> a downgraded 3.16-3-686-pae kernel.
>> Attached file contains a debug session.
>>
>> At the
Dear Maintainer,
I could reproduce the issue in a i386 qemu VM with
a downgraded 3.16-3-686-pae kernel.
Attached file contains a debug session.
At the sysenter instruction in function shmdt
the signal SIGSYS is received.
Kind regards,
Bernhard
(gdb) bt
#0 shmdt (shmaddr=0xb774) at
Control: tags -1 + upstream patch
Dear Maintainer,
I tried to have a look into this issue and guess I found something.
It looks like the application is exhausting its stack by
allocation an integer array with maxpid elements.
At least in my test VM this leads to 16 MB array size,
while stack
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
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
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
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
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 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: 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
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
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
Hello
the issue you observed might be already reported in:
https://bugs.debian.org/924925
Kind regards,
Bernhard
Dear Maintainer,
I tried to reproduce this issue and received the below backtrace.
This seems the same issue as in following bugs:
https://bugs.debian.org/924499
https://bugs.debian.org/928264
(And a few other reported just against current testing.)
Kind regards,
Bernhard
(gdb) bt
#0
Hello Gulfstream,
are you by any chance running the proprietary nvidia drivers?
I guess the output of following commands could be
helpful for the maintainer to diagnose this issue.
Could you run them and forward the output to this bug?
which freecad
ldd /usr/bin/freecad
dpkg -S
Dear Maintainer,
I just tried to have a look and might found something.
As far as I see ldd searches the shared objects based on the RPATH in
the executable:
benutzer@debian:~$ ldd /usr/bin/CloudCompare | grep "not found"
libQCC_IO_LIB.so => not found
1 - 100 of 213 matches
Mail list logo
