Thanks for noting that. Of course libout123 should better use
strtok_r() instead of the plain strtok(). I added a change towards that
(with the more cautionous state pointer intialized to NULL) to the
mpg123 upstream repo.
Am Sun, 08 Dec 2024 20:24:01 +0300
schrieb "Yuriy M. Kaminskiy" :
> ==107
lude the .deb built
from that for now.
--
Dr. Thomas Orgis
HPC @ Universität Hamburg
differing mainboard vendors.
I'd be happy to install updated amd64-microcode from
bookworm-backports, but it's not there, I am stuck at
3.20230808.1.1~deb12u1 without starting to mix in packages from testing.
--
Dr. Thomas Orgis
HPC @ Universität Hamburg
Am Thu, 4 Apr 2024 09:36:37 +0200
schrieb Sebastian Ramacher :
> Now I get the following on arm{hf,el}:
>
> --- debian/libmpg123-0.symbols (libmpg123-0_1.32.6~dev+20240403022201-1_armhf)
> +++ dpkg-gensymbolspYII3c 2024-04-03 09:52:12.863133592 +
> @@ -8,8 +8,8 @@
> mpg123_current_deco
Am Wed, 03 Apr 2024 20:46:29 +0200
schrieb Simon Chopin :
> I just uploaded the attached debdiff to Ubuntu to both fix the FTBFS and
> start the t64 transition for this package, based on the following
> comment:
Are you able to test this for the dev snapshot of mpg123 before I do
the next releas
Hi again,
(after Easter hiatus … or rather xz backdoor meltdown?)
I had a stab at this, detecting a system that forces 64 bit offsets on
a 32 bit base in configure. This is to ensure that you do not encounter
the same symbol (like mpg123_tell() on two builds of the library on the
same platform of
Hi Sebastian,
thanks for not escalating on the anger that has shown through the end
of my last reply. It really seems to be an endless stream of pain that
results from once having put off_t into public API. This is the message
I have to any developer: Do not put types into your API that could
depe
Am Sat, 23 Mar 2024 21:59:54 +0500
schrieb Andrey Rakhmatullin :
> Source: mpg123
> Version: 1.32.5-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/fetch.php?pkg=mpg123&arch=armel&ver=1.32.5-1%2Bb1&stamp=1711185338&raw=0
This is being discussued in
https://bugs
Hi Sebastian,
Am Sat, 23 Mar 2024 10:40:43 +0100
schrieb Sebastian Ramacher :
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_decode_frame_32@Base
> 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_feedseek_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1#
> (arch-bits=32|arch=
Am Mon, 05 Feb 2024 08:36:28 +
schrieb Steve Langasek :
> we have identified
> mpg123 as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we
urgency=medium
+
+ * hack it for not doing any critical action
+
+ -- Thomas Orgis Fri, 21 Jul 2023 22:49:00 +0200
+
upower (0.99.17-1) unstable; urgency=medium
* New upstream version 0.99.17
Then:
apt-get --build source upower
dpkg -i upower_0.99.17-99thor_amd64.deb
(matching libupo
I also sent this already directly to Joey, but later found this bug
report. My take is this:
--- /usr/bin/ts 2019-02-20 22:03:31.0 +0100
+++ ./ts2023-03-01 21:06:41.177886024 +0100
@@ -53,6 +53,7 @@
use strict;
use POSIX q{strftime};
no warnings 'utf8';
+use open q{:locale};
Am Sat, 05 Nov 2022 12:07:57 +
schrieb Witold Baryluk :
> trying to overwrite shared '/usr/include/mpg123.h', which is
> different from other instances of package libmpg123-dev:i386
Oh, dear. I broke multiarch headers again. By trying to fix BSDs that
don't react to _FILE_OFFSET_BITS at all
Great. I released 1.26.2 now so that the package here can be updated.
pgpXAEbLMdip3.pgp
Description: Firma digital OpenPGP
I made a new snapshot now. The old one still had a conflict of off_t
and lfs_alias_t in the suffix-less prototype. I hope this does it!
https://mpg123.org/snapshot
Verify?
Am Sun, 28 Jun 2020 22:16:13 +0200
schrieb Sebastian Ramacher :
> Unfortunately the patch fails to build on i386:
Darn. Of course, sorry. This is missing:
Index: src/libsyn123/syn123.h.in
===
--- src/libsyn123/syn123.h.in (revisi
OK,
I introduced the additional wrapper now with svn commit 4743 on
svn://scm.orgis.org/mpg123 .
You can test by using current https://mpg123.org/snapshot or by
applying the attached patch.
Test reports before I release (this weekend?) are welcome.
Alrighty then,
Thomas
Index: NEWS
==
Am Thu, 25 Jun 2020 22:55:36 +0200
schrieb Sebastian Ramacher :
> Other than x32, I'm not aware of any 32-bit arch that doesn't have
> 32-bit off_t if _FILE_OFFSET_BITS is not set. So maybe architecture
A sure-fire ruleset is different …
> specific handling could be enough: if _FILE_OFFSET_BITS
Hey, I am on the path to release mpg123 1.26.2. So, how should I
approach this one here? Can someone comment on my suggestions and
possibly give a variant that works in the header without adding
function wrappers?
Alrighty then,
Thomas
Am Sun, 21 Jun 2020 11:23:32 +0200
schrieb Sebastian Ramacher :
> I am wondering why syn123 and mpg123 use different approaches to achieve
> the same thing. The mpg123-way of handling off_t using functions is
> known to work and doesn't require any quirks on the Debian packaging
> side. Why doesn
Am Sat, 20 Jun 2020 15:03:32 +0200
schrieb Christian Klein :
> A diff of the header files reveals that the i386 and amd64 versions are now
> different:
> -#define syn123_resample_total syn123_resample_total_32
> -#define syn123_resample_intotal syn123_resample_intotal_32
> +#define
Well,
as a special favour to Thorsten, I added the 'u' key now for the
upcoming mpg123 1.26.0 to (un)mute in the audio backend, at the end of
the optional buffer, so that it works immediately like pause.
This was not as easy as it sounds, as I wrote the output library
without detailed knowledge o
Hi,
any special reason why this suggestion is not posted to the mpg123 bug tracker,
or just even just mailed to upstream, but reported to the Debian project
instead?
Alrighty then,
Thomas
Am Mon, 24 Jun 2019 22:54:23 + (UTC)
schrieb Thorsten Glaser :
> >I suspect the link from alsa to pulse is faulty, as mpg123's alsa output
> >module
> >has been working fine for a long time now using proper alsa.
I just had some reproducable playback trouble on a Ubuntu 18.04 box and
mpg1
Are you using the alsa output plugin with routing to pulseaudio? I remember this
from Ubuntu systems. Running mpg123 -o pulse works, -o alsa plays static noise.
Maybe some byte offset not aligned to the data type ...
I suspect the link from alsa to pulse is faulty, as mpg123's alsa output module
ha
And? Any confirmation of the fix?
pgprqQo42wvpj.pgp
Description: Firma digital OpenPGP
Am Sun, 03 Sep 2017 20:07:43 +
schrieb Ivan Shmakov :
> > https://mpg123.org/test/mpg123-1.25.7.tar.bz2
>
> […]
>
> > Ivan, can you test your two issues with the preliminary release and
> > give feedback before I make it official?
>
> The IPv6 http_proxy= handling seems to be
I prepared fixes for both bug 872362 and 872361 for an upcoming mpg123
version 1.25.7. A preliminary release tarball is available via
https://mpg123.org/test/mpg123-1.25.7.tar.bz2
Since debian is working with 1.23.x, you might have a look at the
difference
svn diff svn://scm.orgi
Am Thu, 17 Aug 2017 09:17:01 +0200
schrieb Thomas Orgis :
> I am not able to work on this for about two weeks ... but will,
I made a change to mpg123 trunk now that
a) adds --no-visual option to diasable the behaviour and
b) disables it anyway when TERM=dumb.
The second variant will app
(mpg123 upstream here)
Yes, the terminal support in mpg123 is rather basic. It does not consult any
caps database, just hopes that the simple controls it issued are universally
understood, which obviously works against your desire regarding the cursor.
The reason for switching cursor display of
(mpg123 upstream here)
Oh. Thanks for noticing. It has been some time since IPv6 support has been
added, and frankly, the situation where I actually use IPv6 is rare. Specifying
a proxy without DNS is even more rare.
It is for sure easy to fix, but I won't be able to work on this for about two
Am Sun, 02 Jul 2017 11:12:36 +0200
schrieb Salvatore Bonaccorso :
> CVE-2017-10683[0]:
> | In mpg123 1.25.0, there is a heap-based buffer over-read in the
> | convert_latin1 function in libmpg123/id3.c. A crafted input will lead
> | to a remote denial of service attack.
I don't oppose the creati
Am Wed, 17 May 2017 08:13:32 +0200
schrieb Thomas Orgis :
> Confirmed with current upstream mpg123 1.24.0:
>
> $ mpg123 -R -o dummy
> @R MPG123 (ThOr) v8
> LP some_file.mp3
> @I ID3v2.title:some title
> @I ID3v2.artist:some band
> @I ID3v2.year:2017
> @I ID3v2.
Am Tue, 16 May 2017 09:42:57 -0700
schrieb Al Schmidt :
> pause/un-pause
> @P 2 // response: OK, playing
> file, but then...
>
> [alsa.c:230] error: Fatal problem with alsa output, error -5.
>
> [audio.c:614] error: Error in writing audio (Success?)!
>
Am Wed, 5 Oct 2016 21:34:49 +0200
schrieb Salvatore Bonaccorso :
> Any news from the DWF project on the assigned CVE?
Nothing. I got the initial request to accept the MITRE Terms of Use for
CVE from the person handling my case (I assume). I replied to the mail
at 2016-09-30. Nothing came back. I
Am Tue, 04 Oct 2016 10:03:10 +
schrieb ow...@bugs.debian.org (Debian Bug Tracking System):
> This is an automatic notification regarding your Bug report
> which was filed against the mpg123 package:
>
> #838960: denial of service with crafted id3v2 tags in all mpg123 versions
> since 0.60
>
Am Thu, 29 Sep 2016 01:20:05 +0200
schrieb Thomas Orgis :
> Still nothing. I don't expect anything to arrive anymore. Perhaps that
> Google Docs form was a joke anyway. So, please let's just get a number
> via Debian and get on with it.
Nope, eh … yes. I got a reply now f
Am Tue, 27 Sep 2016 22:39:21 +0200
schrieb Thomas Orgis :
> Well, so far I did not get a response from http://iwantacve.org/
Still nothing. I don't expect anything to arrive anymore. Perhaps that
Google Docs form was a joke anyway. So, please let's just get a number
via Debian an
Am Tue, 27 Sep 2016 18:50:35 +0200
schrieb Florian Weimer :
> Debian is a CNA-covered product, mpg123 is part of Debian,
> so it is unclear what to do here. I'll ask around.
Well, so far I did not get a response from http://iwantacve.org/
(linked from
http://cve.mitre.org/cve/data_sources_produ
Am Tue, 27 Sep 2016 10:27:04 +0100
schrieb James Cowgill :
> Does this have a CVE ID? If not it should get one.
I wondered about that. At the moment I just acted on the bug report and
pushed the fix. I have to personal experience with the CVE procedure.
In the past, just "someone" made them appe
Package: mpg123
This is mpg123 upstream formally informing you of a vulnerability
(crash on illegal memory read) in all mpg123 versions since 0.60, so
very likely all debian versions of mpg123 and libmpg123 are affected.
See more detail at http://mpg123.org/bugs/240 . A one-line fix for any
versi
Am Sun, 3 Jul 2016 13:32:20 +0200
schrieb Marco d'Itri :
> > mpg123 -o alsa [your flags]
> I see no new/specific output by adding -o alsa.
You still see the jack errors and get a segfault? Are you able to
create a backtrace? (`ulimit -c unlimited` before running mpg123 and
then analysing the c
Am Sun, 3 Jul 2016 12:14:40 +0200
schrieb Marco d'Itri :
> mpg123 --random --quiet --control --title ...
>
> [jack.c:252] error: Failed to open jack client: 0x1
> [jack.c:58] warning: FIXME: One needs to wait or write some silence here to
> prevent the last bits of audio to vanish out of the ri
Am Sun, 13 Mar 2016 17:39:38 +0100
schrieb Shérab :
> So alsa makes noise, pulse and oss play music and I believe the others
> are not too relevant...
OK, that means that probably the decoding part is fine. Maybe you have
a problem with specific output encodings.
$ mpg123 -vvv
prints a table o
Hi, (mpg123 upstream here)
does the choice of output method matter? Check
$ mpg123 --list-modules
and try some in the given list using
$ mpg123 -o $output_module_name
The easiest check to rule out an issue in the decoder binary is to
write a WAV file:
$ mpg123 -w output.wav input.mp3
This on
[The first reply may have gotten into the wrong channels, resending
with correct reply addresses.]
Hi, (mpg123 upstream here)
does the choice of output method matter? Check
$ mpg123 --list-modules
and try some in the given list using
$ mpg123 -o $output_module_name
The easiest check to rule o
Hi Yuriy!
Am Sun, 24 May 2015 23:08:12 +0300
schrieb "Yuriy M. Kaminskiy" :
> utf-16 decoder in id3 parser improperly identifies surrogate pairs,
> resulting in improper identification of characters in 0xf800-0xfffe
> range as leading surrogate and decoding failure.
>
> E.g. attempt to decode
Am Mon, 16 Jun 2014 11:43:28 -0700
schrieb Simon Kirby :
> (when does this happen?), configure is passed --with-cpu=x86_dither,
> which avoids the problem, but which is documents (in NEWS) as being for
> i586 and above.
The _dither part used to be for i586, but there is also a plain C
variant in
Am Tue, 4 Mar 2014 16:25:17 -0300
schrieb Felipe Sateler :
> >> #decodert_s16/s t_f32/s
> >> ARM 86.26 90.66
> >> generic 102.80 100.06
> >> generic_dither 121.10 100.84
> madplay -d -o null: convergence_-_points_of_view/*.mp3 &> /dev/null
> 130.22s user 1.88s system 93% cpu 2:2
Am Tue, 4 Mar 2014 11:10:25 -0300
schrieb Felipe Sateler :
> #decodert_s16/s t_f32/s
> ARM 86.26 90.66
> generic 102.80 100.06
> generic_dither 121.10 100.84
Yes, a difference, but aguably a lot less than comparing VPU code to
NEON. With the feature to produce float output from
Am Tue, 4 Mar 2014 11:49:45 +0100
schrieb Thomas Orgis :
> sh$ time -d -o null convergence_-_points_of_view/*.mp3
That should be
sh$ time madplay -d -o null: convergence_-_points_of_view/*.mp3
... as you may have guessed (notice the added ":").
Alrighty then,
Thomas
Am Tue, 04 Mar 2014 02:59:44 +
schrieb peter green :
> Is there any quality
> difference from using a fpu vs nonfpu decoder?
Technically, there is. See those numbers for generic fpu and non-fpu
code with and without --enable-int-quality given to configure (enables
better rounding for small
Am Sat, 01 Mar 2014 01:00:02 +0900
schrieb Taihei Momma :
> OK, after some investigation with armhf cross environment and qemu, finally
> the current mpg123 svn (r3517) should work
After Tahei didn't stop at this (big thanks from here!), we got a new
snapshot,
http://mpg123.org/snapsh
Am Sat, 1 Mar 2014 09:56:46 +0100
schrieb Thomas Orgis :
> Great! So, folks, please check that
>
> http://mpg123.de/snapshot/mpg123-2014030100.tar.bz2
>
> does the trick with all decoders now. Performance numbers from the
> benchmark script would be nice. I'
Am Sat, 01 Mar 2014 01:00:02 +0900
schrieb Taihei Momma :
> OK, after some investigation with armhf cross environment and qemu, finally
> the current mpg123 svn (r3517) should work (including arm_nofpu decoder).
>
> The point is .type directive. Without this directive, a linker doesn't
> disti
Am Tue, 25 Feb 2014 11:20:06 -0500
schrieb "Lennart Sorensen" :
> On Tue, Feb 25, 2014 at 11:18:50AM +0100, Thomas Orgis wrote:
> > Am Tue, 25 Feb 2014 17:37:41 +0900
> > schrieb Taihei Momma :
> >
> > > #0 0xb6fb9332 in INT123_dct64_neon () at dct64_ne
http://mpg123.org/snapshot/mpg123-20140225111416.tar.bz2 ,
and also attached the patch for the rather small change that hopefully
has a big effect. Care to test this?
Alrighty then,
Thomas
--
Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org)
OrgisNetzOr
Am Mon, 24 Feb 2014 12:27:36 -0500
schrieb "Lennart Sorensen" :
> Any help from this:
>
> Program received signal SIGILL, Illegal instruction.
> 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
> 48 vpush {q4-q7}
What the ... ? This does not make sense. I (and actual
Am Fri, 21 Feb 2014 11:25:12 -0500
schrieb "Lennart Sorensen" :
> Testing with the neon build I get a return code of 4, and it seems to
> be failing to run. It was a pain to even get it to compile. Using just
> the configure option, the assembler complained about the NEON instructions
> being i
I'm adding the mpg123 assembly guru to the CC list, as I imagine he
would be interested in why his ARM NEON code doesn't work on a Cortex
A8 chip here. Needless to say, it worked before (on other systems).
Also, the precision of the arm_nofpu code does not look right. This
topic is now shifting tow
> >> > I see. In that case, I'll have to leave the package as it until
> >> > something along those lines is implemented.
So, I got conversion to float implemented now and tested with the
generic_nofpu decoder on x86-64. It _should_ of course work with ARM,
too;-) If you'd like to check the curren
Am Mon, 17 Feb 2014 10:00:48 +0200
schrieb Riku Voipio :
> Thanks Peter for explaining, this was how I ended up the suggestion
> in the bug.
>
> > I see. In that case, I'll have to leave the package as it until
> > something along those lines is implemented.
>
> Yes. The ideal solution is for t
Am Sun, 16 Feb 2014 12:14:46 -0500
schrieb Reinhard Tartler :
> Thomas, in libavcodec, we "solve" (or rather, workaround, depending on
> the PoV) this problem by compiling the libraries multiple times
A sane approach. Runtime code selection in each application can be
stretched beyond the boundar
Sorry for being late to the party, but I have to say that this is a
rather unfortunate situation now. Not using the assembly-optimized
fixed-point ARM code of the arm_nofpu decoder and resorting to the
generic_fpu one (all plain C) will make mpg123 really slow in
comparison. I'm not sure what hardw
Am Sat, 31 Aug 2013 16:02:45 +0200
schrieb Reinhard Tartler :
> The attached patch seems to do the right thing on Debian
> kFreeBSD/i386, i386 and amd64. I've therefore uploadedit to Debian
> unstable.
Sadly, that patch still is not quite right. Now Linux/i386 mixes long
and off_t with 64 bit. T
(I'm also CCing the FreeBSD port maintainer, as I imagine they want that
handled, too.)
Am Sat, 31 Aug 2013 10:03:46 +0200
schrieb Reinhard Tartler :
> Thomas, may I have your opinion on this patch? If you are d'accord,
> I'd upload it to debian/unstable for further testing.
OK, I see that I ne
Am Wed, 28 Aug 2013 01:33:08 +0200
schrieb Thomas Orgis :
> But let me try to get my own logic straight again.
Damn, I shouldn't write such stuff late at night, the brain torn
between wildly differing problems and the urge to fall into hibernation.
> Current lfs_wrap.c is hardc
Am Tue, 27 Aug 2013 23:49:08 +0200
schrieb Reinhard Tartler :
> +if test
> ".$ac_cv_sizeof_int32_t$ac_cv_sys_file_offset_bits$ac_cv_sizeof_off_t"
> = ".4no8"; then
> + # Add dual-mode wrapper code.anyways
> + LFS_LOBJ=lfs_wrap.lo
> + ac_cv_sys_wide_off_t="yes"
> + AC_DEFI
Am Thu, 22 Aug 2013 07:46:55 +0200
schrieb Reinhard Tartler :
> That would then make mpg123 export the _64 variants in the library. Is
> this the correct behavior, even on systems that do have a 64bit off_t
> such as kfreebsd-i386? Your answer seems a bit inconclusive here to me.
>
> Wouldn't it
Well, those look fine to me:
checking for size_t... yes
checking for uintptr_t... yes
checking for ssize_t... yes
checking for off_t... yes
checking for int32_t... yes
checking for uint32_t... yes
checking for int16_t... yes
checking for uint16_t... yes
checking size of size_t... 4
checking size o
TLDR: Please check with current mpg123 snapshot and think about either
prescribing format and letting mpg123 write really raw data or make
proper use of the improper WAV header.
Hello,
mpg123 upstream here. I really did not intend to break dir2ogg in
various ways. I totally regret touching WAV wr
Am Mon, 8 Oct 2012 15:30:48 -0400
schrieb Miguel A. Colón Vélez :
> The Debian i386 architecture is supposed to support all i486 and
> later. The current package of mpg123 gets compiled with
> "--with-cpu=x86_dither"
This doesn't seem to be in effect here. First: Yes, --with-cpu=x86
superseedes
Am Mon, 8 Oct 2012 13:39:26 -0400
schrieb Miguel A. Colón Vélez :
> What I did notice was that the original user logs suggest that they
> are using "Version 0.59o (1998/Feb/08)." of mpg123. My logs show
> version 1.14.4 and that it worked with 1.14.4.
Holy macaroni! I totally overlooked that:
V
Am Sat, 6 Oct 2012 13:07:55 +0200
schrieb Pavel Machek :
> What is "the infamous memcpy optimization"? I tried brief google, but
> nothing. This? http://lwn.net/Articles/417881/ It has no details :-(.
Yeah, I am talking of the change referred to there. Damn, this is a
long time ago already. Soft
Am Fri, 5 Oct 2012 22:06:49 +0200
schrieb Pavel Machek :
> I cut this from the offending file, and it still causes the
> crash. Is it enough for debugging?
Thanks for the data and no, I cannot reproduce a crash on my main
system (not debian). I get valgrind to complain about overlapping
memcpy i
ith http://mpg123.org/snapshot --- does that work with
dir2ogg?
Alrighty then,
Thomas
--
Thomas Orgis - Source Mage GNU/Linux Developer
(http://www.sourcemage.org) OrgisNetzOrganisation ---)=-
http://orgis.org GPG public key D446D524:
http://thomas.orgis.org/public_key Fingerprint: 7236
What exactly fails? With 1.14.3 (also 1.14.2, actually) I do this:
$ mpg123 -w - bla.mp3 > bla.wav
$ mpg123 -w /dev/stdout bla.mp3 > bla2.wav
$ md5sum bla*.wav
ebcdd5f3136e11265c99c578815c4b9b bla2.wav
ebcdd5f3136e11265c99c578815c4b9b bla.wav
Same for trunk ... at least for a single file, I don
Hi again,
please consider verifying that the upcoming mpg123 release really fixes the
issue for good: http://mpg123.org/download/mpg123-1.14.3.tar.bz2
I'm waiting for confirmation before making the public announcement.
Alrighty then,
Thomas
signature.asc
Description: PGP signature
Am Tue, 12 Jun 2012 23:16:02 +0200
schrieb Thomas Orgis :
> I'm not totally sure about a followup detail about cleaner abort (it's in
> mpg123 trunk in addition to the patch), but you can expect mpg123-1.14.3
> sometime in the near future with a fix.
Update: It might b
Am Tue, 12 Jun 2012 09:25:07 +0200
schrieb Max Kellermann :
> On 2012/06/12 09:20, Thomas Orgis wrote:
> > Does plain mpg123 play the file?
> >
> > shell$ mpg123 /path/to/file.mp3
>
> No, same problem.
That is good: It means I can debug and fix without touching m
Am Mon, 11 Jun 2012 23:27:45 +0200
schrieb Max Kellermann :
> On (broken?) MP3 files, mpg123_getformat() hangs in an I/O loop that
> reads one byte at a time, seeks back 64 kB, and repeats practically
> forever. Example strace:
Does plain mpg123 play the file?
shell$ mpg123 /path/to/file.mp3
Am Tue, 8 May 2012 11:28:44 -0600 (MDT)
schrieb Paul Walmsley :
>
> Package: libmpg123-0
> Version: 1.14.0-1
> Severity: normal
> The stack trace suggests the bug may be in libmpg123, although it is of course
> difficult to know what actually corrupted the memory:
This is most likely the exact
Okay, our assembly expert got me, too: We have a fix for this in mpg123 trunk
since september last year!
I pulled that change into another 1.13 release, it is a bit different from your
patch. Could you (peter?) test
http://mpg123.org/download/mpg123-1.13.8.tar.bz2 if it builds now? I'll make i
Am Fri, 6 Apr 2012 22:27:07 -0400
schrieb Miguel Colon :
> I saw that layer3.c includes "#include "mpg123lib_intern.h" and that
> in that file there is a block:
>
> # elif defined(OPT_ARM)
> /* for arm */
> # define REAL_MUL_ASM(x, y, radix) \
>
Damn, you got me there! I really did not thin
What is this ...?
As mpg123 upstream it would be cool to get note of such issues without
having to look for them in the debian bts. Having some bot subscribe
and post to mpg123-de...@lists.sourceforge.net would be splendit; but if
that is too troublesome, sending an info to maintai...@mpg123.org w
I'm having a go at the nearly 12-year-old bug.
There is a fix in mpg123 trunk now. At least you get an error message now when
the file cannot be flushed to disk. It results in mpg123 aborting with non-zero
exit code only when the file header (or at least a single byte at the
beginning) cannot b
I, as upstream maintainer second that update request.
It seems that Daniel, who did good work over all these years as debian
maintainer of mpg123, is increasingly unavailable. Especially regarding
the upcoming freeze for the next stable debian, I really would like to
see this distro jumping to the
I cannot reproduce that on my personal box. I have a Duron at 800 MHz with
debian squeeze on it. Running mpg123 -v needs around 1% of CPU! There must be
something else going on. Also please note that nowadays, the audio output
happily gobbles up way more CPU than mpg123 needs. An example is the
Hi,
once again, I'm idly browsing the debian bug reports about mpg123,
actually wondering how I could bring you folks to update to the current
stable version (especially before freeze for next debian stable)
Now I see this bug and am a bit annoyed that no one bothered to bring
this to my attentio
I noticed a bug in the last revision... in non-utf-8 mode, the last character
was chopped off.
Revision 2771 and the updated snapshot are fixed in that respect.
Alrighty then,
Thomas.
--
Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org)
OrgisNetzOrganisation
t) if this version works for you.
Alrighty then,
Thomas.
--
Thomas Orgis - Source Mage GNU/Linux Developer (http://www.sourcemage.org)
OrgisNetzOrganisation ---)=- http://orgis.org
GPG public key D446D524: http://thomas.orgis.org/public_key
Fingerprint: 7236 3885 A742 B736 E0C8 9721 9B4C 52BC
Am Sun, 23 May 2010 02:41:04 +0400 (MSD)
schrieb William Pitcock :
> Both. I believe this is caused by a bug where the pointers appear to
> become realigned twice (e.g. to the next 16 bytes.) So I believe the
> second realignment is a bug that has always been there.
Though that assumption prove
Am Sat, 22 May 2010 03:43:28 +0400 (MSD)
schrieb William Pitcock :
> This is due to a memory alignment issue in the way that the struct is packed.
> With some help from an affected user, we bisected it to mpg123 SVN r2491.
OK, that revision replaced aligned memory blocks that relied on special
c
Am Wed, 19 May 2010 22:40:08 +0200
schrieb gregor herrmann :
> The minimal change to make the crash go away is to remove "-pie" from
> LDFLAGS.
So, we have some textrel issues, I suppose. I fail to see how mpg123 triggers
that, though. One observation I have, again in a VM with debian unstable.
Poke, poke.
Am Mon, 10 May 2010 22:54:15 +0200
schrieb gregor herrmann :
> Yup, my test results with the current (vanilla|debian) binary+lib are
> the same as yours but they are not necessarily the same as my
> original crashes, and yesterday I haven't systematically tested
> against the lib fro
Am Mon, 10 May 2010 21:23:59 +0200
schrieb Daniel Kobras :
> With drum.mp3, I'm now also seeing the segfault in an i386 chroot. amd64 is
> still fine. Building the Debian package with DEB_BUILD_OPTIONS=noharden (ie.
> without CFLAGS "-Wformat -D_FORTIFY_SOURCE=2 -fstack-protector -fPIE" and
> LDF
I just added this to the mpg123 tracker item:
I managed to reproduce a crash
(no report of double free(), but a segfault during free()) on a VM install
of debian testing, with mpg123 from unstable.
The funny thing is that I observe the debian mpg123 binary crashing with
the debian libmpg123 and a
Am Sat, 8 May 2010 00:12:09 +0200
schrieb gregor herrmann :
> Summary:
> - pulse, arts, esd, jack, nas: I have no pulse audio/artsd/esd/jackd/nas
> daemon installed
> - dummy: fails
> - alsa: still fails
> - oss: hm, somethings blocking my sound device; ah. found it later.
> no visible effects
Hi, this is mpg123 upstream.
I asked for some confirmation of the confinedness of the issue to the ALSA
output on
http://sourceforge.net/tracker/?func=detail&aid=2996045&group_id=135704&atid=733194
...
Actually, this concerns both issues: The crash and the high CPU usage. Can you
try another
I asked about details a month ago... didn't get response:-(
But the good news is that I discovered a basic problem with the ICY stream
reader which was causing desync in the stream and subsequently reading utterly
wrong bytes as ICY metadata (as there is no error check/recovery defined in ICY
m
1 - 100 of 103 matches
Mail list logo
