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 Thu, 13 Jun 2024 20:24:33 +0800 =?UTF-8?B?RGFuYWkgU0FFLUhBTiAo6Z+T6YGU6ICQKQ==?=
wrote:
==659486== Process terminating with default action of signal 11 (SIGSEGV)
==659486== Access not within mapped region at address 0x0
==659486==at 0x4847DC4: strcmp (in
/usr/libexec/valgrind/vgprelo
On Sat, 10 Feb 2024 11:01:54 +0100 Petter Reinholdtsen wrote:
[Petter Reinholdtsen]
> I do not use ssr much myself, and have not had time to test.
I applied the upstream commit in git branch fix-1040375-glinject and
tested it on Bookworm, but alas, the .so file still segfaults with a
useless ba
Hello Cláudio,
I am not maintainer of the din package, just reading through some crash reports.
Unfortunately I cannot follow your claim "The crash occurred in the module
libzstd.so.1".
None of the 5 threads show a frame inside libzstd.
It seems just listed in the Module list.
Thread 166294 sho
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
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
Just a short addition:
There is already an upstream bug reported:
https://github.com/csound/csound/issues/1651
Kind regards,
Bernhard
Dear Maintainer,
this looks like caused by a disaggrement about the size of type OPARMS.
In libcsound64-6.0 it has 264 bytes, but in csound-plugins
only 260 bytes.
This difference is caused by the last member "mp3_mode", that is missing
in the OPARMS type used in csound-plugins.
It got introduced
Dear Maintainer,
I tried to have a look and the segfault is really a result of the
previous g_param_spec_is_valid_name failures.
It looks like g_param_spec_is_valid_name got tightened lately to
not accept names with dashes anymore.
The following malloc corruption seems to originate in the backtr
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 Jason,
> #0 0x7efbfb5f3204 n/a (libgtk-3.so.0)
> #1 0x7efbfb779a53 n/a (libgtk-3.so.0)
> #2 0x7efbfb779b11 n/a (libgtk-3.so.0)
> #3 0x7efbfb779ff1 n/a (libgtk-3.so.0)
> #4 0x7efbf96c38ee ffi_call_unix64 (libffi.so.6)
> ...
I assume you updated inkscape to current ve
Hello Jason,
thanks for the information, just some notes before.
You might want to use reply all, otherwise the answer
might get through unnoticed.
And for some reason your email did not convert sufficiently
to plain text for some reason, so it appears kind of
short at https://bugs.debian.org/9687
Hello Jason,
one small additional note. The dmesg lines you provided would have been
followed by lines "Code:". With that line it would be possible to
find at least the current instruction and source code line when the
executables are from the debian archive and the package version is
known. So ple
Dear Maintainer,
this bug might be related to bug #940839.
At least the frames Json::Reader::parse appear there too.
Kind regards,
Bernhard
Control: reassign -1 zynaddsubfx-dssi 3.0.3-1
Control: affects -1 + audacity
Hello Tjeerd,
> Thanks for coming back, I'm not in a hurry...
>
> The problem is that I can not trigger specific bugs (they seem to happen
> somewhat random). So a made some more valgrinds: valgrind.dat
Because the e
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
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 Daniel,
Am 12.12.19 um 18:27 schrieb Daniel James:
> Hi Bernhard,
>> Marking stops as 'Multi-Arch: foreign' should make
>> that installation possible.
>
> The package 'stops' contains binary instrument data, which as far as I
> know, is uniquely created by the undocumented and well-hidden i
Package: stops
Version: 0.3.0-2
Severity: wishlist
Dear Maintainer,
I was trying to look at 943335, tried to look at it
with the rr debugger which is in the archive just for amd64.
Therefore tried to install aeolus:i386 which required
a package stops:i386.
Marking stops as 'Multi-Arch: foreign'
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
Hello Seth Foley,
if possible you could now install gdb
and the following debug symbol packages.
The latter are stored in a separate
repository, more details in [1]:
handbrake-dbgsym libavformat58-dbgsym
Then if you have not rebooted since the last
handbrake crash, you can use following comma
Hello Seth Foley,
sorry for the delay.
I guess that "Core file was truncated to 2147483648 bytes." means that
the current configuration probihited to save the whole process.
So first you could try to start handbrake the following way:
ulimit -c 0
handbrake
(That might raise that limit and
Dear Maintainer,
might this be the same as I described in #923017 ?
There are two related upstream commits mentioned,
and an example gdb session pointing to
function upload_plane with visible_pitch=0 too.
Kind regards,
Bernhard
https://bugs.debian.org/923017
Hello Seth Foley,
I just tried to reproduce by following your steps.
Unfortunately I did not get a crash.
Therefore this report might not contain enough
information for the maintainers to help.
Maybe you could install the package systemd-coredump.
In the output of 'journalctl --no-pager' should t
Control: retitle 925553 audacity: with ssh X-forwarding:
PaAlsaStreamComponent_BeginPolling: Assertion `ret == self->nfds' failed.
Hello Jeff Cliff,
I looked at this backtrace without deeper knowledge of
audacity and the problem might not be a segfault in
mentioned funciton, instead a SIGABRT f
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
Hello bitfreak25,
trying to get more details out of it I recognised that my physical PC
is also using radeonsi. "Unfortunately" my vlc closes correctly.
I tried to watch how on my system vlc is running through
vout_display_opengl_Delete
and found that on mine it diverts into dri2_flush_swapbuffer
Hello,
probably you can also add following debug symbol packages:
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so ->
libgl1-mesa-dri-dbgsym
/usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 ->
libqt5dbus5-dbgsym
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
Hello
when you find such a failing to close vlc, you might
consider to run following line.
That should give you a vlc_*.txt file which contains
all threads current backtrace and might point to where
the vlc process is waiting.
for pid in `pgrep vlc`; do gdb -q --pid $pid -ex "set pagination off" -
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
Hello,
might this old bug also be related to the double free
described in bug #885606?
Kind regards,
Bernhard
Hello all,
I think this bug is a duplicate of #885606 (or vice versa).
Because the stack looks quite similar, especially
the line in libcdio.so.17 matches in both log files:
/lib/x86_64-linux-gnu/libcdio.so.17(+0x8937)
Kind regards,
Bernhard
Hello all,
I just tried to find out what caused the crash.
This bug seems to be caused by libcdio17_1.0.0-2.
In this library the memory of p_env->cdtext
gets freed once in cdtext_destroy and then
again in get_cdtext_generic.
Upstream was notified about the issue in [1] and
fixed the issue in comm
34 matches
Mail list logo
