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 Wouter,
just tried to reproduce this segmentation fault.
Unfortunately we got new versions of squeakvm and other packages
I fear the core dump is not that useful anymore.
Also I was not able to got the current versions in Debian testing,
when I started it that way:
LANG=C /usr/lib/squeak/4
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 Wouter,
thanks for this additional information.
I could reproduce the issue with a usb webcam inside a buster amd64 VM.
Unfortunately this camera button was with the german translation not
visible with the small resolution of that VM.
It took a little time to get into the smalltalk side of
Am 04.08.2018 um 21:53 schrieb Wolfgang Grünstern:
> Thank you,
> will the Debian version receive the patch next time automatically?
> Kind Regards,
> Wolfgang
Hello Wolfgang,
that would be up to the package maintainer, I think.
Probably the best would be to try to get in contact with him direct
Hello Robert,
if you started the crashing application already with gdb then, after the
crash, please also call the "bt" command to get a complete call stack.
More information in [1].
And this is most helpful, if the debug packages got installed before,
e.g. freecad-dbgsym and at least the last fram
On Wed, 17 Jan 2018 09:41:44 +1100 Paul Szabo wrote:
> Dear Maintainer,
>
> Running on x86_64, hpanel sometimes crashes with SIGSEGV.
> As yet I have not noticed what actions may cause this, so
> do not know how to make it happen at will.
Hello Paul,
just tried if I can reproduce the issue even
Forgot to attach ...
Description: Avoid crash when there too many windows open to draw at least one char.
Author: Bernhard Ãbelacker
Bug-Debian: https://bugs.debian.org/887468
Forwarded: no
Last-Update: 2018-08-07
--- hpanel-0.3.2.orig/hpanel.c
+++ hpanel-0.3.2/hpanel.c
@@ -588,7 +588,7 @@ gui
Control: tag -1 patch
Hello Paul,
I could trace from your core the crash into a call to
XftTextExtents8 in libxft2 library.
There is just one location that calls that function which
is responsible to draw the window title near the icon in
the window bar.
There I could reproduce that crash:
P
Dear Maintainer,
today I stumbled also over this issue in Stretch amd64 with gimp-2.8.18-1.
I tried to apply the patch by Alexis Scheuer from bug report [1][2] and
built a package and can confirm that the freeze does not happen with it.
As I could not easily apply it because of the format, find a
Hello Maximiliano,
I tried recently also a Plasma Wayland session and it crashed also on
closing windows.
I have coredumps enabled and installed the needed debug symbols.
I put my findings into the upstream bug [396096].
That might be the same that Alexander observed.
Kind regards,
Bernhard
[39
Hello Eugene,
I just tried to reproduce the issue and collect some more information.
Unfortunately grub-legacy has not yet a dbgsym package.
But is also crashing with a self built package.
# gdb -q --args /usr/sbin/grub
Reading symbols from /usr/sbin/grub...done.
(gdb) display/i $pc
1: x/i $pc
(
Hello,
not being the maintainer I just found it interesting to investigate...
This message seems to be printed while it wants to load libc.so.6 into the
process,
and is just printed if there is not yet a "/etc/ld.so.cache".
Then it has a handling to be able to load some hardware optimized
version
Hello all,
attached a try to minmize the testcase to just the affected instruction.
Kind regards,
Bernhard
/*
bernhard@rechner:~$ uname -a
Linux rechner 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 (2018-09-06) x86_64 GNU/Linux
bernhard@rechner:~$ gcc -m32 -g -O0 -static 910571_test_2.c -o 910571_test_2
Hello Bastian Blank,
might this crash be the same as reported in #898553 ?
Kind regards,
Bernhard
Hello all,
just tried to reproduce the crash in a buster amd64 VM.
(gdb) bt
#0 0x7eff267b4f15 in QRegion::operator+= (this=0x5566b805ab60, r=...) at
painting/qregion.cpp:4183
#1 0x7eff265451a4 in QPaintDeviceWindow::update
(this=this@entry=0x5566b8072600, rect=...) at kernel/qpaintdev
Hello,
missed following bug while listing maybe related ones:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911320
Kind regards,
Bernhard
Hello,
just tried to reproduce this issue.
And I think this is "just" a recursion.
Also bash shows this behaviour.
(except it just allocates 132MB instead of
exchausting the whole physical memory.)
Are you maybe trying to achive something like this?
echo () { /bin/echo foo; } ; echo
Kind reg
Hello Andrea,
I just tried to reproduce the hang, unfortunately did not hang
in an i386 VM upgraded from jessie to stretch with an anjuta started
before and after the upgrade.
Therefore you might need to provide some more information
for the maintainer.
First please install following packages con
Hello,
I just tried to reproduce the crash.
As far as I see the interface glue between python and x11 is not prepared for
64 bit pointers.
Without being explicit python assumes here just 32 bits and therefore truncates
the pointers.
This probably worked in older 64 bit releases because there poi
Hello,
just trying to reproduce the crash, but it does not happen for me
with the sequnce from the man page like below.
Could you probably provide some more information.
Either an minimal example database and selects that triggers the crash.
Or just a backtrace from an attached debugger.
You find
Hello Axel,
what CPU is inside the machine producing this cores?
Could you please check if your CPU supports avx2 instructions.
If an internet search tells me right this line should show
"avx2" for each core if yes:
grep -o 'avx[^ ]*' /proc/cpuinfo
Kind regards,
Bernhard
Hello Axel,
Am 21.10.2018 um 23:10 schrieb Axel Beckert:
> The system is about 2.5 years old.
...
> (I'd say this counts as a yes.)
Ok, will not do wild guesses next time ;-)
I think I were able to reproduce the issue in a buster amd64 qemu-VM,
by forwarding a real usb card reader with inserte
Hello Ritesh Raj Sarraf,
Am 23.10.2018 um 06:22 schrieb Ritesh Raj Sarraf:
> Are you in a position to try the patch
> out and confirm if it really mitigates the problem ?
I have built a package with this patch applied yesterday,
and it did not crash anymore in my test VM.
Kind regards,
Bernhard
Hello all,
I tried to reproduce this issue and think I found the problem.
In commit [1] a typo creeped in and "block->name" got replaced by "block_name".
Variable block_name gets not initialized and therefore g_str_has_prefix crashes.
Might be on other architectures just valid or zero by luck.
Hello Massimo Manghi,
just tried to reproduce the issue inside a debian buster amd64 qemu VM.
I never hit the crash and found you were probably running inside a VirtualBox.
Nevertheless with installed debug informations I think the crash shown
in the Xorg.log points to that location:
(gdb) bt
#0
Hello Massimo,
Am 24.10.2018 um 15:54 schrieb Massimo MANGHI:
> ... and the new patch will be
> included in the next upload, is it correct? Am I supposed to take any
> further action? Something like changing the bug status or applying some
> extra tag to the bug in order to specify the environm
Hello all,
to upstream git this patch [1] got just committed.
I repeated my tests from message #25 with
wine-development version 3.18 and found:
- Debian packages show still that exact crash.
- A local rebuilt package show that crash too.
- A local rebuilt package with just patch applied does no
Hello Alex Andreotti,
just tried to reproduce this issue but did not happen inside my unstable amd64
qemu VM.
Probably you can install an core dump collector like systemd-coredump?
Then you could see the stack where the crash happened by:
coredumpctl gdb list
coredumpctl gdb
And even bette
Package: mirrors
Severity: normal
Hello all,
since a week or so I get slow downloads when upgrading.
With that line in sources.list:
deb http://deb.debian.org/debian/ buster main contrib non-free
I receive following http connection:
root@rechner:~# netstat -anp | grep http
tcp
Am 25.10.2018 um 22:44 schrieb Marco d'Itri:
> On Oct 25, Bernhard Übelacker wrote:
>
>> Due to [1] I assume the location of the actually
>> used mirror in San Francisco.
> It is not.
>
Hello Marco d'Itri,
thanks for your very quick response.
I should ha
On Thu, 25 Oct 2018 23:13:50 +0200 Marco d'Itri wrote:
> The output of mtr would tell more, but if you are experiencing
> performance issues then I recommend that you start by discussin this
> with your ISP.
> Or else just try different mirrors, Germany has many:
> https://www.debian.org/mirror/
Hello Mo Zhou,
I just tried to reproduce the issue and thats my findings:
...
corrupted double-linked list
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht
gefu
Just for reference attached some notes how to
switch to openrc and some debugging attempts.
# switch to unstable
nano /etc/apt/sources.list
apt update
apt dist-upgrade
apt autoremove
reboot
nano /etc/default/grub
# remove quiet
# add init=/sbin/openrc-init
update-grub
apt install initscripts
ap
Dear Maintainer,
just tried to debug this issue.
When running regularly I received right before the crash that line:
corrupted double-linked list
When running with valgrind it receives this error:
==8018== Invalid free() / delete / delete[] / realloc()
==8018==at 0x48369EB: free (vg_rep
Dear Maintainer,
I tried to have a look at this crash.
But just found out that valgrind shows reproducible
the following invalid read to already freed memory:
==14641== Invalid read of size 4
==14641==at 0x4EC1424: av_packet_copy_props (avpacket.c:578)
==14641==by 0x4EC1BB2: av_packet_ref
Package: buildd.debian.org
Severity: normal
Hello,
when opening [1] the drop-down list contains a "jessie-security",
but misses a "stretch-security" - should that be available?
[1] https://buildd.debian.org/status/package.php
Kind regards,
Bernhard
Package: udisks2
Version: 2.8.1-3
Severity: normal
Dear Maintainer,
I received a crash of udevd by doing an unmount of a ntfs partition
of an usb stick via the plasma systray icon.
As far as I see in this case in function udisks_linux_drive_object_get_block
is a call to udisks_linux_block_object
Package: vlc-plugin-video-output
Version: 3.0.6-1
Severity: normal
Tags: upstream upstream-fixed patch
Dear Maintainer,
I received a "SIGFPE, Arithmetic exception." while the menu of a to
hard disk copied VIDEO_TS folder was playing and then pressing space.
For some reason I did not get that exc
Control: reopen 921959
Control: reassign 921959 tftpd 0.17-22
Hello Everyone,
I hope it is ok to reopen and reassign this report to package tftpd,
which I assume Alison Chaiken has installed, based on the addresses
in the supplied backtrace.
I assume this is the result of some implicit "Object
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.
Control: tags 926408 + unreproducible moreinfo
Hello Gudjon I. Gudjonsson,
just tried to triage this report and could unfortunately not
reproduce the crash either in a VM or a regular desktop system.
You should received a crash message from "drkonqi".
(The bad smiley icon in the tray near the cl
Hello Bernhard E. Reiter,
just tried to help triaging this bug.
It sounds quite similar to an already filed bug #924050 .
Is pdfsig on your system really not crashing if firefox is installed?
Maybe you could run following command in a terminal to get a backtrace
from a debugger when it crashes a
Hello Jérémy,
sorry for the delay.
> So if i run qemu with the first P6 cpu that comes to mind, pentiumpro,
> npm install electron-spellchecker@1.1.2
> no longer crashes.
>
> That doesn't prove there is no crash on a supported cpu, but that's a start.
> Comparing the flags and address sizes might
Hello Guenter Grodotzki,
I just tried to help triage that issue.
For some reason you just added the segfault line.
I assume there was one line following starting with "Code:".
Please add that line too when submitting bugs.
As this information is still kind of small, you might consider
to install
Dear Maintainer,
just tried to help triaging this issue.
Seems this is "expected" behaviour with LC_ALL not
set to "C". In the end it leads to this upstream bug:
https://github.com/sirfz/tesserocr/issues/165
It contains some workarounds and more information.
Kind regards,
Bernhard
# Buster
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
Control: tags 926408 + upstream patch
Control: tags 926408 - moreinfo unreproducible
Dear Maintainer, Hello Gudjon,
I forgot to mention that this little "save" button should be on the
developers information tab of DrKonqi. Then you should not need to
do something in gdb manually.
However, I over
Hello Adrian,
> I don't have any of those old GNOME applications installed, you mentioned.
Then these files should not be there I guess like e.g.:
/usr/share/glib-2.0/schemas/org.gnome.EasyTAG.gschema.xml
On a system where e.g. easytag is installed a 'dpkg -S' returns this:
$ dpkg -S /usr/sh
Control: tags 926658 + patch upstream fixed-upstream
Dear Maintainer,
I just tried to help triage this issue.
I think this is related to upstream bug [1] and
was already fixed in the 5.2 branch by commit [2].
A package built with this patch does just show the
'undefined variable' error, but not
Hello Alf,
maybe we can get more context of this crash
by doing one of the following:
- Install gdb and run linphone like this:
script -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' -ex
'bt' -ex 'bt full' -ex 'detach' -ex 'quit' --args linphonec -d 5 -l
linphone-debug" -a g
Hello Thorsten Glaser,
Am 24.03.19 um 14:25 schrieb Thorsten Glaser:
> Bernhard Übelacker dixit:
>
>> I see that the syscall number gets modified to become 0x4062.
>>
>> But the syscall modifies 144 bytes, more than just the size of
>> variable ru1 of 88 byte
Hello Alf,
thanks for the fast response.
You can query to which package a shared object belongs by:
dpkg -S /usr/lib/x86_64-linux-gnu/libbellesip.so.0
That should show 'libbellesip0' I guess.
So, if package libbellesip0-dbgsym gets installed, another
retry should have all needed debug inform
Control: reassign 921266 libbellesip0 1.6.3-4
Control: affects 921266 linphone
Control: tags 921266 + upstream patch
Hello Alf,
> Hope this helps you to locate the root cause.
I had a quick look at this line and found that upstream has
changed these lines already in their repository,
these comm
Dear Maintainer,
I tried to triage that issue and came to this try and catch block:
146 try {
147 PlainPasswd plainPassword(obfuscated);
148 password->replaceBuf(plainPassword.takeBuf());
149 PlainPasswd plainPasswordReadOnly(obfuscatedReadOnly);
1
Hello Alf,
Am 12.04.19 um 22:10 schrieb Alf:
> I am prepared to test your patch as soon as I get a binary of the
> patched lib.
please find attached some commands to build the package
with the patches in question by yourself.
Maybe you want to do this on a different machine as it
installs quite
Control: tags 927027 + patch
Dear Maintainer,
I tried to have a look at this crash and I think it is related to
the large file support, which is defined in dcfldd.h, line 27 and 28.
Unfortunately this file gets not included first in split.c and
therefore off_t gets defined without large file sup
Hello Juanjo Espí,
I just tried to reproduce this issue to get some
more informations for the Maintainer.
Unfortunately due to my limited docker
knowledge I was not successful.
Therefore you might supply some more information by installing
gdb, attaching it with following command and then start th
Hello Kim-Alexander Brodowski,
I just tried to get some more information from the segfault
lines, while not being involved in packaging.
It seems to point to function sieve_bytecode_version
in sieve/bc_eval.c:1809.
Unfortunately upstream seems to have removed/rewritten that
function completely [1]
Control: tags 924050 + upstream fixed-upstream patch
Dear Maintainer,
> Program received signal SIGSEGV, Segmentation fault.
> 0x77321c84 in SECMOD_ReferenceModule () from
> /lib/x86_64-linux-gnu/libnss3.so
> #0 0x77321c84 in SECMOD_ReferenceModule () from
> /lib/x86_64-linux-
Hello Wesley Schwengle,
I am not sure anymore if the error I received is the same you got.
Therefore, if you can still reproduce this issue, can you please
run pdfsig inside a debugger like below and forward the output to
this bug? You would at least need to install the package 'gdb'.
gdb -q -
Hello Bernhard,
> The indicateion is the difference in the messages in the original problems:
> #924050: Internal Error (0): Input couldn't be parsed as a CMS signature
> #926404: Internal Error (0): couldn't find default Firefox Folder
Yes, I fear I hit not the submitters problem in #924050 and
Hello Kim-Alexander,
thank you for the fast response.
I loaded the core and found following backtrace.
(Information how to retrieve it attached.)
Kind regards,
Bernhard
(gdb) bt
#0 0x7f65d13e3dd9 in __bswap_32 (__bsx=) at
/usr/include/x86_64-linux-gnu/bits/byteswap.h:52
#1 sieve_bytecode_
Am 16.04.19 um 12:04 schrieb Bernhard Reiter:
>> there was neither /etc/pki/nssdb nor a firefox profile in the
>> home directory.
>
> Can you post the signature information?
> My guess from the code is that you saw the info,
> but no certification validation.
benutzer@debian:~$ /usr/bin/pdfsig Sa
Am 31.05.21 um 21:49 schrieb Adrian Bunk:
#975977 comes into my mind as a similar bug in a different package.
Unfortunately in this bug it was possible to do a side by side
debugging, that way the exact instruction could be identified,
and the relation to the alignment was found.
But with gho
Dear Maintainer,
there is an upstream bug that shows a similar backtrace
and is also about clipboard interaction.
Maybe more likely to happen with larger selections.
https://gitlab.gnome.org/GNOME/gimp/-/issues/2357
Kind regards,
Bernhard
Am 01.06.21 um 14:31 schrieb Bernhard Übelacker:
Dear Maintainer,
there is an upstream bug that shows a similar backtrace
and is also about clipboard interaction.
Maybe more likely to happen with larger selections.
https://gitlab.gnome.org/GNOME/gimp/-/issues/2357
And copyq upstream has also
Dear Maintainer,
I could reproduce the issue, but mostly just on the first run
after a reboot of my test VM.
When the issue appears the context menu opens for the favorites,
but the entry to create a new folder is wrongly enabled.
Clicking in that state leads to the error message:
Error while
Hello Juan,
the last lines of your backtrace end in nouveau_dri.so.
Therefore this might not be a fault in solvespace.
Maybe you could install the package libgl1-mesa-dri-dbgsym where
the file nouveau_dri.so originates from, and provide
another backtrace from such a crash.
I would expect that the
Hello Jim,
I am not involved in packaging, but came to this report by chance.
The attached file contains all the changes you devs have made in the kernel
configs from 5.10.28 (-6 package) to 5.10.38/.40 (-7 package). It was made with
meld.
~10 kernel parameters have changed and led to this mess
Hello Jerome,
could you please add a few more details for the Maintainer?
What shows the "bt full" command in gdb, when the crash is reached?
Is the package dconf-service installed and
when you login a process dconf-service running?
Kind regards,
Bernhard
Hello Helge,
I just tried to collect some information for the Maintainer.
Might this be the expected behaviour?
This image seems to have a stored Delay and Duration value:
$ identify -verbose 2006_08262.gif
Image:
Filename: 2006_08262.gif
...
Delay: 20x100
Duration: 20
...
These 20 ge
Package: gdb
Version: 10.1-1.7
Severity: wishlist
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
while investigating an issue in the test suite of rr-debugger,
I found that the libbfd part of gdb is not built with debug information,
therefore the dbgsym package also lacks this information.
Hello Simon,
I guess #982049 is about the same issue.
At least function name and address offset is equal.
Kind regards,
Bernhard
Hello Hans,
I had also used smb4k some months/years ago, so I tried to start it now.
I also got no entry in the window list, but I got a symbol in the system
tray near the clock. It was kind of hidden as there are already plenty
icons I had to extend the system tray via the triangle (plasma des
Hello Hans,
(please leave the bug address in the CC field
to add the information in the bug too.)
I did not mean in the taskbar, I meant the systemtray near the clock.
Please see the green marks in the picture below.
Kind regards,
Bernhard
Am 06.02.21 um 13:03 schrieb Hans:
Am Samstag, 6
Hello Hans,
However, no icon. Smb4k is starting, then crashing. There is also no
process running which is named smb4k or similar.
Ah, ok, from the description I was under the impression the process is
running but not showing a window.
So what does it write to the konsole when started from t
Hello Hans,
great that it works.
So I suppose, we should and could safely close this bug.
This can be achieved by sending the
mail to 980103-d...@bugs.debian.org.
(I hope this is ok with smb4k maintainers.)
Best regards, thank you very much again and stay healthy!
Thank you, the same to
Dear Maintainer,
I tried to find out when this started to happen.
And I found this issue in releases 11-bullseye, 10-buster and 9-stretch.
In 8-jessie such a vgcore shows in gdb the correct line information.
Further looking brought me to stretch/testing as of 29.10.2016,
where the issue starts t
Looking a little further, it looks like gdb does "just" not
know where the executable was mapped in memory, therefore it
gets mapped to 0x0 instead of 0x108000 in my example below.
Debugging such a "pie vgcore" file would be possible
if the debug symbols are loaded manually to the "right" address
0x563cebe97881 in svr4_exec_displacement (displacementp=) at /build/gdb-Nav6Es/gdb-10.1/gdb/solib-svr4.c:2577
#8 svr4_relocate_main_executable () at
/build/gdb-Nav6Es/gdb-10.1/gdb/solib-svr4.c:2960
...
Description: Add auxiliary vector to vgcore files
This enables gdb to get reloca
Hello Bjørn, hello Sudip,
I just tried to locate the line where the crash happens from
the dmesg output and got to this location [1].
Unfortunately the CVS tree seems not up to date or I was using the wrong one.
At least there was a change in geoip.c in line 166 [2] [3].
Kind regards,
Bernhard
Hello Florence,
there might be still something that could be done
to retrieve some more information (if you have still
the versions installed that show the issue).
The easiest first thing might be to install the package
systemd-coredump, if possible.
Then open in another terminal 'journalctl -f'
Dear Maintainer, hello Mihai,
I tried to reconstruct the source line information of the top frames,
how they should look like if the packages
libgtk-3-0-dbgsym libglib2.0-0-dbgsym would have been installed.
#0 0x7fec909d1ce1 in __libc_signal_restore_set at
../sysdeps/unix/sysv/linux/intern
Hello Florence, dear Maintainer,
Stack trace of thread 113079:
#0 0x7f858b12ae71 raise
(libc.so.6 + 0x3ce71)
Am 16.09.21 um 00:29 schrieb Bernhard Übelacker:
exceeds what
is with these 7 places possible (would be 268 MB ?)
Short correction:
6 bytes for the hex number and 1 byte termination.
Would just give something around 16 MB as a maximum?
Kind regards,
Bernhard
Dear Maintainer,
this might be the same as reported
in #993293 against the xsane package.
Kind regards,
Bernhard
https://bugs.debian.org/993293
Dear Maintainer,
I tried to have a look and received the backtrace below [3].
As far as I see is 4.8.27 in current testing not affected.
And a 'git bisect' led to the upstream commit [1], which
is tracked in upstream bug [2].
A package 4.8.26 built with this commit is also
working as expected (s
.
Kind regards,
Bernhard
Description: Replace my_setjmp by original setjmp
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/992871
Forwarded: no
Last-Update: 2021-09-18
Index: darkplaces-0~20180908~beta1/image_png.c
Hello,
just for the record.
Upstream seems to have fixed this in [1] which
is included in kernel v5.8 and later.
Kind regards,
Bernhard
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/ui/browsers/hists.c?id=d61cbb859b45fdb6b4997f2d51834fae41af0e94
Hello Chris,
I am not involved in packaging, just trying to give some
pointers to get better information for the maintainers.
In [1] are several possible actions listed, that could be
used to get more informations.
Just to clarify, host heisenberg is your local system,
from which the connection
Hello Torbjørn Birch Moltu,
I tried to reproduce this issue inside a virtual machine.
But there the menu opens without the issue.
Does this happen to you if you startup without the wacom input attached?
Next thing you could try is to startup krita this way:
export MALLOC_CHECK_=3
krita --new
Hello,
just a small note about the toolbars in the screenshot
may be looking similar to these in bug#986821.
Kind regards,
Bernhard
https://bugs.debian.org/986821
Hello Guilhem, hello Jonas,
might this be a similar or the same issue as in #942055 ?
I took the example file from this issue,
created an armel buster chroot and ran it once at my arm5tel device,
and once at a armv7l cpu android device (unfortunately with
a non-debian kernel).
- with the arm5tel
Hello Diederik,
I am not involved in packaging, just
trying to collect some information.
Architecture: amd64 (x86_64)
The subject on the email mentions "on arm64".
From the Architecture line I assume this should read "on amd64"?
[44932.698657] python3.9[313800]: segfault at 2524310 ip 000
Am 22.05.21 um 00:11 schrieb Bernhard Übelacker:
Maybe systemd-coredump would collect a core of such a crash?
And I did a debootstrap in a loop and got three crashes out of 20 tries.
A core was collected and shows the stack below.
It is strange that exec_path shows just "/arm64"
Dear Maintainer,
I did a little further investigation and found that it could be
reproduced with just the following line, inside the arm64 chroot:
for i in {1..100}; do echo $i; python3.9 -c "exit()"; done
This produced 13 crashes for the 100 runs.
But the crashes stop to appear when /proc
Hello Ray,
Warning, a coredump from this system would be immense. Or, well anyway
pretty darn large.
systemd-coredump should limit the core to 2G.
And as a first target, the journal output might have a backtrace
from which one could start looking.
Maybe running openuniverse with a memory li
Dear Maintainer,
this backtrace looks quite similar to the reports
from following link from fedora, which started
to appear end of march.
Unfortunately I could not find a related
entry in their bug tracker.
https://retrace.fedoraproject.org/faf/problems/41770/
Kind regards,
Bernhard
401 - 500 of 1320 matches
Mail list logo
