Hello,
tried to reproduce this crash in a Stretch amd64 VM.
It wants to open the directory "maps":
benutzer@debian:~$ strace -f zatacka 2>&1 | grep maps
open("maps", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
Therefore a null pointer is handed to readdir.
}
54
(gdb)
(gdb) list modeling/libraries/pml/MultiComponent.h:134
129 }
130 inline void MultiComponent::removeSubComponent(Component* c) {
131 auto it = std::find(components.begin(), components.end(), c);
132 if (it != components.end()) {
133 component
Hello Emmanuel,
I made a mistake and did my first investigations on testing instead of unstable.
So my findings of my first mail are unrelated (but hope they still help).
So I did another try and got all tests fail like in the reproducible build log.
Something bad happens in these lines:
(gdb) l
Hello Christoph Anton Mitterer,
I just tried to reproduce this issue.
It looks like this issue got introduced in upstream commit [1].
There an error message got added that leads to an immediate process exit.
This error is shown when file /usr/share/tracker/domain-ontologies/default.rule
is not fou
Hello Christoph Anton Mitterer,
this issue seems a duplicate of bug #908800.
Kind regards,
Bernhard
Hello Sandro,
Am 05.03.19 um 00:43 schrieb Sandro Knauß:
> Btw. please use the bugnumber-qu...@bugs.debian.org rarely, because than
> maintainers like me don't gets any mails, that's why I missed your
> conversation.
Sorry for using -quiet - Pino Toscano made me already
aware to avoid -quiet.
Hello Awtul,
not being the maintainer for olwm I tried to shed shome light to it
and describe some ways to get more informations out of it.
(Even when olwm got removed from testing.)
First one can install the systemd facility to collect coredumps:
apt install systemd-coredump gdb
Al
Hello,
I continued debugging from looking at #855167 and came up now with
the 6 attached patches.
With these applied olwm and olvwm are not crashing anymore inside my
minimal test vm.
Probably you want to give them a try.
> Unless there is an automated way to identify all the cases of
> integer
Hello,
I tried to debug this issue and spent "some" time to it.
---
The class ShellCorona contains a QMap m_desktopViewforId storing
pairs of idx and desktopViews pointers.
When a display gets deactivated the method ShellCorona::removeDesktop [1]
is called with parameter desktopView.
voi
Hello,
this looks like it affects package mediainfo [1] too.
Kind regards,
Bernhard
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903054
Hello Tobias Bengfort,
I tried to reproduce by just starting seahorse in a VM,
but the crash did not happen here.
Probably you can follow the steps in [1] to locate
where the crash happens?
[1] https://wiki.debian.org/HowToGetABacktrace
Kind regards,
Bernhard
Hello,
just tried to reproduce the stack smashing.
It looks like the variable "gdouble c[3];" in colorb_csok
needs to be a "gdouble c[4];".
Did not find an related upstream ticket, neither in old SF nor at Github.
Also at Github this function was not yet changed, so this should be
forwarded to up
Hello,
just tried to have a look at #892288 but got stopped by this one.
Upstream handled this issue in [arrayfire/2148] and [arrayfire/2149].
Unfortunately this patch does not apply.
Also the pull request mentions another change is needed in the
boost library [boostorg/776].
Kind regards,
Bernh
Hello,
tried to reproduce this, but unfortunately it fails to build against
gcc-8, for which #897707 is already open.
Therefore tried to reproduce it with gcc-7.
I think this is what happens:
- test Asssign_LinearAssignGenSeq_Test::TestBody allocates a buffer
- buffer gets deleted
- the same buff
Hello,
tried have a look at this crash.
The hkl-5.0.0.2449/Documentation/figures/.libs/sirius executable makes
use of makecontext/swapcontext to execute function trajectory_gen_generator__.
But it looks like the argument given to makecontext got truncated to 32 bits.
So I looked for HAVE_POINTER
Hello,
this might be fixed by upstream commit [1],
connected to this upstream bug [2].
Unfortunately not yet contained in an upstream release.
[1]
https://cgit.kde.org/kaffeine.git/commit/src/dvb/dvbdevice_linux.cpp?id=06b78c5f24891fd38d25ed64f5029106eec7c4fb
[2] https://bugs.kde.org/show_bug.cg
Hello,
just tried to get some more information from this backtrace.
This is what I assume the last frames look like when not optimizing:
g_type_check_value_holds
playcounts_plist_read, line 1115
playcounts_init
itdb_parse_internal
...
main
playcounts_plist_read:
...
1114
Hello Dominik Röttsches,
the missing debug symbols for libmariadbclient.so.18
might hide in libmariadb3-dbgsym.
You may also want to install these packages too:
dovecot-core-dbgsym dovecot-mysql-dbgsym
They should be available in a different debug symbol
repository described in [1].
I had a lo
Hello Francesco,
I missed that, sorry about that.
On Mon, 26 Nov 2018 15:22:39 +0100 =?utf-8?Q?Francesco_Potort=C3=AC?=
wrote:
> >can you still observe the crash, or got it fixed by updates
> >in mid October? (Like mentioned in #910581)
>
> It does not crash any more, ...
So the initial issue
Hello Dominik George,
might this be also caused by "libcap-ng's use of pthread_atfork
causes segfaults" [1].
A version of libcap-ng that should fix that issue should hit
testing the next days.
Maybe you can check if this fixes the crash you reported, too,
or if it is a separate one?
Kind regards,
Hello Francois Marier,
this looks like a duplicate of bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919765
Kind regards,
Bernhard
Control: tags 920467 + upstream patch
Dear Maintainer,
tried to have a look at the stack smashing.
It happens inside a call to g_stat/stat64.
The reason is as far as I see that in nconfig.c the type
GStatBuf has just a size of 88 bytes, therefore no
more memory is reserved. Inside nstat or g_sta
Hello Jean-Dominique Frattini,
I am not involved in packaging any of these packages,
but I noted that you opened the last three days nearly
the same issue against three different packages?
What are you trying to achive that way?
And you noted versions contained in current Buster,
but you claim it i
Hello Chris,
I am sorry for this this mistake.
I assume you tried to build dvbcut for the current gcc transition
on testing/unstable where you got an error as following.
# dpkg-buildpackage
Error parsing time at /usr/lib/x86_64-linux-gnu/perl/5.20/Time/Piece.pm line
469, <$filehandle> line 12.
Opened this RFS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795754
Kind regards,
Bernhard
On Wed, 08 Mar 2023 10:47:25 +0100 Laurent Bigonville wrote:
$ pkcon what-provides application/x-keepass2
Getting provides[=]
Loading cache [=]
Querying[=
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 VM
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)
object.runtime_invoke_virtual_void__this__(object,in
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 the
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 st
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 unresolv
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 f
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 cod
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 hel
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 (nouv
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 US
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 mak
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 /lib/x86_64-linux
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
the issue you observed might be already reported in:
https://bugs.debian.org/924925
Kind regards,
Bernhard
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 at
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 /var/lib/systemd/
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, 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 r
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 modifications
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
0
> 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 r
Sorry missed your email.
Weitergeleitete Nachricht
Betreff: Re: Bug#974828: printer-driver-hpcups: SIGABRT with "free():
invalid next size (normal)" in HPCupsFilter::cleanup
Datum: Thu, 25 Feb 2021 17:03:02 +0100
Von: Bernhard Übelacker
An: 974...@bugs.debian.or
Hello Ian,
I tried to collect some informations for the
maintainer in the other report #972339.
Therefore I tried to reproduce this issue now too, because
my amd64 hardware is much faster as my armhf systems...
But I failed to reproduce maybe because I use the wrong ppd file,
or something else mi
argv=0x7ffc2a13fd48) at prnt/hpcups/HPCupsFilter.cpp:617
...
Description: Grow m_pPrinterBuffer if needed on each page
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/974828
Bug-Ubuntu: https://launchpad.net/bugs/1904318
Last-Update: 2021-02-26
In
Hello Ian,
Am 27.02.21 um 08:49 schrieb Ian Campbell:
On Fri, 2021-02-26 at 15:41 +0100, Bernhard Übelacker wrote:
The attached patch is an attempt to grow the buffer size
if the header changes on a new page.
This is just tested for the given crash, nothing more, therefore
there might be side
Hello Didier,
I have retried with the patch in #974828, but it still
crashed with the test files from this bug, therefore
I guess #974828 is similar but unrelated.
Then I took another look at the valgrind runs and found
that these invalid reads and writes also appear at amd64.
After some diggin
Dear Maintainer,
I tried to 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
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 "mchunk
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
Hello,
tried to reproduce the issue.
I think the problem is that in de::File::parent the method maybeAs()
is called on a NULL pointer.
With the attached patch the crash does not happen.
Kind regards,
Bernhard
# apt install doomsday doomsday-dbgsym doomsday-common-dbgsym
$ gdb -q --args doomsd
Hello Thomas,
sorry for the late reply.
I tried to compare the mawk_1.3.3.orig.tar.gz from the current package
and it compares best to the initial commit in mawk-snapshots [v1_3_3] from 2008.
(Without debian directory and different VCS tags.)
Since then the package just collected some patches on
Hello,
just tried if I can reproduce the issue.
I think this is a again a case of a pointer truncation by default
int for a pointer returning function.
First patch is just to build with debug information to make the
automatic dbgsym packages helpful.
The second patch adds some includes to get p
Hello,
tried to have a look at it.
Program received signal SIGSEGV, Segmentation fault.
0x80015110 in mount ()
(gdb) bt
#0 0x80015110 in mount ()
#1 0xb7f8ff03 in fuse_mount_sys (mnt_opts=0x800163a8 "rw,nosuid,nodev",
mo=0xb398,
mnt=0x80016288 "/home/benutzer/rdiff-backup-fs-test/mnt"
Hello,
this seems to be the same problem seen in #391051 for regular
expressions (collect_RE).
In this bug we overrun the size limit of string_buff (tempbuff._string_buff)
in function collect_string.
Attached patch adds a similar check like in #391051 to collect_string.
With that applied the bui
Hello,
tried to get some more information from the crash.
# IKARUS_SRC_DIR=. IKARUS_BUILD_DIR=. IKARUS_FASL_DIRECTORY=''
IKARUS_LIBRARY_PATH=.:.:./../lib gdb -q --args ../src/ikarus -b
./ikarus.boot.4.prebuilt --r6rs-script ./makefile.ss
Reading symbols from ../src/ikarus...done.
(g
Hello Helge,
net being the zapping maintainer, I just tried to have a look at it.
It looks like alloc_aligned does truncate the pointer to 32 bits.
Therefore storing the original pointer, for being able to free it later,
fails.
common/alloc.c:
37 p = (void *)(((long)((char *) b + al
Hello,
not being the maintainer for this package, I just tried to
have a look at it.
1043 *str = EquivalTable[ *str++ ] ;
To me it looks like in the past the compiler did the assignment
to the unincremented str.
Today str gets first incremented, then *str assigned the element
Hello Sandro,
Am 08.02.2017 um 01:24 schrieb Sandro Tosi:
> Hey Bernhard,
> would be interested in preparing a NMU package with your patches
> included (feel free to reply to me in private if you need instructions
> on how to do that)? alternatively i'd be happy to NMU this myself
I tried to prep
Hello Guenter Grodotzki,
(I guess you wanted me to receive your last message, so you should
use "reply all", or it gets just attached to your bug report.)
I have left a note in this upstream report [1], lets see if they agree.
Kind regards,
Bernhard
[1] https://gitlab.gnome.org/GNOME/gnome-shel
On Tue, 16 Apr 2019 22:47:14 +0100 Simon McVittie wrote:
> How sure are you that the virtual memory area starting at 0x7fd4fa6a6000
> starts with .init and not .text?
Unfortunately I am not completely sure, but I caused a crash while
knowing the memory layout and found there also the dmesg line
c
Hello Pere Nubiola Radigales,
I just saw this report without being involved in packaging freecad.
And tried to reproduce the issue but failed.
Is it possible to save it into a file just before it crashes?
Can the crash be reproduced by starting from that file?
Otherwise you could install the pack
Hello Paul Wise,
might this be related to #925539 ?
Can you still reproduce it when you install
libgeocode-glib0 3.26.1-1 from unstable?
Kind regards,
Bernhard
https://bugs.debian.org/925539
Hello gpe92,
maybe you could add some more information for the maintainer
by following steps, if possible:
- install the package "systemd-coredump"
- try to start gnome-maps again
- forward the output of following command to this bug:
journalctl | sed -n '/dumped core/,/systemd-coredump@/p'
I
Hello gpe,
this stack trace looks really like that one
submitted in https://bugs.debian.org/927728 .
Possibly you can install just libgeocode-glib0 3.26.1-1
from unstable?
>From my findings in https://bugs.debian.org/927728
I would expect that this crash should then be gone.
Kind regards,
Bernha
Control: reassign 928264 libgeocode-glib0 3.20.1-2
Control: tags 928264 + upstream fixed-upstream patch
Control: affects 928264 gnome-maps
Control: fixed 928264 libgeocode-glib0/3.26.1-1
Dear Maintainer,
I just tried to reproduce and hit the segfault below [3].
This seems to be reported in bugs [
Control: tags 907348 + patch upstream
Dear Maintainer,
I tried to have a look and tracked it down into the file
lib/leap-seconds.def which is generated by ltrcc.
Unfortunately this generator seems not prepared for at least i386.
With attached patch the generated file is equal to one
generated a
Control: found 855124 2.2.17-1.1+b1
Control: fixed 855124 2.2.17-1.2+b1
Dear Maintainer,
this issue seems to be a problem with the default python
pointer/int sizes which seem to default
to 32 bit in stretch on amd64.
Attached patch tries to declare these to avoid the crashes.
For some reason thi
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
libQ
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 "cod
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 ../sysde
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
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 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
(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
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
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 unfa
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 regist
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 mes
Hello,
I have created a new upstream issue:
https://gitlab.gnome.org/GNOME/gegl/issues/206
Kind regards,
Bernhard
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 tran
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 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 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
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 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 r
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 bui
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
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 ret
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 ASAN_OPTIO
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 invo
1 - 100 of 224 matches
Mail list logo
