When I upgraded my Sid system yesterday (I do it every week or so),
windows cannot be moved to the edge of the screen to have them use half
screen. It simply moves there without readjusting.
Dear Maintainer, hello Alejandro,
this looks like it appeared in unstable with the
appearance of xfwm
And indeed, when unchecking following in Window Manager
settings it seems to "snap" again:
Wrap workspaces when reaching the screen edge / With a dragged window
I had that one disabled (but I didn't do that; I guess it was like
that by default). My windows don't move to other workspace
"With a dragged window" - default as far as I see is on.
I confirm that either with those 4 defaults, or with "with a dragged
window" off (as you suggested that would fix it), I still have it bugged.
If you still don't get a dragged window filling half of the screen,
then I can't reproduc
The patch at the bottom would set tile_on_move to true,
if the "With a dragged window" gets switched off.
Now after some sleep I found that this might really be the
way upstream wants this to handle, so the patch is wrong.
After enabling "With a dragged window" in xfwm4-settings
which switc
After enabling "With a dragged window" in xfwm4-settings
which switches off the tile_on_move setting,
the user can re-enable this setting by
"Automatically tile windows when moving towards the screen edge"
in xfwm4-tweaks-settings.
(If both settings applications are opened side by side,
one can wa
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 Tue, 27 Dec 2022 00:11:12 +0100 Tobias Frost wrote:
On Mon, 26 Dec 2022 16:53:27 +0200 Kostadin Shishmanov
wrote:
> I think it happens because libllvm15:i386 is at version 15.0.6-3+b1, while
libllvm15:amd64 is at version 15.0.6-3
This is due to #1025530: on i386, the binNMU built and
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
plasma panel sometimes hangs, becomes irresponsive. this is preceded by
some notification appearing in the notification area, that becomes stuck
in the corner of the windows and cannot be dismissed. at the same time
all the panel becomes irresponsive to mouse clicks.
my only workaround is kill
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 introduced
Just a short addition:
There is already an upstream bug reported:
https://github.com/csound/csound/issues/1651
Kind regards,
Bernhard
Dear Maintainer,
following is what I was able to extract from the dmesg lines
and the dbgsym packages.
It looks like it crashes in cmsSetHeaderRenderingIntent because
it was given a NULL pointer in parameter hProfile.
That's still not much information, but for this function name
an upstream bug s
Dear Maintainer,
I could reproduce a crash inside a
minimal Bookworm/testing amd64 qemu VM.
There I took below backtrace [2].
Having msg_data->repl_buff equal NULL seems to be the issue.
Upstream commit [1] looks related and a package built
with this commit does not crash with the example comman
Dear Maintainer,
this issue was also discussed upstream in [1] [2].
There the reason was given, that running the application
inside a KDE plasma session makes Qt pick up some KDE
shared libraries (KDEPlasmaPlatformTheme.so),
which does its own GL interactions, which is
not expected by qrenderdoc
Dear Maintainer,
it seems less a crash, instead it fails to find the
right drivers to use, therefore exits.
Looking at the Xorg.0.log from a bullseye netinst it looks
like it uses the /usr/lib/xorg/modules/drivers/modesetting_drv.so
driver inside a virtio equipped qemu VM,
which seems missing in
Hello Everyone,
I guess I see a similar same issue here.
First, for me works as a workaround if I click the slider somewhere
in the middle of the video and do pause it, then close vlc completely.
The next attempt to start the video with vlc works for me.
(Like after a reboot the very first video
Hello Kayim,
I am not involved in packaging or development of nftables or firewalld,
just trying to help debugging random crashes in Debian.
And want just to mention a maybe possible way of debugging this.
As this is a kind of rare issue and when the core is produced it is
hard to find the place
Dear Maintainer,
I tried to get some more information from the dmesg lines.
It leads to the function "boxes_libvirt_broker_real_add_source_co",
which is also written in the critical message before
and unfortunately line numbers are for the generated c files from vala sources.
There are several u
Dear Maintainer,
I tried to investigate a little further and think
I have found some details.
When starting inkscape from a terminal and opening the
given PDF shows a "double free" message.
A valgrind run [2] shows the causing lines at a first glance.
On a second look [3] it might be related to
Why isn't there a symbol package, just for some ports?
Hello Patrick,
there are symbol packages for nearly all Debian packages nowadays.
You can add the debug component [1] to be able to install the dbgsym packages,
or if you like you can just use the DEBUGINFOD_URLS environment variable [2].
K
Hello,
upstream uses now macro-prefix-map, therefore e.g.
source files using __FILE__ should no longer
contain absolute paths.
So there are still the *.S files embedding their absolute paths.
In the long run maybe dpkg-buildflags might help there [1], [2].
But there is also mentioned to "just" f
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
On Fri, 30 Dec 2022 09:46:49 -0300 craudio wrote:
#8 0x7f2ba43e5b99 n/a (kded_apperd.so + 0xeb99)
#9 0x7f2becae8fcf n/a (libQt5Core.so.5 + 0x2e8fcf)
#10 0x7f2ba4323095
_ZN10PackageKit6Daemon22transactionListChangedERK11QStringList
(libpackagekitqt5.so.1 + 0xe095)
Hello,
this
On Fri, 06 Jan 2023 16:50:02 +0100 Gregor Riepl wrote:
...
#14 0x7f9c8c26f6ed in QObject::connect<...> (...) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:268
#15 TransactionJob::TransactionJob (...) at ./apperd/TransactionJob.cpp:47
#16 0x7f9c8c271648 in TransactionWatcher::t
On Fri, 06 Jan 2023 15:08:11 +0100 Lucio Crusca wrote:
$ time ccd2iso e.i.vol.16.img e.i.vol.16.iso
Unrecognized sector mode (0) at sector 0!
real0m0,110s
user0m0,003s
sys 0m0,005s
$ ls -lh *.iso
Dear Maintainer,
this seems to be an upstream issue.
The ccd2iso author states i
Am 22.01.23 um 14:19 schrieb Gregor Riepl:
FYI: My kded core dumps also contained something about a closed DBus
connection in a different thread's stack trace. Perhaps this is related?
I am not able to exclude it to be related, maybe it is the start of the
row of events. When debugging through
On Sat, 14 Jan 2023 18:07:08 + Stephan =?ISO-8859-1?Q?Verb=FCcheln?=
wrote:
This bug appears back some time ago. For some months, video thumbnails
failed to generate on multiple of my machines. Since then, I was trying
to figure out the cause.
It only seemed to affect h264, but not all vid
(gdb) bt
#0 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x7fbffe79dbe1 in KCrash::defaultCrashHandler(int) () from
/lib/x86_64-linux-gnu/libKF5Crash.so.5
#3
#4 0x7fbffc2a9ccc in ?? () from
(gdb) bt
...
#4
#5 0x7f54b82563fb in QQuickItem::~QQuickItem() () from
/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6 0x7f54b83d0045 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5
#7 0x7f54b66dd53f in QObject::event(QEvent*) () from
/lib/x86_64-linux-gnu/libQt5Core.so.5
#8 0x0
Package: gdb
Version: 12.1-4+b1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
I tried to debug a mono application in another Debian bug.
There I received the assertion below, with just trying to run
the application inside gdb.
I found this gdb upstream bug report:
On Thu, 12 Jan 2023 18:31:37 + =?UTF-8?Q?Julian_Gro=c3=9f?=
wrote:
My computer just froze on Kernel version 5.19.11-1. Though nothing got
logged.
Now I don't know if this is the same issue and newer kernels just behave
better in terms of logging, or if this is a different issue..
I gue
Am 23.01.23 um 22:48 schrieb piorunz:
On 23/01/2023 13:35, Bernhard Übelacker wrote:
(gdb) bt
#0 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x7fbffe79dbe1 in KCrash::defaultCrashHandler(int
Am 23.01.23 um 23:07 schrieb piorunz:
On 23/01/2023 21:59, Bernhard Übelacker wrote:
Hello Piotr,
if it is not clear it would be possible to take
the bug number from the email addresses and open
the bug page e.g. https://bugs.debian.org/1028208.
This was just about the plasma-discover crash
https://bugs.debian.org/1028197
On Mon, 23 Jan 2023 21:48:23 + piorunz wrote:
On 23/01/2023 13:35, Bernhard Übelacker wrote:
journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 12:12"
-- No entries --
Then please try something like this:
journalctl
Am 24.01.23 um 00:30 schrieb piorunz:
On 23/01/2023 22:46, Bernhard Übelacker wrote:
https://bugs.debian.org/1028197
On Mon, 23 Jan 2023 21:48:23 + piorunz wrote:
On 23/01/2023 13:35, Bernhard Übelacker wrote:
journalctl --user --since="2023-01-08 12:10" --until="20
Control: reassign 1028220 libglib2.0-cil 2.12.40-3.1
Control: affects 1028220 cowbell
=
Managed Stacktrace:
=
at <0x>
at GLib.SL
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
Package: approx
Version: 5.11-1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
approx got sensitive to lines in /etc/approx/approx.conf
which are empty except of spaces.
This did not harm previous approx versions.
Unfortunately there is no error message in journal:
Start
On Sun, 12 Feb 2023 18:53:01 +0900 Junichi Uekawa wrote:
/usr/bin/wine64-stable fails because of missing files.
Should /usr/bin/wine64-stable be there at all?
I guess having just package wine64 without package wine
installed should also work?
Then /usr/bin/wine64-stable would be needed.
Other
Am 08.02.23 um 19:31 schrieb Tim McConnell:
Opppss I thought I had, here it is.
bt full
Hello Tim,
sorry for the delay. For some reason the debug information
for libpcap.so.0.8 was missing in your backtrace (was the
DEBUGINFOD_URLS variable set in that console?).
But I guess I could fill in t
Dear Maintainer,
I tried to add line information using the dbgsym packages.
That led me to libc trying to print the
message "double free or corruption (out)".
Kind regards,
Bernhard
https://sources.debian.org/src/glibc/2.36-8/malloc/malloc.c/
4584malloc_printerr ("double free or corruption
Hell Mulas,
I tried to get to the source line of you dmesg output:
[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp
7fff0ca38e10 error 4 in
libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2,
socket 0)
[254868.778109] Code: 18 64 48
Hello,
below is the top of a valgrind run
with dbgsym package installed.
Kind regards,
Bernhard
benutzer@debian:~$ valgrind bash
==1114== Memcheck, a memory error detector
==1114== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1114== Using Valgrind-3.19.0 and LibVEX; rerun
On Sun, 31 Jul 2022 11:26:14 -0500 "Steve M. Robbins" wrote:
Package: lldb-14
Version: 1:14.0.6-2
$ lldb
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'lldb.embedded_interpreter'
See https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug
On Sat, 19 Aug 2023 01:44:04 +0200 ramon
wrote:
$ lldb
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'lldb.embedded_interpreter'
The reason is the disagreement in paths for the python integration between lldb and the package.
Running lldb -P,
On Wed, 24 Jul 2024 12:50:23 +0200 Santiago Vila wrote:
Package: src:win32-loader
Version: 0.10.6
Severity: serious
Tags: ftbfs
During a rebuild of all packages in unstable, your package failed to build:
i686-w64-mingw32-as --defsym IMAGE_BASE=0x40 -march=i486 -o instdlg.o
/<>/helper
But I am not completely sure if the generated instdlg.o
is valid and expected, and nsis needs to be able to handle it.
Or GNU assembler should really generate object files in the old layout?
Just a short addition:
If GNU assembler and nsis is found to be working as expected
and there exists no
The package fails to build from source on arm64 and mips64el with
multiple test failures that look similar at first glance. For example,
on arm64:
Fatal Python error: Segmentation fault
Hello,
I tried to collect some more information.
I could just follow that far as a bogus pointer
gets w
Control: tag + upstream fixed-upstream
Another short addition:
A patch got discussed and commited upstream:
https://sourceware.org/pipermail/binutils/2024-August/136268.html
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8c1cd8603443ffeee6e9cc97b738527ea1e2b3e5
On Wed, 31 Jul 2024 22:33:10 +0200 Jakub Wilk wrote:>
Package: gir1.2-gtk-3.0
Version: 3.24.38-2~deb12u1
Gtk.Clipboard.request_rich_text() segfaults for me:
$ python3 request_rich_text.py
Segmentation fault
Backtrace:
#0 0xf5b23141 in gtk_clipboard_request_rich_text (clipboard=0x87
Control: reassign -1 libqt5gui5 5.15.8+dfsg-11+deb12u2
Control: affects -1 + dolphin
On Sat, 03 Aug 2024 15:07:48 -0500 Cody Johnson wrote:
Package: dolphin
Version: 4:22.12.3-1
Severity: important
X-Debbugs-Cc: co...@protonmail.com
Dear Maintainer,
Application: dolphin (22.12.3)
Qt Version
Package: rr
Version: 5.8.0-1
Severity: normal
X-Debbugs-Cc: debian-...@lists.debian.org, bernha...@mailbox.org
User: debian-...@lists.debian.org
Usertags: arm64
Dear Maintainer,
I tried to run rr within a Debian arm64 trixie/unstable,
running at a Raspberry Pi 3 with a ARM Cortex-A53.
I know t
Am 18.08.24 um 14:55 schrieb Stephen Kitt:
Hi Bernhard,
On Sat, 17 Aug 2024 17:49:20 +0200, Bernhard Übelacker
wrote:
I tried to run rr within a Debian arm64 trixie/unstable,
running at a Raspberry Pi 3 with a ARM Cortex-A53.
I know this CPU does not support rr,
but crashing may still not
On Wed, 7 Aug 2024 11:16:04 +0200 Vincent Lefevre wrote:
Package: libc6
Version: 2.39-6
Severity: normal
The following program
#include
#include
int main (void)
{
int r;
r = mcheck (NULL);
printf ("%d\n", r);
return 0;
}
outputs -1, which is incorrect. It should have been 0.
The
On Mon, 26 Aug 2024 08:02:30 +0200 Antonio wrote:>
Package: dolphin
Version: 4:24.08.0-2
Severity: normal
X-Debbugs-Cc: antde...@gmail.com
Dear Maintainer,
I'm trying dolphin for plasma 6, I noticed that when I try to access
disks via
nfs protocol (nfs://myserver/test) or ssh server (fish://m
On Sun, 25 Aug 2024 02:14:10 +0300 Antti Kultanen wrote:
Package: bash
Version: 5.3~alpha1-1
Severity: important
Dear bash maintainers,
bash version 5.3~alpha1-1 in experimental seems to break replacing a
percentage sign in variables. The sign doesn't get removed when replacing:
-8<-
pyksy@
On Sun, 25 Aug 2024 00:16:33 +0200 Ben Hutchings wrote:
Package: mandos-client
Version: 1.8.16-1
Severity: serious
mandos-client's postrm script can fail on purge with no obvious error
message. dpkg reports that it exited with error code 128 but it's not
clear why. I can reproduce this in a b
On Sat, 24 Aug 2024 22:39:30 +0200 Roland Clobus wrote:
Package: gnome-control-center
Version: 1:46.4-1
Severity: normal
X-Debbugs-Cc: p...@hands.com
User: debian...@lists.debian.org
Usertags: openqa
Hello maintainers of gnome-control-center,
As seen on the automatic openQA tests, the tab 'App
Control: affects -1 + heaptrack
Control: retitle -1 libunwind8: SIGSEGV in _ULarm_step on RPI 3B+ (heaptrack
autopkgtest test fails at armel)
On Sun, 07 Mar 2021 14:38:24 +0100 Tobias Diedrich
wrote:> Package: libunwind8
Version: 1.2.1-10~deb10u1
Severity: normal
Dear Maintainer,
While try
Am 12.09.24 um 11:49 schrieb Bernhard Übelacker:
Dear Maintainer,
I found the autopkgtest of heaptrack fails, so I tried to collect some more
information,
and as the backtrace ends in libunwind8 I think this is the same issue as in
this bug.
Following is a lighter reproducer, just needing gdb
On Sat, 24 Aug 2024 21:05:54 +0200 Matthias Klose wrote:
Package: src:libfabric
Version: 1.17.0-3
Severity: serious
Tags: sid trixie
libfabric ftbfs at least on i386, there might be more follow-up errors:
[...]
prov/hook/src/hook_domain.c:124:54: error: passing argument 2 of
‘domain->base_o
On Wed, 21 Aug 2024 10:01:21 -0400 Reinhard Tartler wrote:
Source: mediaconch
Version: 24.06-1 fail
Severity: important
Here are recent instances where the test
https://sources.debian.org/src/mediaconch/24.06-1/debian/tests/check-mediaconch-gui/#L28
has failed on armhf:
https://ci.debian.net/
On Sat, 3 Aug 2024 11:20:59 +0100 Simon McVittie wrote:>
Source: ironseed
Version: 0.4.0-5
Severity: important
User: debian...@lists.debian.org
Usertags: flaky
X-Debbugs-Cc: debian...@lists.debian.org
Control: affects -1 + src:libsdl2
The ironseed autopkgtest 'savegames' intermittently fails o
On Mon, 19 Aug 2024 07:10:13 +0200 Sebastian Ramacher
wrote:
Source: freerdp2
Version: 2.11.7+dfsg1-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
https://ci.debian.net/packages/f/freerdp2/testing/amd64/49289917/
58s autopkgtest [21:09:03]: test compare: [---
58s
Package: wordtrans-kde
Version: 1.1pre14-2
Severity: normal
With a running instance of kwordtrans any call to
DCOPClient::remoteObjects hangs until kwordtrans is closed.
A test case is calling in a shell "dcop kwordtrans".
This affects at least also the kdelirc package.
When running the configura
Package: kdetv
Version: 0.8.9-1
Severity: important
Tags: squeeze patch
Kdetv has not found any video device at my system.
It assumes that if the directory /dev/v4l exists the video
device is also in this directory.
$ ll /dev/video0
crw-rw+ 1 root video 81, 0 22. Mai 01:40 /dev/video0
Control: tags 920139 + moreinfo
Hello Adrian,
Am 03.02.19 um 09:24 schrieb Adrian Immanuel Kiess:
> The bug is, like I see it, that the applications cannot find the
> gsettings schema directory.
>From my point of view it might be more the file gschemas.compiled
inside that directory. Does that
Am 04.02.19 um 13:42 schrieb Didier 'OdyX' Raboud:
> Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :
>> If such a system is detected, maybe a warning could be added?
>
> Sure. I suggest this would be done very early, but have no clue how to dete
Hello Thomas,
Am 05.02.19 um 20:50 schrieb Thomas Gaugler:
...
> I thought to use the momentum around secure boot within Debian [2] for
> supporting it within win32-loader as well.
>
> The basic idea is to replicate the following commands in win32-loader:
> $ # Copy /usr/lib/shim/shimx64.efi.sign
Hello Jiri Palecek,
I could reproduce this issue also on amd64.
It looks intentional and seems like a security consideration
to make no crash dumps and is caused by this line:
kdesu.cpp:83: prctl(PR_SET_DUMPABLE, 0);
However, you may temporarily add SUID to gdb, then gdb
will run as
Hello Zac Morris,
I am not the maintainer and just trying to get some
more informations of the segfault.
Unfortunately I think you need to provide some more
details on your used configuration.
The line shown in dmesg about the segfault could
also be of help already.
Otherwise you could also inst
Hello Adrian,
maybe one of the installed source files lead
to a bad gschemas.compiled file?
Could you create a file with the md5sums of all
the xml files that seem to get combined into that
gschemas.compiled file.
md5sum /usr/share/glib-2.0/schemas/* >
~/usr-share-glib-2.0-schemas-md5sums.t
Betreff:Re: Bug#921310: dnsmasq "segment fault" bug when total conf
files size is too large
Datum: Sat, 9 Feb 2019 15:31:52 -0500
Von:Zac Morris
An: Bernhard Übelacker
Yeah, I didn't know how to update the case. Is there a web front-end for
updating/tr
Hello Zac Morris,
you still may consider installed systemd-coredump and
when it happens again provide the complete lines reported
by journalctl related to the crash.
I, as I said not deeply involved in dnsmasq and just trying to
collect some information, tried to replicate your configuration,
but
Ok, so the package corekeeper would be an option?
Is gdb-minimal also already too much?
Kind regards,
Bernhard
PS.: please leave the bugs email as CC or To. ;-)
Hello,
tried to reproduce this.
So far it looks like it manifests not at amd64 but on i386.
Also when rebuilding the package the fault is not visible.
Using the previous package libtinyxml2-6_6.0.0+dfsg-1_i386.deb from
snapshot.debian.org works without stack smashing.
The problem might be a ABI
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,
tried to reproduce this issue in a Debian Jessie VM.
The stack smashing detector bytes are changed here:
(gdb) bt
#0 __strncat_sse2 (s1=0x7fffd198
"s\201\215I\267\344Cݠ\022\271\367\377\177", s2=0x77ba5046
"s_expression>\n", n=0) at ../string/strncat.c:55
#1 0x77b9da83
Hello,
tried to reproduce this issue.
The exact location where the stack smashing detector bytes get overwritten is
below.
Looks like an upstream bug where the size of
the out parameter ("decoded" variable) is not respected.
Kind regards,
Bernhard
(gdb) cont
Continuing.
Watchpoint 4: *0x
fixed 776161 1:2.10.0-1
quit
Hello Jakub Wilk,
I tried to reproduce the issue in a Debian Jessie 32 bit VM.
The stack smashing detector bytes are overwritten here:
(gdb) bt
#0 short2long_name (src=, dest=) at
/home/benutzer/qemu/qemu-2.1+dfsg/block/vvfat.c:431
#1 create_long_filename (filena
Hello,
I tried to reproduce the stack smashing.
But found that the current package in Debian amd64 testing
looks like it was not build with -fstack-protector-strong.
So could it be that your report was using a local rebuilt package?
Nevertheless it looks like the local variable testname has just
Hello
On Tue, 3 Jul 2018 20:57:46 +0200 "W. Martin Borgert"
wrote:
> Any more ideas? The workaround with the Jessie chroot is OK, but.. ;~)
A way to get more information would be to install the debug information packages
and let simple-scan run by gdb [1].
[1] https://wiki.debian.org/HowToGet
Hello Knut Jackowski,
I tried to reproduce the issue with a Stretch i386 VM.
"Unfortunately" the scide gui opened without a problem.
So maybe you could deliver some more information about
the crash by following this guide [1].
[1] https://wiki.debian.org/HowToGetABacktrace
This mail is written
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,
tried to look if this issue could be closed.
Unfortunately can also not reproduce it in a Debian Jessie i386 VM
with 21.0-1 from snapshot.debian.org.
Following the mail from message #20 [1], it leads to a bug in [2] which
points in the attachement to the function read_klog.
Upstream got a
Hello,
I tried to reproduce the issue.
The original logfile showed this part:
ending up
*** stack smashing detected ***: /<>/tools/.libs/test
terminated
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x6737a)[0xf757e37a]
/lib/i386-linux-gnu/libc.so.6(__fortify_fai
Hallo Knut,
there is still the shadow that this issue might be first sent to the
people from BunsenLabs.
Nevertheless from looking at the stack it looks like a Qt5 application
but we end up here in some Gtk 2 libraries ...
Does this also happen with a new second user at this system?
Also the te
Hello Riccardo Lancellotti,
> It looks like the problem was related to some incompatibility issue
> with a previous version of some library (libecal-1.2 is my guess).
Then was it solved by any update to libecal-1.2, or at least is it
still an issue or should this bug be closed?
Kind regards,
Ber
Hello Richard Jasmin,
can you still reproduce this issue or can this bug be closed?
Could you tell if you use Gtk or Qt version?
Or with which game this happens at which state?
Kind regards,
Bernhard
Hello,
just looking at some stack smashing errors and got onto
this one here.
Unfortunately Jessie did not have the dbgsym packages so
I cannot get any clue of the given stack.
Was or is this still an issue for Stretch or testing?
Also it looks like this daemon got removed last month
from upstre
tags -1 = patch
bye
Hello,
just tried to reproduce the issue.
With the help of the message #42 and the debug symbols in Stretch
and later in a Debian Stretch i386 VM I could reproduce the issue.
I think it all boils down to:
(gdb) bt
#0 get_port_fmt (ip=16777343, port=44081) at utils.c:81
#1
Hello Al,
I tried to reproduce the issue and the relevant part of the crash seems here:
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1 0x7734446c in _IO_vfprintf_internal (s=s@entry=0x7fffe030,
format=format@entry=0x556873e8 "[chuck](VM): sporking
Hello Knut,
thanks for your feedback.
I was just asking because I did not know if Bunsen does rebuild
packages. But as the packages are really from the Debian repo I assume
here is a good place for this bugreport.
So as it works with a default setup it is just harder to reproduce ...
and it might
Hello Knut,
Am 31.07.2018 um 00:37 schrieb Knut Jackowski:
> So not sure how you see it, but I think that this is more a case of
> borking one's own system and not a bug.
I think it is not that easy, this might still be a bug. But yes, when
the configuration gets more and more unique, the more no
Hello,
just tried to reproduce this issue.
I think the problem is with the usage of the segment register
$fs in dosemu that is not compatible with gcc use of that
segment register $fs.
It looks like in "regular" processes the $fs register stays always
at a value of 0.
But after starting the unzi
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,
was just looking at some random crashes.
I was only testing in a Debian testing/Buster amd64 VM.
After some time looking at line readconf.c:71 I doubt that
nvram-wakeup ever ran successfuly on amd64 architecture.
At least in line 71 the 64bit pointers get trunctated by casting
them to 32b
Hello Alison Chaiken,
> Here is the backtrace from GDB. I'd be happy to compile the package
> again from source and gather more info, although not if I must compile
> GTK, too!
No need to compile just for debug information as the debug information
is now widely available in separate deb package
Hello John Scott,
I just tried to reproduce the issue.
As far as I see this issue is known upstream as issue [openalpr#692].
That one got closed with following hint:
Fixed by change in tesseract tesseract-ocr/tesseract#1669
In [tesseract#1665]/[tesseract#1669] a fix got commited for tessera
301 - 400 of 1320 matches
Mail list logo
