Hello Saša Janiška,
sorry for the delay.
The versions match what I tested previously, but could
not reproduce the crash.
Found also no upstream bug matching this one.
Next step, if you can still reproduce the crash, would be
to attach an debugger like this:
script -a gdb-gnome-maps_$(date +%Y
Control: tags -1 + upstream fixed-upstream
Dear Maintainer,
I could reproduce a crash in csd-backlight-helper too.
Had not installed a complete cinnamon desktop - just the
cinnamon-settings-daemon package, running a plasma desktop.
It looks like upstream handled the issue already in [1] [2].
K
Dear Maintainer,
this looks like the same issue reported in #923962.
I have reassigned that bug to libunwind8, but that
did not receive an answer yet.
More details in [1].
@Kevin Otte: Could you confirm that you did not set a view-only password?
Because doing so could be a workaround.
Kind regard
Hello Kevin Otte,
Am 21.07.19 um 17:23 schrieb Kevin Otte:
> I have now tried with and without a view-only password. I receive the
> same error in both cases.
just to be sure, you got also the "Backtrace" message when
you answered the following question on vncserver start with yes?
Would
Am 22.07.19 um 03:28 schrieb Kevin Otte:
> That is correct.
Strange, because in my VM I received just the
Backtrace when using no view-only password.
One thing to note, I used the same password for
regular and view-only ...
Am 22.07.19 um 15:44 schrieb Kevin Otte:
> As soon as I disconnect the client, the server again crashes with a
> backtrace:
I was told in the upstream report [1], mentioned in #923962,
that the crash on disconnect is known and handled upstream in [2].
[1] https://github.com/TigerVNC/tigervnc/issu
Dear Maintainer,
in the meantime upstream got this bug report [1] that
seems to describe the same issue.
The applied fix seems similar to my previous patch
and 1.8.2 should include it.
Kind regards,
Bernhard
[1] https://bugs.kde.org/show_bug.cgi?id=407829
> 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
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
https://github.com/Winetricks/winetricks/commit/76f5f
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
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 regar
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 lo
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 in
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:
https://g
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 non-sse-ena
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 pwr
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 [2
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 repository
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.
Dear Maintainer,
I could reproduce this stack smashing inside a testing amd64 VM.
The stack canary gets overwritten in the stack below.
It looks like there is a disagreement of wesnoth and wolfssl in
the size of sha/hasher wc_Sha/WOLFSSL_SHA_CTX, the first allocates
112 bytes, the latter thinks i
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.
0x7fa54364fc1
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 "--v
Dear Maintainer,
tried to have a look at it and found that this might be caused by
the wine binary being pointed to by Debians alternatives system.
Therefore winedbg does not find the loader shared object of the target
process and cannot map it (elf_read_wine_loader_dbg_info).
That module would be
Dear Maintainer,
I could reproduce this crash and first lines of the backtrace
with full debug symbols shows like in [1],
while trying to dereference a null pointer.
This might be a use after free because when trying to reverse execute
to the point where the memory holding the null pointer is last
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,
B
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 so
, arg=arg@entry=0x7fffe380) at src/conf/conf.c:285
#8 0x5556d0c1 in module_init (conf=0x555ac760) at src/module.c:151
#9 0x55569950 in conf_modules () at src/conf.c:385
#10 0xf467 in main (argc=, argv=) at
src/main.c:242
Description: Use right size for ioctl
A
rotating by zero degrees
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/971428
Forwarded: no
Last-Update: 2020-10-15
Index: xloadimage-4.1/options.c
===
--- xloadimage-4.1.orig/options.c
+++ xloadimage-4.1/options.c
Dear Maintainer,
from the submitters attached log I guess
the part in [2] is relevant.
This led to the upstream bug in [1].
Downstream there seem to be also some duplicates:
#953880, #953854, #953794, #954095, #954739
This seems to be fixed in testing since gimp 2.10.14-3,
but due to this repo
> #6 0x7f3e13f61730 in () at
> /lib/x86_64-linux-gnu/libpthread.so.0
> #7 0x7f3e1424ceba in g_type_check_value_holds () at
> /lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #8 0x7f3e142526f9 in g_value_get_int () at
> /lib/x86_64-linux-gnu/libgobject-2.0.so.0
> #9 0x5604fd828b2b
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
Dear Maintainer,
I could reproduce it with the state of Debian testing at 2020-07-24.
Upstream bugs seem to be these:
https://bugs.kde.org/show_bug.cgi?id=407338
https://gitlab.freedesktop.org/poppler/poppler/-/issues/766
The issue seems to be resolved since poppler 0.77 and above.
Kind rega
Dear Maintainer,
tried to reproduce but found pcmanfm not crashing.
Instead the process "just" exits without error or crash.
As we leave the main loop without error I tried setting a
breakpoint to g_main_loop_quit and it got hit multiple times.
I guess this last call to g_main_loop_quit is related
Dear Maintainer,
could reproduce this inside a minimal amd64 qemu VM in current testing.
In my test Xorg consumed on CPU completely, another thread
xfce4/panel/wrapper-2.0
used 6% when this menu is opened.
It looked like this process triggers redrawing in a fast loop, which
seem most expensive on
Dear Maintainer,
tried to track where the time is set/retrieved for a remote file
and came up with this location [1].
I am not sure if flag SSH_FILEXFER_ATTR_ACMODTIME/SSH2_FILEXFER_ATTR_ACMODTIME
is the only possible way ssh has to transfer the date, but at
least that way seems to just use 32 bit
Am 19.10.20 um 23:43 schrieb Adam Borowski:
> On Mon, Oct 19, 2020 at 10:52:45PM +0200, Bernhard Übelacker wrote:
>> Dear Maintainer,
>> tried to track where the time is set/retrieved for a remote file
>> and came up with this location [1].
>&g
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,
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
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,
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 gimp_stac
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
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.
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
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 dow
Package: qemu-system-x86
Version: 1:5.2+dfsg-3
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I was playing around with a qemu VM with a virtio vga to see
how far I could get with accelerated graphics inside a VM.
I was watching the VM via remote-viewer.
But on several reb
Dear Maintainer,
the patches got accepted upstream hit now testing
with xserver-xorg-core 2:1.20.10-1.
I made a test similar to the initial attached file and
function addresses printed by gdb match now xservers backtrace.
Therefore I guess this bug can then be closed?
Kind regards,
Bernhard
Dear Maintainer,
I tried to collect some more information and compared this
situation on real hardware armv5tel with an armv7 and
it looks like in keccak_finalize the following instruction
stores different data to memory depending on the arm hardware:
0x005c4ac0 :f0 20 c4 e1 strdr2
Dear Maintainer,
I tried to have a look and could reproduce the crash.
As far as I see a virtual method is called through a shared library
boundary and somehow returns with a wrong value in the $sp register.
Therefore an instruction in memory without executable mapping is
tried to be executed, wh
Hello Mack Stanley,
I am not involved in packaging a2ps, but I guess there are some more
information needed to even start investigating.
I tried several files in a VM to send to a2ps and I could
not observe a crash.
Therefore could you supply to this bug which command line is used
to trigger the
Control: forcemerge 974826 975580
Dear Maintainer,
I just noticed this issue on some devices here too,
and found it leads to the same upstream as #974826 does.
So I hope it is ok to merge them.
As far as I see this error message path triggers the segfault
because "error" is a null pointer.
The
Dear Maintainer,
I tried to reconstruct the line number information with
the dbgsym packages from the backtrace provided by the submitter.
This points to the assert in this line of code: [1]
There are already some other references showing a similar assert below:
../nouveau/pushbuf.c:723: nouve
Dear Maintainer,
due to having in the backtrace the same offsets from function
nouveau_pushbuf_data, I assume this is similar to the bug #975990,
which is currently assigned to the xorg package and contains now
the line information I added with the help of the dbgsym packages.
Kind regards,
Bernh
Dear Maintainer,
this crash shows the following backtrace
and leads to this upstream issue:
https://github.com/JoeDog/siege/issues/104
Kind regards,
Bernhard
(gdb) bt
#0 0x7f6066705b51 in __GI_getenv (name=name@entry=0x0) at getenv.c:39
#1 0x559b8b01a190 in evaluate (hash=hash@entry=
Dear Maintainer,
I tried to get a backtrace containing the source line
information from the core provided by the submitter.
It shows the backtrace below.
This backtrace leads to some upstream issues. Some
of them showing "proxy" being a null pointer.
In this case it shows 0x1 which seems causing
Hello Otto,
if you still can reproduce the segfault then it might
also be possible to install the package systemd-coredump.
That way a backtrace should show up in 'journalctl -e' giving
some more details of where the segfault happens.
This should get more informative if the fdupes-dbgsym gets
in
Hello Peter,
Am 16.12.20 um 11:08 schrieb Peter Palfrader:
Hi Bernhard!
Can you try to rebuild tor with __attribute__((aligned(8))) for the
keccak_state as suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44
and then let us know if the issue is still there?
I rebuilt t
Am 15.12.20 um 23:00 schrieb Mack Stanley:
Dear Bernhard,
Thanks so much for your interest and your message. I very recently
realized that my bug report is in error and hoped that I would be able
to correct or withdraw it before troubling anyone.
Here is how to reproduce the segfault I obse
Dear Maintainer,
from the dmesg line from the submitter I think the crash happens
save_thumbnail_in_cache_thread in [1], between the calls to
cairo_image_surface_get_height and -width.
Tried to reach that function just showing some random PDF
but did not get there.
@Nicolas: I assume Simon asked
Dear Maintainer,
I am sorry but I missed the offset of 42 in the kernel output,
which shows 42 bytes before the crashing instruction marked with "< >".
The location where the crash happened would therefore
not be in line 351, instead it would be in 355.
0x00438186 <+102>: push 0x14(%ebp)
Dear Maintainer,
I tried to have a look at the core file.
If a dbgsym package would be available I would be more
confident about the following information.
Please consider to build the dbgsym package.
The crash seems to happen in the stack below.
It seems the function mc_clear_window_simple ge
Dear Maintainer,
this is a backtrace of the crash:
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x55a9f3c9e5d0 in set_current_wd (path=) at
../path.c:235
#2 0x55a9f3c906b7 in main (argc=1, argv=0x7fffa8fcd4b8) at
../main.c:196
It see
Dear Maintainer,
I tried to have a look at this crash and could it reproduce it
inside a minimal testing amd64 VM.
A backtrace with full debug symbols in [1].
The crash itself happens because of a stack exhaustion, because in
_celt_autocorr a 2015 MB array should be constructed.
But this seems
Hello Karsten,
I tried to collect some more information for the maintainer and
could reproduce this (or nearly) the same SIGILL with a qemu VM limited
to a pentium class CPU.
The instruction in question might these below:
0xb78816bb <+75>:movd 0x4(%esi),%xmm2 (here I received the SIG
Hello Karsten,
thanks for the information - that explains why my emulated pentium
failed already at 0x...6bb because not supporting sse at all.
>From wikipedia [1] the pminud instruction at 0x...6fb got
introduced with sse4.1 which seem not supported from your
flags line (while on the other side i
Dear Maintainer,
this issue seems to be reported upstream already.
There is also a workaround mentioned to modify a "Styli=@..." setting.
Kind regards,
Bernhard
https://github.com/linuxmint/cinnamon-control-center/issues/250
https://github.com/linuxmint/cinnamon-control-center/issues/245
https://
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
aces the use of long by CHRPOS in the places where
they cause the tests to fail. With it applied they succeed when
building at i386 and armhf with current testing.
Kind regards,
Bernhard
Description: Use a variable type that is 8 bytes in size on 32 bit systems too.
Author: Bernhard Übelacke
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux debian 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17)
x86_64 GNU/Linux
M
Hello Ryutaroh Matsumoto,
I just tried to reproduce this and got such a "Bus error" while
running an armhf testing chroot on a physical armv7l system,
unfortunately not running a stock debian kernel, instead
a lineageos kernel.
Here the "Bus error" is given because of an stmib instruction
operatin
%2520.
I guess upstream needs to have a look at this epub.
Kind regards,
Bernhard
Description: Avoid crash on certain epub files
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/972715
Forwarded: no
Last-Update: 2020-11-01
Index: atril-1.24.0/backend/epub/epub-document.c
Dear Maintainer,
I just came across this report and want to note that since ASLR
got quite common the addr2line method is unreliable.
Therefore I want to point to here [1], were another method is
described to find out the source line where a crash happened.
Attached file contains this exercised
-core/src/gatb/tools/misc/impl/Tool.cpp:112
#13 0x00555bad97bc in main (argc=7, argv=0x7fd3195848) at
/usr/include/c++/10/ext/new_allocator.h:79
[2]
https://sources.debian.org/src/gatb-core/1.4.2+dfsg-5/gatb-core/src/gatb/system/impl/FileSystemCommon.hpp/#L103
Description: Use int as re
Dear Maintainer,
I could reproduce this issue with version 2.26.20160125+Atmel3.6.2-1.
Program terminated with signal SIGILL, Illegal instruction.
#0 0xe70f20e8 in e843419@0011_0103_e2c ()
(gdb) bt
#0 0xe70f20e8 in e843419@0011_0103_e2c ()
#1 0xa
nit: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages rr depends on:
ii libc6 2.31-4
ii libc6-i386 2.31-4
ii libcapnp-0.7.0 0.7.0-7
ii libgcc-s1 10.2.0-16
ii libstdc++6 10.2.0-16
ii python3 3.8.2-3
Description: Remove embedded
Am 07.11.20 um 11:00 schrieb Chris Lamb:
Hi Bernhard,
I guess attached patch would at least remove the embedded
build path from the files, which is mentioned in [2] too.
Thanks for working on this. Looking at your solution though, I believe
it implies that CFLAGS set by the dpkg-buildflags me
Hello Chris,
thanks for the pointers.
By enabling fixfilepath [1] the build it is automatically using
-ffile-prefix-map.
This seems also the case for the reproducible-builds.org results already [2].
Therefore I assume the compilation of the .c* files is already good.
And the -ffile-prefix-map pa
Hello Paul,
is it possible to install the package systemd-coredump on
the systems showing this crash?
Then after the next crash in the output of 'journalctl --no-pager'
should the segfault appear followed by a backtrace
that you could forward to this bug.
This should clarify which function calls
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "dvbcut"
Package name: dvbcut
Version : 0.7.2-1
Upstream Author : Bernhard Übelacker
URL : https://github.com/bernhardu/dvbcut-deb
License : GPL-
tags 897150 = moreinfo
quit
On Sat, 28 Apr 2018 23:25:07 -0500 Casey C
wrote:
> -- System Information:
> Debian Release: buster/sid
> APT prefers xenial-updates
> APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500,
> 'xenial'), (500, 'unstable')
> Architecture: powerpc (pp
tags 897390 = moreinfo
quit
On Wed, 02 May 2018 02:09:08 +0200 Manolinux wrote:
> #1 0x7f7cd8902231 in __GI_abort () at abort.c:79
> #2 0x5642194aaa5a in OsAbort ()
> #3 0x5642194b0573 in ?? ()
> #4 0x5642194b1395 in FatalError ()
> #5 0x5642193388bf in ?? ()
> #6 0x000
Hello,
this seems to be caused by a build failure in 1:9.0.0-1
for i386 while amd64 succeeded.
The build failure seems related to #942864.
Next upload 1:9.0.0-2 succeeded for both architectures.
Kind regards,
Bernhard
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-9&arch=i386
http
Dear Maintainer,
the above backtrace lacks symbols but should
match something like below.
Kind regards,
Bernhard
>From submitter: | Reconstructed:
fcitx(+0x1927)[0x5568b6236927] | 0x55b5bef8e927
in OnException at ./src/cor
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 /us
Hello Tomaz Solc,
are you still able to reproduce the crash?
If yes is it possible to install a coredump collector
like systemd-coredump or corekeeper?
With the first following should show something after a crash:
coredumpctl list
And could be examinded by:
coredumpctl gdb
Kind regards,
Hello François,
I just tried to reproduce this crash, without being involved
in packaging qemu.
But could not get my VM to crash - it shows just the video,
either with spicy or the virt-manager integrated viewer.
Therefore could you please add the exact VM config? (virsh dumpxml)
This gstreamer w
Control: fixed 893753 leatherman/1.4.2+dfsg-2
Hello,
looks like 1.4.2+dfsg-2 did build without SIGSEGV.
https://buildd.debian.org/status/logs.php?pkg=leatherman&arch=x32
Kind regards,
Bernhard
Control: tags 886692 + unreproducible moreinfo
Hello Alberto,
I just tried to get some more information from this crash.
I assume this is not caused by the length of the current directory.
Instead I think this is caused by this file:
/DEFAULT/home/marmo/Work/NEGF/SPRKKR_LMAT_practice/.kate
Hello Joe Ma,
On Sun, 20 Jan 2019 19:59:27 +0800 Joe Ma wrote:
> Hello Bernhard,
> For your question, I do execute your gdb command in the console by a shell
> script when kate freeze. What information do you want me to add? I will
> reply asap.
sorry for the late reply, I did not notice your a
Control: reassign 928498 gtksourceview3 3.24.9-2
Control: tags + 928498 upstream fixed-upstream patch
Control: affects 928498 gitg gedit
Dear Maintainer,
this crash seems to be described in upstream
bugs [1] and [2].
And upstream seems to have a fix commited
to the 3.24 branch [3] too.
A packa
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
Control: tags 928687 + upstream patch
Dear Maintainer,
this could be reproduced from a stored RDP connection entry,
while the plugin is uninstalled.
With the dbgsym package installed the backtrace looks like below.
Unfortunately the null pointer in gp->priv->plugin seems to get
unconditionally d
Control: tags 928710 + upstream
Control: forwarded 928710 https://bugs.kde.org/show_bug.cgi?id=381644
Dear Maintainer,
above the upstream bug of this issue.
Kind regards,
Bernhard
Control: reassign 928892 sponsorship-requests
Hello Francois,
it looks like somthing ate all newlines in your email.
I hope it is ok if I reassign to sponsorship-requests.
Kind regards,
Bernhard
Hello Francois,
it looks like your email did not contain any newlines.
Therefore it seems like the whole email was interpreted as the "package".
You can see what I mean in this page [1] near
"Bug reassigned from package".
Kind regards,
Bernhard
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?b
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
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,
the given backtrace should look like below with debug symbols installed.
For some reason it looks like the strchr at line 281 returns a null pointer.
Kind regards,
Bernhard
(gdb) bt no-filter
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x76fc
Dear Maintainer,
I tried to reproduce this issue. And as far as I see
eog/cairo tries to allocate a pixmap from the xserver
in the size of the image file - in this case 44351x3013 pixel.
Unfortunately the xserver has a hard limit for such pixmap sizes:
Thread 1 "Xorg" hit Breakpoint 4, ProcShmC
601 - 700 of 1320 matches
Mail list logo
