Bug#1056303: pg_createcluster destroys data directory under certain conditions

2023-11-20 Thread Max Kellermann 
Package: postgresql-common
Version: 248
Severity: critical

When I tried to use "pg_createcluster" to configure my pre-existing
PostgreSQL data directory with a new Debian install, it deleted the
whole cluster with all databases instead.  (This serious data loss
justifies "severity critical" according to
https://www.debian.org/Bugs/Developer#severities)

Steps to reproduce:

 pg_createcluster 15 test
 cp /etc/postgresql/15/test/postgresql.conf /var/lib/postgresql/15/test/
 rm -r /etc/postgresql/15/test
 pg_createcluster 15 test

This creates a new cluster just for the demo, then deletes the
configuration directory, after copying the postgresql.conf to the data
directory.

I expect the second "pg_createcluster" call to find the existing data
directory and configure it; and it tries to do so indeed:

 Configuring already existing cluster (configuration: /etc/postgresql/15/test, 
data: /var/lib/postgresql/15/test, owner: 103:111)

After it finds and moves a "postgresql.conf", it however fails to find
"pg_hba.conf"

 Error: move_conffile: required configuration file 
/var/lib/postgresql/15/test/pg_hba.conf does not exist

This fails the whole operation, and apparently, "pg_createcluster"
tries to roll back by invoking "pg_dropcluster 15 test 2>/dev/null",
destroying all pre-existing data.

If "postgresql.conf" does not exist (or is empty), "pg_dropcluster" is
not invoked.

Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

2023-04-11 Thread Max Kellermann 
On 2023/04/11 17:40, Andreas Henriksson  wrote:
> I think 2 is better myself and I'm attaching a proof of concept
> debdiff to implement it. (You might want to make a cleaner version.)

Agree.  I think your patch looks quite clean, and if it were submitted
to me, I'd merge it (the same would probably be necessary for the user
units).

Maybe I'd go as far and remove the Meson options; they should never
have been there in the first place.  When those options were authored
and submitted to me long ago (in 2011 by commit 83f6498aac), I didn't
know systemd exposes those directories in its pkg-config file.

Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

2023-04-11 Thread Max Kellermann 
On 2023/04/11 15:11, Andreas Henriksson  wrote:
> The culprit seems to be that mpd falls back on hard-coded path (instead
> of failing) when systemd.pc is not found!

What does this have to do with systemd.pc?  It isn't used anywhere.

Bug#1017164: mpd: FTBFS: ./obj-x86_64-linux-gnu/../src/decoder/plugins/FfmpegIo.cxx:102: undefined reference to `av_malloc(unsigned long)'

2022-08-14 Thread Max Kellermann 
On 2022/08/14 09:16, Lucas Nussbaum  wrote:
> Relevant part (hopefully):
> > /usr/bin/ld: src/decoder/plugins/libdecoder_plugins.a.p/FfmpegIo.cxx.o: in 
> > function `AvioStream::Open()':
> > ./obj-x86_64-linux-gnu/../src/decoder/plugins/FfmpegIo.cxx:102: undefined 
> > reference to `av_malloc(unsigned long)'
> > collect2: error: ld returned 1 exit status

Upstream bug report: https://github.com/MusicPlayerDaemon/MPD/issues/1582

Upstream fix: 
https://github.com/MusicPlayerDaemon/MPD/commit/59792cb0b801854ee41be72d33db9542735df754

Will soon be released as 0.23.9.

Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid

2021-11-05 Thread Max Kellermann 
On 2021/11/05 08:09, Max Kellermann  wrote:
> I gave this a second thought, and I fear that changes like this one
> break even more setups, which should be avoided in a stable branch.
> 
> I'll rather revert the "RuntimeDirectory" addition for now in the
> 0.23.x stable branch.

And this is the result of my third thought:

 
https://github.com/MusicPlayerDaemon/MPD/commit/a4e42172045f62583cbf97a6a94c3d2b9de77a6c

This keeps RuntimeDirectory, but "fixes" the pid_file problem (by
ignoring the useless pid_file setting).

Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid

2021-11-05 Thread Max Kellermann 
On 2021/11/05 06:10, Max Kellermann  wrote:
> On 2021/11/05 05:55, Florian Schlichting  wrote:
> > However, Max: behind this hides another problem, which is why I asked
> > Ryan to delete the pid_file configuration: as part of 0.23.3 you added
> > the "RuntimeDirectory=mpd" directive to both mpd.service units. In the
> > absence of User and Group directives, this causes /run/mpd to change
> > ownership from mpd:audio (as created by our
> > /usr/lib/tmpfiles.d/mpd.conf) to root:root, which means that mpd would
> > have to be run as root in order to be able to create a socket or a
> > pidfile (yes, legacy) there. I think that's broken from an upstream
> > perspective as well, and only works when running mpd as user.
> 
> True, and the real fix would be to finally cease launching MPD as
> root, which is an anachronism.

I gave this a second thought, and I fear that changes like this one
break even more setups, which should be avoided in a stable branch.

I'll rather revert the "RuntimeDirectory" addition for now in the
0.23.x stable branch.

The RuntimeDirectory will be re-added to the to-become-0.24 branch,
together with lots of other changes to modernize MPD with systemd (no
root startup, a StateDirectory for the state file, CacheDirectory for
the database file etc.)

Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid

2021-11-04 Thread Max Kellermann 
On 2021/11/05 05:55, Florian Schlichting  wrote:
> However, Max: behind this hides another problem, which is why I asked
> Ryan to delete the pid_file configuration: as part of 0.23.3 you added
> the "RuntimeDirectory=mpd" directive to both mpd.service units. In the
> absence of User and Group directives, this causes /run/mpd to change
> ownership from mpd:audio (as created by our
> /usr/lib/tmpfiles.d/mpd.conf) to root:root, which means that mpd would
> have to be run as root in order to be able to create a socket or a
> pidfile (yes, legacy) there. I think that's broken from an upstream
> perspective as well, and only works when running mpd as user.

True, and the real fix would be to finally cease launching MPD as
root, which is an anachronism.

> I suppose the best way forward is to specify User=mpd and Group=audio
> in the system unit, however this immediately hits a snag when mpd tries
> to open its log file /var/log/mpd/mpd.log, which up to now is created as
> root. This we could probably work around in Debian, and defaulting to
> log to syslog/journal also feels sensible, but I'm not sure if there may
> be other things that mpd might want to be root for when starting up as a
> system service?

The right way to have a writable /var/log/mpd is "LogsDirectory=mpd",
but I don't want to do that.  Per-daemon log files are an anachronism,
too.  Just like starting daemons as root, PID files, per-daemon
daemonization code and so on ... all the good stuff that systemd can
do for us, stuff which in ancient times every daemon had unnecessary
duplicate code for.

Another thing that MPD could fail if we don't launch MPD as root is
binding to "privileged ports" (another anachronism).  For example, a
httpd streaming output could be bound to a low port.  People who do
that could add a drop-in with
"AmbientCapabilities=CAP_NET_BIND_SERVICE" to give MPD permission for
that.

Bug#994033: mpd: Fails to find ldd libraries from libraspberrypi0 that have moved

2021-09-10 Thread Max Kellermann 
On 2021/09/10 11:43, Tim Phipps  wrote:
> AN upgrade to rasbian stable ahs moved some ldd files included in the 
> libraspberrypi0 packages and now mpd fails to start.

MPD doesn't use any of these libraries.  These are indirect
dependencies, maybe via FFmpeg?  In any case, this is not a MPD
packaging problem.

Bug#939937: Acknowledgement (Remotely exploitable null pointer dereference bug)

2019-09-11 Thread Max Kellermann 
I committed my patch to libapreq's Subversion repository:

 http://svn.apache.org/viewvc?view=revision=1866760

Bug#939937: Remotely exploitable null pointer dereference bug

2019-09-10 Thread Max Kellermann 
Package: libapreq2-3
Version: 2.13-5+b3
Severity: grave

libapreq's multipart parser can be made dereference the null pointer
by issuing a simple CURL command:

 curl http://a/b -F 'foo=bar;type=multipart/dummy'

This POSTs a "multipart/form-data" body where one part has the
Content-Type "multipart/dummy" (i.e. a nested "multipart"), which
enables this branch:

 if (ct != NULL && strncmp(ct, "multipart/", 10) == 0) {

 https://github.com/apache/apreq/blob/v2_13/library/parser_multipart.c#L401

Later, this calls create_multipart_context() and dereferences the
returned pointer (without checking it):

 next_ctx = create_multipart_context(...
 next_ctx->param_name = "";

 https://github.com/apache/apreq/blob/v2_13/library/parser_multipart.c#L409-L414

The function create_multipart_context() however can return NULL if
there is no "boundary" attribute.  And omitting "boundary" is what my
CURL command does.

With this simple exploit, I can remotely crash any process which uses
libapreq2 only by issuing an invalid nested "multipart" body.  Since
this bug is remotely exploitable, I decided to set "grave" severity.

This bug affects all libapreq2 versions ever shipped in Debian, and
was introduced by SVN commit 227276 in 2005.  Prior to this commit,
there was a NULL check, but the commit removed it:

 
http://svn.apache.org/viewvc/httpd/apreq/trunk/library/parser_multipart.c?r1=227276=227275=227276

The attached patch fixes the bug by re-adding the NULL check.
commit f27d15e47000b0442e8071ab0fd76b82df9f2d2f
Author: Max Kellermann 
Date:   Tue Sep 10 12:15:07 2019 +0200

parser_multipart: fix NULL pointer dereference in nested multipart

create_multipart_context() can return NULL if the given Content-Type
was not recognized (if there is no "boundary" attribute).  This
crashes libapreq2.

This bug was introduced by SVN commit 227276.  Prior to this commit,
there was a NULL check, but the commit removed it:

 http://svn.apache.org/viewvc/httpd/apreq/trunk/library/parser_multipart.c?r1=227276=227275=227276

diff --git a/library/parser_multipart.c b/library/parser_multipart.c
index 60b5bad..4242b7e 100644
--- a/library/parser_multipart.c
+++ b/library/parser_multipart.c
@@ -410,6 +410,10 @@ APREQ_DECLARE_PARSER(apreq_parse_multipart)
 parser->brigade_limit,
 parser->temp_dir,
 ctx->level + 1);
+if (next_ctx == NULL) {
+ctx->status = MFD_ERROR;
+goto mfd_parse_brigade;
+}
 
 next_ctx->param_name = "";

Bug#917593: mpd: FTBFS ('_IO_off64_t' has not been declared)

2018-12-28 Thread Max Kellermann 
On 2018/12/29 01:25, Santiago Vila  wrote:
> In file included from /usr/include/libroar/libroar.h:173,
>  from /usr/include/roaraudio.h:133,
>  from src/output/plugins/RoarOutputPlugin.cxx:36:
> /usr/include/libroar/vio_stdio.h:50:46: error: '_IO_off64_t' has not been 
> declared
>  int roar_vio_to_stdio_lseek (void *__cookie, _IO_off64_t *__pos, int __w);

This is clearly a libroar bug and has nothing to do with MPD.

Upstream bug report (for MPD):
https://github.com/MusicPlayerDaemon/MPD/issues/377

See https://github.com/MusicPlayerDaemon/MPD/commit/06ca08ce555 for my
opinion on this bug.

Bug#822401: [mpd-devel] [Pkg-mpd-maintainers] Bug#822401: mpd: FTBFS: error: 'uint8_t' was not declared in this scope

2016-04-25 Thread Max Kellermann 
On 2016/04/24 22:00, Florian Schlichting  wrote:
> This seems to be caused by a lacking include, fixed by the below patch.

Merged.

Bug#767504: [Pkg-mpd-maintainers] Bug#767504: mpd: licence clash with libmp4v2 (MPL) and mpd GPL-+2

2014-11-26 Thread Max Kellermann 
On 2014/11/02 21:16, Max Kellermann m...@duempel.org wrote:
 This copyright problem must be resolved by a license change of
 libmp4v2.  If no solution appears possible on their side, the plugin
 will be removed from the next MPD release.

The plugin has been removed from MPD 0.19.5, because no solution was
in sight.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767504: [Pkg-mpd-maintainers] Bug#767504: mpd: licence clash with libmp4v2 (MPL) and mpd GPL-+2

2014-11-02 Thread Max Kellermann 
On 2014/11/02 21:10, Florian Schlichting f...@debian.org wrote:
 or the mpd authors would need to give permission to link mpd against
 libmp4v2

That will not work.  It would require permission from each and every
MPD contributor, which is nearly 200 people.

This copyright problem must be resolved by a license change of
libmp4v2.  If no solution appears possible on their side, the plugin
will be removed from the next MPD release.

(I was not aware of this licensing problem when I merged the plugin.)

Max


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739410: mpd: new version fails to update with apt-get update

2014-02-18 Thread Max Kellermann 
On 2014/02/18 12:31, Sharon Kimble boudic...@talktalk.net wrote:
 Tried to update to version 0.18.8-1 today and it fails to install giving a 
 dpkg
 error code of 1.

It appears your /etc/default/mpd contains garbage that belongs in
/etc/mpd.conf, but I don't see anything in the new package that would
cause garbage to be added to /etc/default/mpd.  Are you sure this was
added by the package and not by yourself?  What does your
/etc/default/mpd look like?


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739410: mpd: new version fails to update with apt-get update

2014-02-18 Thread Max Kellermann 
On 2014/02/18 13:06, Sharon Kimble boudic...@talktalk.net wrote:
 On Tue, 18 Feb 2014 12:40:23 +0100
 Max Kellermann m...@duempel.org wrote:
 
  On 2014/02/18 12:31, Sharon Kimble boudic...@talktalk.net wrote:
   Tried to update to version 0.18.8-1 today and it fails to install
   giving a dpkg error code of 1.
  
  It appears your /etc/default/mpd contains garbage that belongs in
  /etc/mpd.conf, but I don't see anything in the new package that would
  cause garbage to be added to /etc/default/mpd.  Are you sure this was
  added by the package and not by yourself?  What does your
  /etc/default/mpd look like?
 
 I've attached my /etc/default/mpd = blank, not used, /etc/mpd.conf =
 blank, not used, and /home/$USER/cron/conf/mpd.conf = which is used. 

Not true.  Your /etc/default/mpd is not blank.  It contains the same
data as your mpd.conf, which is a mistake.  This cannot work.

This bug report is bogus, unless you can demonstrate the the package
has wrongfully copied your /etc/mpd.conf to /etc/default/mpd.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#635399: mpd segfaults when building the database

2011-07-25 Thread Max Kellermann 
On 2011/07/25 20:51, Michael Gibbs upsilon.al...@gmail.com wrote:
 Package: mpd
 Version: 0.16.2-1
 Severity: grave
 Justification: renders package unusable
 
 When attempting to rebuild the database mpd segfaults and gives the following
 message in 'dmesg':
 
 mpd[15439]: segfault at 805aebf ip b75ce7a5 sp b37b0be0 error 7 in 
 libavformat.so.52.110.0[b750a000+ff000]

Obviously not a MPD bug.  Should be moved to package libavformat52.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#613736: mpd: postinst script returned non-zero

2011-02-16 Thread Max Kellermann 
On 2011/02/16 22:56, Serafeim Zanikolas s...@debian.org wrote:
 mpd's postinst script returns non-zero because of the error_file directive in
 /etc/mpd.conf (which was deprecated in v0.16).

It was deprecated (ignored) in 0.15, and removed in 0.16.

 Starting Music Player Daemon: mpdunrecognized parameter in config file at
 line 12: error_file failed!
  invoke-rc.d: initscript mpd, action restart failed.

What do you expect the script to do?

You are using a (now-)invalid configuration file which you did not
migrate during upgrade, and you set START_MPD=true in
/etc/default/mpd.

Do you want the postinst script to ignore such a configuration error?

Max



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#601657: libffado2 thread crashes with assertion failure

2010-10-28 Thread Max Kellermann 
Package: libffado2   
Version: 2.0.1+svn1856-5
   
Severity: serious

The attached test program can trigger a (timing?) bug in libffado2,
which causes an assertion failure (i.e. crash of the whole
application).
#include libffado/ffado.h
#include stdbool.h
#include string.h
#include assert.h
#include stdio.h

enum {
MAX_STREAMS = 16,
PERIOD_SIZE = 1024,
NB_BUFFERS = 3,
};

static float buffer[PERIOD_SIZE];

static bool
configure_stream(ffado_device_t *dev, int number)
{
return ffado_streaming_set_playback_stream_buffer(dev, number, (char *)buffer) == 0 
ffado_streaming_playback_stream_onoff(dev, number, 1) == 0;
}

int main(int argc, char **argv) {
ffado_device_t *dev;

ffado_device_info_t device_info;
memset(device_info, 0, sizeof(device_info));
ffado_options_t options;
memset(options, 0, sizeof(options));
options.sample_rate = 44100;
options.period_size = PERIOD_SIZE;
options.nb_buffers = NB_BUFFERS;
options.verbose = 4;

dev = ffado_streaming_init(device_info, options);
assert(dev != NULL);

ffado_streaming_set_audio_datatype(dev, ffado_audio_datatype_float);

int num_streams = ffado_streaming_get_nb_playback_streams(dev);
assert(num_streams  0);

int streams[MAX_STREAMS], configured_streams = 0;
for (int i = 0; i  num_streams; ++i) {
if (configured_streams = 2)
break;

char name[256];
ffado_streaming_get_playback_stream_name(dev, i, name,
 sizeof(name) - 1);

ffado_streaming_stream_type type =
ffado_streaming_get_playback_stream_type(dev, i);
if (type != ffado_stream_type_audio)
continue;

printf(stream %d name='%s'\n, i, name);

streams[configured_streams++] = i;
configure_stream(dev, i);
}

if (ffado_streaming_prepare(dev) != 0) {
fprintf(stderr, ffado_streaming_prepare() failed\n);
return 1;
}

if (ffado_streaming_start(dev) != 0) {
fprintf(stderr, ffado_streaming_start() failed\n);
return 1;
}

getchar();

return 0;
}
Cannot create thread 1 Operation not permitted
ERROR: messagebuffer not initialized: 1250338856552:  (ffado.cpp)[  92] 
ffado_streaming_init: libffado 2.999.0- built Oct 16 2010 22:29:48
ERROR: messagebuffer not initialized: 1250338856611: Warning (ffado.cpp)[ 
121] ffado_streaming_init: Realtime scheduling is not enabled. This will cause 
significant reliability issues.
ERROR: messagebuffer not initialized: 1250339089620: Debug 
(devicemanager.cpp)[ 358] discover: Starting discovery...
ERROR: messagebuffer not initialized: 1250339197751: Debug (Configuration.cpp)[ 
163] showSetting:   Group: (null)
ERROR: messagebuffer not initialized: 1250339197771: Debug (Configuration.cpp)[ 
185] showSetting: vendorid = 3436 (0x0D6C)
ERROR: messagebuffer not initialized: 125033919: Debug (Configuration.cpp)[ 
185] showSetting: modelid = 65634 (0x00010062)
ERROR: messagebuffer not initialized: 1250339197783: Debug (Configuration.cpp)[ 
209] showSetting: vendorname = M-Audio
ERROR: messagebuffer not initialized: 1250339197787: Debug (Configuration.cpp)[ 
209] showSetting: modelname = FW Solo
ERROR: messagebuffer not initialized: 1250339197791: Debug (Configuration.cpp)[ 
185] showSetting: driver = 1 (0x0001)
ERROR: messagebuffer not initialized: 1250339197796: Debug (Configuration.cpp)[ 
185] showSetting: xmit_max_cycles_early_transmit = 4 (0x0004)
ERROR: messagebuffer not initialized: 1250339197885: Debug (devicemanager.cpp)[ 
620] discover: driver found for device 0
ERROR: messagebuffer not initialized: 1250339218779: Debug 
(bebob_avdevice.cpp)[ 734] loadFromCache: filename 
/home/max/.ffado/cache/000d6c0b0076ee12/006001040403.xml
ERROR: messagebuffer not initialized: 1250339224945: Debug 
(serialize_libxml.cpp)[ 230] checkVersion: Cache version: 2.999.0-, expected: 
2.999.0-.
ERROR: messagebuffer not initialized: 1250339374980: Debug (avc_unit.cpp)[ 489] 
discoverPlugConnections: Discovering PCR plug connections...
ERROR: messagebuffer not initialized: 1250339412532: Debug (avc_unit.cpp)[ 500] 
discoverPlugConnections: Discovering External plug connections...
ERROR: messagebuffer not initialized: 1250339451864: Debug 
(bebob_avdevice_subunit.cpp)[ 102] discoverConnections: Discovering 
connections...
ERROR: messagebuffer not initialized: 1250339451876: Debug (avc_subunit.cpp)[ 
148] discoverConnections: Discovering connections...
ERROR: messagebuffer not initialized: 1250339451882: Debug (avc_subunit.cpp)[ 
148] discoverConnections: Discovering connections...
ERROR: messagebuffer not initialized: 1250339451885: Debug 
(bebob_avdevice_subunit.cpp)[ 102] discoverConnections: Discovering 
connections...
ERROR: messagebuffer not

Bug#601659: Double free bug in libffado2

2010-10-28 Thread Max Kellermann 
Package: libffado2 
Version: 2.0.1+svn1856-5   
Severity: serious   

While trying to write a ffado output plugin, MPD crashed with the
following double free bug (backtrace shows it's inside libraw1394, but
my guess is that libffado calls libraw1394 with an invalid pointer):

ERROR: messagebuffer not initialized: 1250648744531: Error 
(IsoHandlerManager.cpp)[1289] ~IsoHandler: BUG: Handler still running!
ERROR: messagebuffer not initialized: 1250648744570: Error 
(IsoHandlerManager.cpp)[1289] ~IsoHandler: BUG: Handler still running!
*** glibc detected *** /usr/src/squeeze-mpd/src/mpd: double free or corruption 
(!prev): 0x01736870 ***
[...]
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffdcabd710 (LWP 5297)]
0x7fffefedc165 in *__GI_raise (sig=value optimized out) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x7fffefedc165 in *__GI_raise (sig=value optimized out) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x7fffefedef70 in *__GI_abort () at abort.c:92
#2  0x7fffeff1227b in __libc_message (do_abort=value optimized out, 
fmt=value optimized out)
at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x7fffeff1bad6 in malloc_printerr (action=3, str=0x7fffeffd2ac8 double 
free or corruption (!prev), 
ptr=value optimized out) at malloc.c:6267
#4  0x7fffeff2084c in *__GI___libc_free (mem=value optimized out) at 
malloc.c:3739
#5  0x7fffed587ff1 in raw1394_destroy_handle () from 
/usr/lib/libraw1394.so.11
#6  0x71a79a75 in IsoHandlerManager::IsoHandler::disable() () from 
/usr/lib/libffado.so.2
#7  0x71a7b99b in IsoHandlerManager::IsoTask::updateShadowMapHelper() 
() from /usr/lib/libffado.so.2
#8  0x71a7bed2 in IsoHandlerManager::IsoTask::Execute() () from 
/usr/lib/libffado.so.2
#9  0x71a9b82a in Util::PosixThread::ThreadHandler(void*) () from 
/usr/lib/libffado.so.2
#10 0x715848ba in start_thread (arg=value optimized out) at 
pthread_create.c:300
#11 0x7fffeff7902d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#12 0x in ?? ()



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#601663: libffado2 reads from freed memory

2010-10-28 Thread Max Kellermann 
Package: libffado2
Version: 2.0.1+svn1856-5
Severity: serious

libffado2 reads a lot of values from freed or uninitialized memory.
That is obviously a crash waiting to happen.  See attached valgrind
log file.

Thread 10:
Conditional jump or move depends on uninitialised value(s)
   at 0xAEE9C75: CycleTimerHelper::getCycleTimerTicks(unsigned long) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAEEB8A9: CycleTimerHelper::Execute() (in /usr/lib/libffado.so.2.999.0)
   by 0xAF15829: Util::PosixThread::ThreadHandler(void*) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)
 Uninitialised value was created by a heap allocation
   at 0x4C24DFA: operator new(unsigned long) (vg_replace_malloc.c:261)
   by 0xAEF0D8B: Ieee1394Service::Ieee1394Service() (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAED67B0: DeviceManager::initialize() (in /usr/lib/libffado.so.2.999.0)
   by 0xAEDCC4A: ffado_streaming_init (in /usr/lib/libffado.so.2.999.0)
   by 0x431A65: ffado_open (ffado_output_plugin.c:240)
   by 0x42CAB2: ao_plugin_open (output_plugin.h:196)
   by 0x42D384: ao_open (output_thread.c:164)
   by 0x42E269: audio_output_task (output_thread.c:549)
   by 0x7A40783: g_thread_create_proxy (gthread.c:1893)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)

Conditional jump or move depends on uninitialised value(s)
   at 0xAEE9C7A: CycleTimerHelper::getCycleTimerTicks(unsigned long) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAEEB8A9: CycleTimerHelper::Execute() (in /usr/lib/libffado.so.2.999.0)
   by 0xAF15829: Util::PosixThread::ThreadHandler(void*) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)
 Uninitialised value was created by a heap allocation
   at 0x4C24DFA: operator new(unsigned long) (vg_replace_malloc.c:261)
   by 0xAEF0D8B: Ieee1394Service::Ieee1394Service() (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAED67B0: DeviceManager::initialize() (in /usr/lib/libffado.so.2.999.0)
   by 0xAEDCC4A: ffado_streaming_init (in /usr/lib/libffado.so.2.999.0)
   by 0x431A65: ffado_open (ffado_output_plugin.c:240)
   by 0x42CAB2: ao_plugin_open (output_plugin.h:196)
   by 0x42D384: ao_open (output_thread.c:164)
   by 0x42E269: audio_output_task (output_thread.c:549)
   by 0x7A40783: g_thread_create_proxy (gthread.c:1893)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)

Conditional jump or move depends on uninitialised value(s)
   at 0xAEEB8DA: CycleTimerHelper::Execute() (in /usr/lib/libffado.so.2.999.0)
   by 0xAF15829: Util::PosixThread::ThreadHandler(void*) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)
 Uninitialised value was created by a heap allocation
   at 0x4C24DFA: operator new(unsigned long) (vg_replace_malloc.c:261)
   by 0xAEF0D8B: Ieee1394Service::Ieee1394Service() (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAED67B0: DeviceManager::initialize() (in /usr/lib/libffado.so.2.999.0)
   by 0xAEDCC4A: ffado_streaming_init (in /usr/lib/libffado.so.2.999.0)
   by 0x431A65: ffado_open (ffado_output_plugin.c:240)
   by 0x42CAB2: ao_plugin_open (output_plugin.h:196)
   by 0x42D384: ao_open (output_thread.c:164)
   by 0x42E269: audio_output_task (output_thread.c:549)
   by 0x7A40783: g_thread_create_proxy (gthread.c:1893)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)

Conditional jump or move depends on uninitialised value(s)
   at 0xAEEB8F7: CycleTimerHelper::Execute() (in /usr/lib/libffado.so.2.999.0)
   by 0xAF15829: Util::PosixThread::ThreadHandler(void*) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)
 Uninitialised value was created by a heap allocation
   at 0x4C24DFA: operator new(unsigned long) (vg_replace_malloc.c:261)
   by 0xAEF0D8B: Ieee1394Service::Ieee1394Service() (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAED67B0: DeviceManager::initialize() (in /usr/lib/libffado.so.2.999.0)
   by 0xAEDCC4A: ffado_streaming_init (in /usr/lib/libffado.so.2.999.0)
   by 0x431A65: ffado_open (ffado_output_plugin.c:240)
   by 0x42CAB2: ao_plugin_open (output_plugin.h:196)
   by 0x42D384: ao_open (output_thread.c:164)
   by 0x42E269: audio_output_task (output_thread.c:549)
   by 0x7A40783: g_thread_create_proxy (gthread.c:1893)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)

Conditional jump or move depends on uninitialised value(s)
   at 0xAEEB96F: CycleTimerHelper::Execute() (in /usr/lib/libffado.so.2.999.0)
   by 0xAF15829: Util::PosixThread::ThreadHandler(void*) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)
 Uninitialised value was created by a heap allocation
   at 0x4C24DFA: operator

Bug#601657: libffado2 thread crashes with assertion failure

2010-10-28 Thread Max Kellermann 
reopen 601657
thanks

On 2010/10/28 11:08, Adrian Knoth a...@drcomp.erfurt.thur.de wrote:
 On Thu, Oct 28, 2010 at 09:31:48AM +0200, Max Kellermann wrote:
 
  The attached test program can trigger a (timing?) bug in libffado2,
 
 Welcome to userlevel device drivers. For some reasons, the packets were
 not delivered or received in time.
 
 Might be a combination of period-size (lower is sometimes better),
 firewire controllers and so on.
 
 As always, svn trunk might have a fix if it's really a device specific
 error, i.e. misunderstanding of the samplerate in use.
 
  ERROR: messagebuffer not initialized: 1250338856611: Warning
  (ffado.cpp)[ 121] ffado_streaming_init: Realtime scheduling is not
  enabled. This will cause significant reliability issues.
 
 You're running it without realtime priorities? Now I see why you get
 the timing issues mentioned above.

You seem to be misunderstanding the problem here.  This is not about a
buffer xrun because the application didn't submit enough PCM samples
in time; this is about a crash due to an assertion failure, i.e. a bug
in libffado2.

Please do not close this bug report until there is a new Debian
revision which does not crash (or until there is evidence that my test
program is bugged, indirectly causing the crash).

Max



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#597731: Bug#562568: 562568: Symbol conflict with libcdio10

2010-09-22 Thread Max Kellermann 
On 2010/09/22 18:03, Matthias Klose d...@debian.org wrote:
 clone 562568 -2
 reassign -2 libmpd

How is this bug related to libmpd?  Did you mean mpd instead?



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#563192: libportaudio.so.2 overrides the libasound2 error handler

2009-12-31 Thread Max Kellermann 
Package: libportaudio2
Version: 19+svn20071022-3
Severity: grave

Upon initialization. libportaudio2 (function PaAlsa_Initialize()) sets
a new global libasound2 error handler by invoking
snd_lib_error_set_handler().  It is bad style for a library to do
this, because this may overwrite the application's custom error
handler.

Now the real critical problem: when loaded with OpenAL (libopenal1
1:1.10.622-1 in this case), libportaudio2 sets the error handler, but
gets unloaded later, rendering the memory address of
AlsaErrorHandler() invalid.  This results in a crash of the
application on the next ALSA error.

(I have submitted this bug for libportaudio2 instead of libopenal1,
because I think libportaudio2 is really doing the wrong thing by
overwriting another library's global variable; you could argue that
unloading the library is wrong in the first place)

Practical example: the Music Player Daemon, which has plugins for
OpenAL as well as for native ALSA.  Here is a crash backtrace:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe2ab6910 (LWP 31128)]
0x77e73d08 in ?? ()
(gdb) bt
#0  0x77e73d08 in ?? ()
#1  0x723fb9a6 in snd_pcm_hw_open (pcmp=0x513178, name=0x5130d0 hw:0, 
card=0, device=0, subdevice=-1, 
stream=SND_PCM_STREAM_PLAYBACK, mode=327681, mmap_emulation=0, 
sync_ptr_ioctl=0) at pcm_hw.c:1325
#2  0x723fc05e in _snd_pcm_hw_open (pcmp=0x513178, name=0x5130d0 
hw:0, root=0x538960, conf=0x55e290, 
stream=SND_PCM_STREAM_PLAYBACK, mode=327680) at pcm_hw.c:1505
#3  0x723ea527 in snd_pcm_open_conf (pcmp=0x513178, name=0x5130d0 
hw:0, pcm_root=0x538960, pcm_conf=0x55e290, 
stream=SND_PCM_STREAM_PLAYBACK, mode=327680) at pcm.c:2181
#4  0x723ea6aa in snd_pcm_open_noupdate (pcmp=0x513178, root=0x538960, 
name=0x5130d0 hw:0, 
stream=SND_PCM_STREAM_PLAYBACK, mode=327680, hop=0) at pcm.c:2219
#5  0x723ea740 in snd_pcm_open (pcmp=0x513178, name=0x5130d0 hw:0, 
stream=SND_PCM_STREAM_PLAYBACK, mode=327680)
at pcm.c:2241
#6  0x0042b34a in alsa_open (data=0x513160, audio_format=0x512d20, 
error=0x7fffe2ab6008)
at /home/max/git/mpd/src/output/alsa_plugin.c:471
#7  0x00428153 in ao_plugin_open (plugin=0x4678c0, data=0x513160, 
audio_format=0x512d20, error=0x7fffe2ab6008)
at /home/max/git/mpd/src/output_plugin.h:196
[...]


Severity grave because this allows an attacker to make MPD crash
remotely.  It might also be possible to inject and execute code this
way, if the address happens to be memory mapped later.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#560533: mpd: FTBFS: wavpack_plugin.c:75: error: 'uchar' undeclared (first use in this function)

2009-12-11 Thread Max Kellermann 
On 2009/12/11 09:30, Lucas Nussbaum lu...@lucas-nussbaum.net wrote:
 Source: mpd
 Version: 0.15.6-1
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20091210 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.

Upstream patch scheduled for 0.15.7:

 
http://git.musicpd.org/cgit/master/mpd.git/patch/?id=8f7bc70bf5e47da66e57e5606b978ba3ee975d89



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#560433: Package is empty

2009-12-10 Thread Max Kellermann 
Package: libv8-2.0.3
Version: 2.0.3-1
Severity: grave

Contrary to the package description, there is no shared library.
There is nothing except /usr/share/doc/libv8-2.0.3.  Same is true for
the -dbg package.  The symlink /usr/lib/libv8.so in the -dev package
points to a non-existing path.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#551932: mpd and mpich2: error when trying to install together

2009-10-22 Thread Max Kellermann 
On 2009/10/22 13:35, Lucas Nussbaum lu...@lucas-nussbaum.net wrote:
 Decklin, what are your thoughts on this? Would it make sense to move the
 Music Playing Daemon's mpd binary to /usr/sbin/, and the manpage to
 section 8? I have the impression (perhaps wrongly) that mpd is mainly
 start via an init script, so it wouldn't hurt too badly.

Yes, I know a whole lot of users who run MPD as a regular user.  It is
perfectly possible to run MPD on login in ~/.xsession, and there are
good reasons for doing so.

Besides that, your suggestion isn't a solution at all, because it does
not address the real problem: that there are two binaries with the
same name.  It's just an attempt to hide the symptom (path name
conflict).

 The problem is that mpd is a key binary in the mpich2 package,
 referenced all over the place, and it would really be confusing for
 users to rename it to (say) mpich2-mpd.

It would be confusing for users if /usr/bin/mpd doesn't start the
Music Player Daemon anymore, after more than 6 years.  Same thing.

There are more problems to come: mpd.py references files named
/etc/mpd.conf and ~/.mpd.conf.  Music Player Daemon uses /etc/mpd.conf
and ~/.mpdconf.  Talk about confusion.

Max



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#547525: NMU

2009-10-01 Thread Max Kellermann 
On 2009/10/01 12:06, Christophe Mutricy xto...@chewa.net wrote:
 I attend to upload a 0-day NMU to fix this FTBFS as soon as I find a
 sponsor.
 
 Debdiff and diif.gz can be found at
 http://people.videolan.org/~xtophe/debian

Not sure if it's worth it.  We will release MPD 0.15.4 on the upcoming
weekend, which includes the revert commit.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#547525: FTBFS on armel: 'OV_CALLBACKS_STREAMONLY' undeclared

2009-09-20 Thread Max Kellermann 
On 2009/09/20 16:00, Luk Claes l...@debian.org wrote:
 mpd fails to build on armel with the following message (more info in
 the full build log on buildd.d.o). This is currently one of the
 blockers for the faad2 transition.

This fails on older libvorbis versions.  For 0.15.4, we have reverted
the patch which uses the new API; will be released soon.

 
http://git.musicpd.org/cgit/master/mpd.git/commit/?h=v0.15.xid=a99202a8a4ebda1fcbedb3b024cab3b25c63adad



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542102: mpd: audio skips once per second

2009-08-18 Thread Max Kellermann 
On 2009/08/18 19:45, Peter Colberg pe...@colberg.org wrote:
 Both the workaround and the patch resolve the skipping playback.
 
 (Btw, the release-0.15.2 tag is missing in the git repository.)

Thanks again for the feedback.  I must have forgot to merge the
release tag from our release manager's repository...

Max




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542102: mpd: audio skips once per second

2009-08-17 Thread Max Kellermann 
On 2009/08/17 22:15, Peter Colberg pe...@colberg.org wrote:
 with the new version of mpd, I experience skipping audio about once per
 second, where a skip could be described as a crackling noise followed by
 a fast forward of a fraction of a second. I verified this behaviour for
 FLAC, Ogg and MP3 files.

Please enable verbose mode and watch the log file for related
messages.  Then try switching to an OSS output, and see if the same
problem occurs.

Max



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542102: mpd: audio skips once per second

2009-08-17 Thread Max Kellermann 
On 2009/08/17 22:53, Peter Colberg pe...@colberg.org wrote:
 Aug 17 22:41 : playlist: queue song 1:Miles Davis/Kind of Blue 
 (1997)/Miles Davis - Kind of Blue - 02 - Freddie Freeloader.flac

Nothing to see here, no underruns.. :(

  Then try switching to an OSS output, and see if the same
  problem occurs.
 
 A restart of mpd results in the following messages:

So does the problem occur with OSS?

Can you make a git bisect from release-0.15.1 to release-0.15.2 to
isolate the commit which broke playback for you?  It's very difficult
for me to find the cause, because I don't hear that problem over here.

Max



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542102: mpd: audio skips once per second

2009-08-17 Thread Max Kellermann 
On 2009/08/18 01:51, Peter Colberg pe...@colberg.org wrote:
 Reverting commit 7133f56 fixes the audio skips :-).

Thanks for the bisect!

I suspect this is an uninitialized variable.  Please try two
approaches at working around it:

1. mpc toggle twice (enter pause, leave pause) - this should
   initialize the pause flag retroactively

2. try the attached patch

If the patch fixes the problem, we'll release 0.15.3 soon.

Max
diff --git a/src/output_init.c b/src/output_init.c
index 04609bb..9274243 100644
--- a/src/output_init.c
+++ b/src/output_init.c
@@ -109,6 +109,7 @@ audio_output_init(struct audio_output *ao, const struct config_param *param,
 	ao-plugin = plugin;
 	ao-enabled = config_get_block_bool(param, enabled, true);
 	ao-open = false;
+	ao-pause = false;
 	ao-fail_timer = NULL;
 
 	pcm_convert_init(ao-convert_state);

Bug#476376: Bug#476377: Please port to new libmpcdec API

2009-03-21 Thread Max Kellermann 
On 2009/03/21 08:57, Sebastian Dröge sl...@circular-chaos.org wrote:
 libmpc will be uploaded to unstable in the next days. Please port your
 package to the new API ASAP, it will most probably fail to build after
 the upload to unstable.

I do not understand the hurry.  Do you plan to remove the old libmpc
package?  The Debian shared library policy guarantees that older
package continue to work/build (with older SO versions) even when a
new API of a library gets uploaded.  Please explain how this bug
report relates to the Debian shared library policy.

Max



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#512841: Segmentation fault on startup

2009-01-24 Thread Max Kellermann 
Package: smc
Version: 1.6-1
Severity: grave

When I start smc, the screen flickers black, then the process crashes
immediately.

Backtrace:

#0  0x7fd929df003d in iGetIntegervImage () from /usr/lib/libIL.so.1
#1  0x7fd92a0fc283 in iluGetImageInfo () from /usr/lib/libILU.so.1
#2  0x7fd92a300364 in CEGUI::DevILImageCodec::load () from 
/usr/lib/libCEGUIDevILImageCodec.so
#3  0x7fd93762e7f5 in CEGUI::OpenGLTexture::loadFromFile () from 
/usr/lib/libCEGUIOpenGLRenderer.so.0
#4  0x7fd93762ccc8 in CEGUI::OpenGLRenderer::createTexture () from 
/usr/lib/libCEGUIOpenGLRenderer.so.0
#5  0x7fd937913bd6 in CEGUI::Imageset_xmlHandler::elementImagesetStart () 
from /usr/lib/libCEGUIBase.so.1
#6  0x7fd93791430b in CEGUI::Imageset_xmlHandler::elementStart () from 
/usr/lib/libCEGUIBase.so.1
#7  0x7fd929813b25 in CEGUI::XercesHandler::startElement () from 
/usr/lib/libCEGUIXercesParser.so
#8  0x7fd932d549f6 in xercesc_2_8::SAX2XMLReaderImpl::startElement () from 
/usr/lib/libxerces-c.so.28
#9  0x7fd932d147b1 in xercesc_2_8::IGXMLScanner::scanStartTagNS () from 
/usr/lib/libxerces-c.so.28
#10 0x7fd932d16f9d in xercesc_2_8::IGXMLScanner::scanContent () from 
/usr/lib/libxerces-c.so.28
#11 0x7fd932d171a8 in xercesc_2_8::IGXMLScanner::scanDocument () from 
/usr/lib/libxerces-c.so.28
#12 0x7fd932d53fea in xercesc_2_8::SAX2XMLReaderImpl::parse () from 
/usr/lib/libxerces-c.so.28
#13 0x7fd929811caa in CEGUI::XercesParser::doParse () from 
/usr/lib/libCEGUIXercesParser.so
#14 0x7fd9298127e8 in CEGUI::XercesParser::parseXMLFile () from 
/usr/lib/libCEGUIXercesParser.so
#15 0x7fd93790e0f9 in CEGUI::Imageset::load () from 
/usr/lib/libCEGUIBase.so.1
#16 0x7fd93790e387 in CEGUI::Imageset::Imageset () from 
/usr/lib/libCEGUIBase.so.1
#17 0x7fd937911a63 in CEGUI::ImagesetManager::createImageset () from 
/usr/lib/libCEGUIBase.so.1
#18 0x7fd93791e846 in CEGUI::Scheme::loadXMLImagesets () from 
/usr/lib/libCEGUIBase.so.1
#19 0x7fd937921ecd in CEGUI::Scheme::loadResources () from 
/usr/lib/libCEGUIBase.so.1
#20 0x7fd937922452 in CEGUI::Scheme::Scheme () from 
/usr/lib/libCEGUIBase.so.1
#21 0x7fd937924763 in CEGUI::SchemeManager::loadScheme () from 
/usr/lib/libCEGUIBase.so.1
#22 0x00533ac6 in ?? ()
#23 0x0043500e in ?? ()
#24 0x00439415 in ?? ()
#25 0x7fd936b4c1a6 in __libc_start_main () from /lib/libc.so.6
#26 0x0040eec9 in ?? ()
#27 0x7fff41083ab8 in ?? ()
#28 0x001c in ?? ()
#29 0x0001 in ?? ()
#30 0x7fff41084ca8 in ?? ()
#31 0x in ?? ()

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.28-woodpecker (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages smc depends on:
ii  libboost-filesystem1.34.11.34.1-14   filesystem operations (portable pa
ii  libc62.7-18  GNU C Library: Shared libraries
ii  libcegui-mk2-1   0.5.0-4.1   Crazy Eddie's GUI (libraries)
ii  libcegui-mk2-dev 0.5.0-4.1   Crazy Eddie's GUI (development fil
ii  libgcc1  1:4.3.2-1.1 GCC support library
ii  libgl1-mesa-glx [libgl1] 7.0.3-7 A free implementation of the OpenG
ii  libglu1-mesa [libglu1]   7.0.3-7 The OpenGL utility library (GLU)
ii  libpng12-0   1.2.27-2PNG library - runtime
ii  libsdl-image1.2  1.2.6-3 image loading library for Simple D
ii  libsdl-mixer1.2  1.2.8-4 mixer library for Simple DirectMed
ii  libsdl-ttf2.0-0  2.0.9-1 ttf library for Simple DirectMedia
ii  libsdl1.2debian  1.2.13-2Simple DirectMedia Layer
ii  libstdc++6   4.3.2-1.1   The GNU Standard C++ Library v3
ii  libx11-6 2:1.1.5-2   X11 client-side library
ii  smc-data 1.6-1   levels and game data for Secret Ma

smc recommends no packages.

smc suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#510205: buffer overflow in libaudiofile

2008-12-30 Thread Max Kellermann 
Package: libaudiofile0
Version: 0.2.6-6
Severity: critical

Today, the Music Player Daemon project received a bug report from
Anton Khirnov: MPD crashed when attempting to play a WAV file.  file
says:

 RIFF (little-endian) data, WAVE audio, Microsoft ADPCM, stereo 44100
 Hz

The MPD bug report: http://musicpd.org/mantis/view.php?id=1915

The test file: http://filebin.ca/meqmyu/max_theme.wav

Turns out that this is a bug in libaudiofile.  When attempting to
decode the file, libaudiofile writes past the buffer in msadpcm.c:194

  code = *encoded  4;
  newSample = ms_adpcm_decode_sample(state[0], code,
  coefficient[0]);
  *decoded++ = newSample;

Valgrind output:

 ==4680== Invalid write of size 2
 ==4680==at 0x8CF0478: ms_adpcm_run_pull (msadpcm.c:194)
 ==4680==by 0x8CEAF75: _AFpull (modules.c:111)
 ==4680==by 0x8CF11A3: int2rebufferf2vrun_pull (rebuffer.template:409)
 ==4680==by 0x8CDE4ED: afReadFrames (data.c:228)
 ==4680==by 0x435EBA: audiofile_streamdecode (audiofile_plugin.c:159)
 ==4680==by 0x4145A2: decoder_stream_decode (decoder_thread.c:49)
 ==4680==by 0x414A5C: decoder_run (decoder_thread.c:189)
 ==4680==by 0x414B7B: decoder_task (decoder_thread.c:214)
 ==4680==by 0x72E0453: g_thread_create_proxy (gthread.c:635)
 ==4680==by 0x62CBFC6: start_thread (pthread_create.c:297)
 ==4680==by 0xAA595AC: clone (in /usr/lib/debug/libc-2.7.so)
 ==4680==  Address 0x15a66de8 is 0 bytes after a block of size 4,096 alloc'd
 ==4680==at 0x4C2260E: malloc (vg_replace_malloc.c:207)
 ==4680==by 0x8CDF96A: _af_malloc (util.c:122)
 ==4680==by 0x8CEEEBA: _AFsetupmodules (modules.c:2539)
 ==4680==by 0x8CDE151: afGetFrameCount (format.c:218)
 ==4680==by 0x435CDD: audiofile_streamdecode (audiofile_plugin.c:141)
 ==4680==by 0x4145A2: decoder_stream_decode (decoder_thread.c:49)
 ==4680==by 0x414A5C: decoder_run (decoder_thread.c:189)
 ==4680==by 0x414B7B: decoder_task (decoder_thread.c:214)
 ==4680==by 0x72E0453: g_thread_create_proxy (gthread.c:635)
 ==4680==by 0x62CBFC6: start_thread (pthread_create.c:297)
 ==4680==by 0xAA595AC: clone (in /usr/lib/debug/libc-2.7.so)

A quick look at the code revealed that the allocated buffer size
depended on the following formula:

  bufsize = outc-nframes * _af_format_frame_size(outc-f, AF_TRUE);

outc-nframes basically comes from _AF_ATOMIC_NVFRAMES (1024), because
the msadpcm module does not implement the max_pull callback.  This
results in a 4096 byte allocation in modules.c:2539 (frame size is 4).

In ms_adpcm_decode_block(), msadpcm-samplesPerBlock is set to 2036
(unverified value from the input file header).  outputLength is 8144,
which obviously does not fit into the allocated 4096 byte buffer.

I could reproduce the same crash with normalize-audio max_theme.wav.
The real crash happens after closing the file, probably due to heap
corruption.  valgrind notices the problem before the crash actually
occurs.

Severity critical because this is may be used for a remote DoS
attack on software like MPD.  I did not investigate whether it is
possible to inject code this way.  Chances are good, since arbitrary
amounts of heap can be overwritten.

Both Debian Etch and Lenny are affected.

Solution: don't use libaudiofile.  Change libaudiofile to allocate the
correct buffer size.  Add buffer size checks to libaudiofile.

Regards,
Max Kellermann



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#508133: audacity: munmap_chunk(): invalid pointer: 0x00000000026f4eb0

2008-12-07 Thread Max Kellermann 
Package: libmad0
Version: 0.15.1b-3
Severity: grave

I generated a raw audio file and tried to load it into audacity
(1.3.5-2).  Audacity crashed with the following message.  Looks like
it attempted to load the file as mp3; the file name had no extension.
This bug is always reproducible (tell me if you need my test file;
/dev/urandom might also do well).

Severity grave because this bug may be a remote vulnerability
(e.g. when playing remote mp3 streams).

*** glibc detected *** audacity: munmap_chunk(): invalid pointer: 
0x024d7950 ***
=== Backtrace: =
/lib/libc.so.6[0x7f4c0a23e948]
/usr/lib/libmad.so.0(mad_frame_finish+0x15)[0x7f4c0d7b3bb5]
/usr/lib/libmad.so.0[0x7f4c0d7b5cd1]
/usr/lib/libmad.so.0(mad_decoder_run+0x5f)[0x7f4c0d7b5b2f]
audacity[0x5ce4c9]
audacity[0x5c9a5c]
audacity[0x4c6680]
audacity[0x4c796c]
audacity[0x4477be]
audacity(_ZN12wxAppConsole10CallOnInitEv+0xd)[0x44812d]
/usr/lib/libwx_baseu-2.6.so.0(_Z7wxEntryRiPPw+0x23)[0x7f4c0b669573]
audacity[0x442dc2]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f4c0a1e91a6]
audacity(_ZN8wxDCBase22GetMultiLineTextExtentERK8wxStringPiS3_S3_P6wxFont+0x1a9)[0x43]
=== Memory map: 
0040-00896000 r-xp  08:02 50951588   
/usr/bin/audacity
00a95000-00ae1000 rw-p 00495000 08:02 50951588   
/usr/bin/audacity
00ae1000-00b0 rw-p 00ae1000 00:00 0 
01eea000-025fa000 rw-p 01eea000 00:00 0  [heap]
41ea4000-41ea5000 ---p 41ea4000 00:00 0 
41ea5000-426a5000 rw-p 41ea5000 00:00 0 
7f4bfd8d7000-7f4bfd937000 rw-s  00:07 9404421
/SYSV (deleted)
7f4bfd937000-7f4bfd93d000 r-xp  08:02 8494344
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so
7f4bfd93d000-7f4bfdb3d000 ---p 6000 08:02 8494344
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so
7f4bfdb3d000-7f4bfdb3e000 rw-p 6000 08:02 8494344
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so
7f4bfdb3e000-7f4bfdb4 r-xp  08:02 33723161   
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
7f4bfdb4-7f4bfdd3f000 ---p 2000 08:02 33723161   
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
7f4bfdd3f000-7f4bfdd4 rw-p 1000 08:02 33723161   
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so
7f4bfdd4-7f4bfdda rw-s  00:07 9338884
/SYSV (deleted)
7f4bfdda-7f4bfdda7000 r-xp  08:02 59226866   
/usr/lib/libgailutil.so.18.0.1
7f4bfdda7000-7f4bfdfa7000 ---p 7000 08:02 59226866   
/usr/lib/libgailutil.so.18.0.1
7f4bfdfa7000-7f4bfdfa8000 rw-p 7000 08:02 59226866   
/usr/lib/libgailutil.so.18.0.1
7f4bfdfa8000-7f4bfdfdc000 r-xp  08:02 59148264   
/usr/lib/libgnomecanvas-2.so.0.2001.0
7f4bfdfdc000-7f4bfe1db000 ---p 00034000 08:02 59148264   
/usr/lib/libgnomecanvas-2.so.0.2001.0
7f4bfe1db000-7f4bfe1dd000 rw-p 00033000 08:02 59148264   
/usr/lib/libgnomecanvas-2.so.0.2001.0
7f4bfe1dd000-7f4bfe221000 r-xp  08:02 59226871   
/usr/lib/libgnomeprintui-2-2.so.0.1.0
7f4bfe221000-7f4bfe421000 ---p 00044000 08:02 59226871   
/usr/lib/libgnomeprintui-2-2.so.0.1.0
7f4bfe421000-7f4bfe424000 rw-p 00044000 08:02 59226871   
/usr/lib/libgnomeprintui-2-2.so.0.1.0
7f4bfe424000-7f4bfe576000 r-xp  08:02 59241068   
/usr/lib/libxml2.so.2.6.32
7f4bfe576000-7f4bfe775000 ---p 00152000 08:02 59241068   
/usr/lib/libxml2.so.2.6.32
7f4bfe775000-7f4bfe77f000 rw-p 00151000 08:02 59241068   
/usr/lib/libxml2.so.2.6.32
7f4bfe77f000-7f4bfe78 rw-p 7f4bfe77f000 00:00 0 
7f4bfe78-7f4bfe797000 r-xp  08:02 59226843   
/usr/lib/libart_lgpl_2.so.2.3.20
7f4bfe797000-7f4bfe996000 ---p 00017000 08:02 59226843   
/usr/lib/libart_lgpl_2.so.2.3.20
7f4bfe996000-7f4bfe997000 rw-p 00016000 08:02 59226843   
/usr/lib/libart_lgpl_2.so.2.3.20
7f4bfe997000-7f4bfea0c000 r-xp  08:02 59812713   
/usr/lib/libgnomeprint-2-2.so.0.1.0
7f4bfea0c000-7f4bfec0b000 ---p 00075000 08:02 59812713   
/usr/lib/libgnomeprint-2-2.so.0.1.0
7f4bfec0b000-7f4bfec0e000 rw-p 00074000 08:02 59812713   
/usr/lib/libgnomeprint-2-2.so.0.1.0
7f4bfec0e000-7f4bfec0f000 rw-p 7f4bfec0e000 00:00 0 
7f4bfec0f000-7f4bfec19000 r-xp  08:02 26811946   
/lib/libnss_files-2.7.so
7f4bfec19000-7f4bfee19000 ---p a000 08:02 26811946   
/lib/libnss_files-2.7.so
7f4bfee19000-7f4bfee1b000 rw-p a000 08:02 26811946   
/lib/libnss_files-2.7.so
7f4bfee1b000-7f4bfee25000 r-xp  08:02 25172845   
/lib/libnss_nis-2.7.so
7f4bfee25000-7f4bff024000 ---p a000

Bug#505901: ABI breakage due to 02_public-headers.dpatch

2008-11-16 Thread Max Kellermann 
Package: libfaad-dev
Version: 2.6.1-3.1
Severity: grave

The patch debian/patches/02_public-headers.dpatch breaks both the faad
API and ABI.  When compiling code against the Debian package
libfaad-dev, gcc emits the following error messages (with -Werror):

decoder/aac_plugin.c: In function 'getAacFloatTotalTime':
decoder/aac_plugin.c:275: error: passing argument 4 of 'NeAACDecInit'
from incompatible pointer type
decoder/aac_plugin.c: In function 'aac_stream_decode':
decoder/aac_plugin.c:346: error: passing argument 4 of 'NeAACDecInit'
from incompatible pointer type

Upstream has unsigned long arguments where the Debian package has
uint32_t.  Code which tries to pass an unsigned long pointer here
will break both on the ABI and the API level, and this may result in
corrupted data (when copying a binary compiled with upstream, the
upper 32 bit of the long are undefined), or in a buffer overflow (when
running a Debian binary on a non-Debian machine with unmodified
libfaad, which writes 64 bit when there is room only for 32 bit).

Severity grave because Debian introduces a dangerous ABI
incompatibility with this patch, which may result in buffer overflows
(AMD64 or other platforms with a 64 bit long).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#505901: libfaad and uint32_t....

2008-11-16 Thread Max Kellermann 
severity 505901 minor
thanks

Sorry for the traffic - after some more research, I found that the
libfaad headers are inconsistent: internally, it uses uint32_t*.  This
is a very unfortante situation, since even non-bugged software will
break on Debian, assuming that passing a long pointer is correct.

There is no documentation on that issue in the Debian package - no
README.Debian, and no documentation in the patch file.  Would you mind
to add it?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#472554: erlang violates strict-aliasing rules

2008-04-05 Thread Max Kellermann 
reassign 472554 erlang 1:12.b.1-dfsg-4
thanks

Actually, this is not a GCC bug, it is just that GCC 4.3 implements
some C99 rules correctly for the first time.  In C99, the strict
aliasing rules forbid casting (long) integers to pointers.  The Erlang
internal type Eterm is an unsigned long, which gets casted around
every two lines (hidden in macros).  The described segfault happens
because GCC sees no effect in the function ets_match_2() and replaces
it with a simple jmp to ets_select_2(), leaving the stack area
pointed to by the integer variable ms undefined.  This is correct
behaviour according to the C99 standard.

This gcc behaviour is triggered by -ftree-pre -fstrict-aliasing
(included in -O2 and -O3).

To work around this violation, we should compile with
-fno-strict-aliasing.

Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#388067: *** [stampdir/patch-stamp] Error 2

2006-09-19 Thread Max Kellermann 
On 2006/09/19 09:07, Frank K?ster [EMAIL PROTECTED] wrote:
 Strangely, I cannot reproduce this here (it happened exactly
 once...).  Maybe there's again some timeskew problem, but I doubt
 it, since all these commands should take a while.  Are you able to
 reproduce this?  If yes, please apply the following patch:

Please see build1.log and build2.log.  For both builds, I started with
a fresh source checkout, applied one of your patches, and ran
dpkg-buildpackage -b 21 |tee /tmp/buildX.log.  Neither was
successful.

dpkg-buildpackage: source package is tetex-base
dpkg-buildpackage: source version is 3.0-21
dpkg-buildpackage: source changed by Frank Küster [EMAIL PROTECTED]
dpkg-buildpackage: host architecture i386
dpkg-buildpackage: source version without epoch 3.0-21
 debian/rules clean
eperl -k -P -o debian/common.functions debian/common.functions.in
test -e ../../tex-common/tex-common/debian/common.variables  test 
../../tex-common/tex-common/debian/common.variables -nt debian/common.variables 
 cp ../../tex-common/tex-common/debian/common.variables debian/ || true
test -e ../../tex-common/tex-common/debian/common.functions.in  test 
../../tex-common/tex-common/debian/common.functions.in -nt 
debian/common.functions.in  cp 
../../tex-common/tex-common/debian/common.functions.in debian/  eperl -k -P 
-o debian/common.functions debian/common.functions.in || true
eperl -k -P -o debian/rules debian/rules.in
uudecode -o debian/missingfiles.tar.gz debian/patches/missingfiles.tar.gz.uu
# quilt returns 2 if no patch is applied, but 1 if the topmost patch needs 
refreshing
quilt pop -a || test $? = 2
No patch removed
# remove ordinary files (not dirs) from missingfiles.tar.gz
for file in `tar -tzf debian/missingfiles.tar.gz`; do \
   test -f $file  rm -f $file || true; \
done
rm  -f debian/missingfiles.tar.gz
rm -f stampdir/patch-stamp
dh_testdir
dh_testroot
test -e ../../tex-common/tex-common/debian/common.variables  test 
../../tex-common/tex-common/debian/common.variables -nt debian/common.variables 
 cp ../../tex-common/tex-common/debian/common.variables debian/ || true
test -e ../../tex-common/tex-common/debian/common.functions.in  test 
../../tex-common/tex-common/debian/common.functions.in -nt 
debian/common.functions.in  cp 
../../tex-common/tex-common/debian/common.functions.in debian/  eperl -k -P 
-o debian/common.functions debian/common.functions.in || true
dh_testdir
dh_testroot
chmod +x debian/remove-bad-license-files
dh_clean -Xconfig.old ./stampdir/*-stamp ./stampdir/files* ./debian/*.links 
./debian/*.files
rm -f debian/preinst debian/postinst debian/postrm debian/tetex-base.dirs 
debian/tetex-extra.postinst debian/tetex-extra.preinst 
debian/tetex-extra.postrm debian/tetex-extra.dirs debian/setup-conflinks 
debian/common.functions debian/sarge/changelog.sed
rm -f debian/copyright
rm -f debian/missingfiles.tar.gz
 debian/rules build
eperl -k -P -o debian/common.functions debian/common.functions.in
test -e ../../tex-common/tex-common/debian/common.variables  test 
../../tex-common/tex-common/debian/common.variables -nt debian/common.variables 
 cp ../../tex-common/tex-common/debian/common.variables debian/ || true
test -e ../../tex-common/tex-common/debian/common.functions.in  test 
../../tex-common/tex-common/debian/common.functions.in -nt 
debian/common.functions.in  cp 
../../tex-common/tex-common/debian/common.functions.in debian/  eperl -k -P 
-o debian/common.functions debian/common.functions.in || true
eperl -k -P -o debian/rules debian/rules.in
uudecode -o debian/missingfiles.tar.gz debian/patches/missingfiles.tar.gz.uu
mkdir stampdir
ls -l stampdir/patch-stamp
ls: stampdir/patch-stamp: No such file or directory
make: [stampdir/patch-stamp] Error 2 (ignored)
quilt push -a
Applying patch patch-missingfiles
patching file doc/fonts/calrsfs/readme
patching file tex/latex/calrsfs/OMSrsfs.fd

Applying patch patch-context
patching file scripts/context/perl/mptopdf.pl

Applying patch patch-licenseinfo
patching file doc/generic/pstricks/README.pst-osci

Applying patch patch-texdocphp
patching file doc/tdphp/config.php
patching file doc/tdphp/texdocfooter.php

Applying patch patch-doc
patching file doc/index.html
patching file doc/mkhtml.nawk
patching file doc/helpindex.html

Applying patch patch-deb
patching file dvips/config/config.ps
patching file texdoctk/texdocrc.defaults
patching file web2c/mktex.cnf
patching file tex/generic/config/language.dat
patching file scripts/context/perl/texfind.pl
patching file scripts/context/perl/texshow.pl
patching file fonts/map/dvips/omega/omega.map
patching file fonts/map/dvips/context/original-context-symbol.map

Applying patch patch-tmp
patching file bibtex/bib/plbib/plbib.bib

Applying patch patch-dvipdfm
patching file dvipdfm/config/config

Now at patch patch-dvipdfm
tar -xzf debian/missingfiles.tar.gz
rm debian/missingfiles.tar.gz
touch stampdir/patch-stamp
ls -l stampdir/patch-stamp
-rw-r--r-- 1 root root 0 Sep 19 08:44

Bug#388258: /sbin/MAKEDEV: don't know how to make device fuse

2006-09-19 Thread Max Kellermann 
Package: fuse-utils
Version: 2.5.3-4.1
Severity: serious

The current fuse-utils is uninstallable (makedev 2.3.1-82, udev
0.100-1 installed):

Setting up fuse-utils (2.5.3-4.1) ...
creating fuse device node...
/sbin/MAKEDEV: don't know how to make device fuse
dpkg: error processing fuse-utils (--install):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 fuse-utils



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#388056: Build-Depends on ruby-dev missing

2006-09-18 Thread Max Kellermann 
Package: graphviz
Version: 2.8-2.2
Tags: ftbfs
Severity: serious

x86_64-linux-gnu-g++ -shared -nostdlib
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtbeginS.o  .libs/gv.o
.libs/gv_ruby.o  -Wl,--rpath
-Wl,/usr/src/debian/build/graphviz-2.8/lib/gvc/.libs -Wl,--rpath
-Wl,/usr/lib/graphviz ../../lib/gvc/.libs/libgvc.so -L/usr/lib -lruby
-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2
-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtfastmath.o
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crtn.o
-Wl,-soname -Wl,libgv_ruby.so.0 -o .libs/libgv_ruby.so.0.0.0
/usr/bin/ld: cannot find -lruby
collect2: ld returned 1 exit status
make[4]: *** [libgv_ruby.la] Error 1
make[4]: Leaving directory
`/usr/src/debian/build/graphviz-2.8/tclpkg/gv'


Additionally, it tries to link with the wrong library - in
ruby1.8-dev, that should be -lruby1.8 instead of -lruby.

But since the ruby stuff is not shipped with the binary package, you
should rather configure with --disable-ruby (and --disable-java, and
all the others).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#381452: locate data section to 0x10000000

2006-09-18 Thread Max Kellermann 
tag 381452 patch
thanks

This is a very ugly misdesign in the emacs core.  It uses the upper 4
bits of an elisp object pointer for type information.  These 4 bits
are restored by dereferencing the pointer by ORing it with a
well-known platform specific value, 0x1000 on mips.

The .data section indeed used to start after 0x1000 with binutils
up to 2.16.  In binutils 2.17, the ld scripts were modified, and the
.data section will start after .text, without a gap (around 0x004a
in my test cases).  Emacs, however, still ORed the pointer with
0x1000 without checking the facts, and the dereferenced pointer
was 0x104a which is invalid, and instantly led to a segmentation
fault.

I had several ideas to fix this, e.g. setting the OR value to 0, which
worked well with binutils 2.17, but would crash with older binutils.
I ended up with patching the linker script to restore the old
behaviour.  See my patch.

--- src/m/mips.h.orig   2006-09-18 13:12:35.557829500 +0200
+++ src/m/mips.h2006-09-18 13:12:37.16593 +0200
@@ -142,6 +142,12 @@
 
 /* Alter some of the options used when linking.  */
 
+#ifdef THIS_IS_MAKEFILE
+#define LD_SWITCH_MACHINE -T ../../mips.ld
+#else
+#define LD_SWITCH_MACHINE -T ../mips.ld
+#endif
+
 #if !defined(NEWSOS5)  !defined(__linux__)
 #ifdef BSD_SYSTEM
 
--- /dev/null   2006-09-14 13:24:19.0 +0200
+++ debian/mips.ld  2006-09-18 13:12:42.178243250 +0200
@@ -0,0 +1,244 @@
+/* Work around a design flaw in emacs: emacs assumes the data section
+begins on address 0x1000, which was true up to binutils version
+2.16, but the binutils 2.17 default linker script does not use this
+alignment anymore.
+
+This is actually a patched version of the file
+/usr/lib/ldscripts/elf32btsmip.x from binutils 2.17-2.  It makes the
+data section begin at 0x1000.
+
+- 2006/09/17 Max Kellermann [EMAIL PROTECTED] */
+
+/* Default linker script, for normal executables */
+OUTPUT_FORMAT(elf32-tradbigmips, elf32-tradbigmips,
+ elf32-tradlittlemips)
+OUTPUT_ARCH(mips)
+ENTRY(__start)
+SEARCH_DIR(/usr/mips-linux-gnu/lib); SEARCH_DIR(/usr/local/lib); 
SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib);
+SECTIONS
+{
+  /* Read-only sections, merged into text segment: */
+  PROVIDE (__executable_start = 0x040); . = 0x040 + 52 + 8*32;
+  .interp : { *(.interp) }
+  .reginfo: { *(.reginfo) }
+  .dynamic: { *(.dynamic) }
+  .hash   : { *(.hash) }
+  .dynsym : { *(.dynsym) }
+  .dynstr : { *(.dynstr) }
+  .gnu.version: { *(.gnu.version) }
+  .gnu.version_d  : { *(.gnu.version_d) }
+  .gnu.version_r  : { *(.gnu.version_r) }
+  .rel.init   : { *(.rel.init) }
+  .rela.init  : { *(.rela.init) }
+  .rel.text   : { *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) }
+  .rela.text  : { *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) }
+  .rel.fini   : { *(.rel.fini) }
+  .rela.fini  : { *(.rela.fini) }
+  .rel.rodata : { *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) }
+  .rela.rodata: { *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*) }
+  .rel.data.rel.ro   : { *(.rel.data.rel.ro* .rel.gnu.linkonce.d.rel.ro.*) }
+  .rela.data.rel.ro   : { *(.rela.data.rel.ro* .rela.gnu.linkonce.d.rel.ro.*) }
+  .rel.data   : { *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*) }
+  .rela.data  : { *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*) }
+  .rel.tdata : { *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*) }
+  .rela.tdata: { *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*) }
+  .rel.tbss  : { *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*) }
+  .rela.tbss : { *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*) }
+  .rel.ctors  : { *(.rel.ctors) }
+  .rela.ctors : { *(.rela.ctors) }
+  .rel.dtors  : { *(.rel.dtors) }
+  .rela.dtors : { *(.rela.dtors) }
+  .rel.got: { *(.rel.got) }
+  .rela.got   : { *(.rela.got) }
+  .rel.sdata  : { *(.rel.sdata .rel.sdata.* .rel.gnu.linkonce.s.*) }
+  .rela.sdata : { *(.rela.sdata .rela.sdata.* .rela.gnu.linkonce.s.*) }
+  .rel.sbss   : { *(.rel.sbss .rel.sbss.* .rel.gnu.linkonce.sb.*) }
+  .rela.sbss  : { *(.rela.sbss .rela.sbss.* .rela.gnu.linkonce.sb.*) }
+  .rel.sdata2 : { *(.rel.sdata2 .rel.sdata2.* .rel.gnu.linkonce.s2.*) }
+  .rela.sdata2: { *(.rela.sdata2 .rela.sdata2.* .rela.gnu.linkonce.s2.*) }
+  .rel.sbss2  : { *(.rel.sbss2 .rel.sbss2.* .rel.gnu.linkonce.sb2.*) }
+  .rela.sbss2 : { *(.rela.sbss2 .rela.sbss2.* .rela.gnu.linkonce.sb2.*) }
+  .rel.bss: { *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*) }
+  .rela.bss   : { *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*) }
+  .rel.plt: { *(.rel.plt) }
+  .rela.plt   : { *(.rela.plt) }
+  .init   :
+  {
+KEEP (*(.init))
+  } =0
+  .plt: { *(.plt) }
+  .text   :
+  {
+_ftext = . ;
+*(.text .stub .text.* .gnu.linkonce.t.*)
+KEEP (*(.text.*personality

Bug#388071: binaries are not executable

2006-09-18 Thread Max Kellermann 
Package: libgcj7-dbg
Version: 4.1.1-13
Severity: serious

None of the binaries below /usr/lib/debug/usr/bin is executable:

-rw-r--r-- root/root  8421 2006-09-08 16:03:23
./usr/lib/debug/usr/bin/gij-4.1
-rw-r--r-- root/root 71536 2006-09-08 16:03:23
./usr/lib/debug/usr/bin/gcj-dbtool-4.1
-rw-r--r-- root/root 10201 2006-09-08 16:03:23
./usr/lib/debug/usr/bin/grmiregistry-4.1
-rw-r--r-- root/root 10214 2006-09-08 16:03:23
./usr/lib/debug/usr/bin/gkeytool-4.1
-rw-r--r-- root/root 10236 2006-09-08 16:03:58
./usr/lib/debug/usr/bin/gappletviewer-4.1



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#388070: GC Warning: Couldn't read /proc/stat

2006-09-18 Thread Max Kellermann 
Package: ecj-bootstrap
Version: 3.2-3
Tags: ftbfs
Severity: serious

ecj-bootstrap won't build when /proc is not mounted.  Also note the
invalid free() call which was reported by glibc.

find build/bin -name '*.java' -exec rm -f {} \;
find build/bin -name '*.html' -exec rm -f {} \;
mkdir -p build/bootstrap
fastjar -c -C build/bin . -f build/bootstrap/ecj.jar
rm -rf build/bin
mkdir -p build/bin
cp -r src/org.eclipse.jdt.core/org build/bin/
gij-4.1 \
-classpath
build/bootstrap/ecj.jar:/usr/share/ant/lib/ant.jar \
org.eclipse.jdt.internal.compiler.batch.Main \
-bootclasspath /usr/share/java/libgcj-4.1.jar \
build/bin
GC Warning: Couldn't read /proc/stat
*** glibc detected *** free(): invalid pointer: 0x7fff22392720 ***
GC Warning: GC_get_nprocs() returned -1
make: *** [build/stamp] Aborted
Build command 'cd ecj-bootstrap-3.2  dpkg-buildpackage -b -uc'
failed.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#388070: Acknowledgement (GC Warning: Couldn't read /proc/stat)

2006-09-18 Thread Max Kellermann 
reassign 388070 gcj-4.1 4.1.1-13
tags 388070 - ftbfs
thanks

This is actually an upstream bug in gcj-4.1, so I'm reassigning this
one.  As for the invalid free() crash, here's a backtrace:

#0  0x2ba99dbf707b in *__GI_raise () from /usr/lib/debug/libc.so.6
#1  0x2ba99dbf884e in *__GI_abort () from /usr/lib/debug/libc.so.6
#2  0x2ba99dc2d639 in __libc_message () from
#/usr/lib/debug/libc.so.6
#3  0x2ba99dc341a3 in _int_free () from /usr/lib/debug/libc.so.6
#4  0x2ba99dc3422e in *__GI___libc_free () from
#/usr/lib/debug/libc.so.6
#5  0x2ba99d68a70d in __pthread_attr_destroy () from
#/usr/lib/debug/libpthread.so.0
#6  0x2ba99c8c14d3 in GC_get_thread_stack_base () at
#../../../src/boehm-gc/pthread_support.c:1140
#7  0x2ba99c8bd095 in GC_init_inner () at
#../../../src/boehm-gc/misc.c:680
#8  0x2ba99c8bd1de in GC_init () at
#../../../src/boehm-gc/misc.c:493
#9  0x2ba99c8b7843 in GC_init_gcj_malloc (mp_index=0,
#mp=0x2ba99c186820) at ../../../src/boehm-gc/gcj_mlc.c:60
#10 0x2ba99c1863e0 in _Jv_InitGC () at
#../../../src/libjava/boehm.cc:503
#11 0x2ba99c14401d in _Jv_CreateJavaVM (vm_args=0x7fff100decc0) at
#../../../src/libjava/prims.cc:1419
#12 0x2ba99c14500e in _Jv_RunMain (vm_args=0x7fff100decc0,
#klass=0x0, name=0x7fff100e0eb0 Foo, argc=1, argv=0x7fff100dedf0, 
is_jar=false) at ../../../src/libjava/prims.cc:1504
#13 0x2ba99aae0dfd in main (argc=Variable argc is not available.
) at ../../../src/libjava/gij.cc:333
#14 0x2ba99dbe44ca in __libc_start_main () from
#/usr/lib/debug/libc.so.6
#15 0x004005ca in _start () at
#../sysdeps/x86_64/elf/start.S:113




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#337127: gaim-encryption patch: check sscanf() return value

2006-09-17 Thread Max Kellermann 
On 2006/09/17 05:20, Bill Tompkins [EMAIL PROTECTED] wrote:
 Actually, I believe the bug is simply that 'realstart' is not
 assigned at the beginning of the function.  If it is set to zero,
 the check correctly detects that it wasn't assigned, and things are
 (moderately) happy:

I also considered this smaller patch, but dismissed it because the
error message would be something like can't decrypt instead of the
more correct no colon found - but you're the upstream author, you're
the one to decide..

Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#387908: ftbfs: 500_ping_icmp fails on VServer

2006-09-17 Thread Max Kellermann 
Package: perl
Version: 5.8.8-6.1
Tags: ftbfs
Severity: serious

The Perl test suite fails on the test lib/Net/Ping/t/500_ping_icmp
when run on a Linux VServer, because it tries to ping 127.0.0.1 which
is not available on a VServer.  Perl should not make assumptions on
the network setup, and should not think that 127.0.0.1 is reachable
via ICMP.

The important part of the build log:

lib/Net/Ping/t/450_serviceok
lib/Net/Ping/t/500_ping_icmp..# Failed test 2 in
../lib/Net/Ping/t/500_ping_icmp.t at line 28
#  ../lib/Net/Ping/t/500_ping_icmp.t line 28 is:   ok
$p-ping(127.0.0.1);
FAILED at test 2
lib/Net/Ping/t/510_ping_udp...ok



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#387974: postinst/postrm delete conffiles

2006-09-17 Thread Max Kellermann 
Package: dokuwiki
Version: 0.0.20060309-5
Severity: serious

dokuwiki's postinst and postrm script delete conffiles in
/etc/apache*/conf.d/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#387972: tries to stop deinstalled apache

2006-09-17 Thread Max Kellermann 
Package: dokuwiki
Version: 0.0.20060309-5
Severity: serious

When deinstalling dokuwiki, the postrm script tries to stop the apache
which has been deinstalled (but not purged) previously.  That makes
dokuwiki impossible to deinstall.

Removing dokuwiki ...
/usr/sbin/apachectl is not executable, exiting... failed!
invoke-rc.d: initscript apache, action force-reload failed.
dpkg: error processing dokuwiki (--purge):
 subprocess post-removal script returned error exit status 1
Errors were encountered while processing:
 dokuwiki
E: Sub-process /usr/bin/dpkg returned an error code (1)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#385800: use %p for printing pointers

2006-09-17 Thread Max Kellermann 
This patch uses %p to format pointers, instead of %x with an int cast.

--- assa/Reactor.cpp.orig   2006-08-13 20:56:22.0 +0200
+++ assa/Reactor.cpp2006-09-17 23:27:00.821168000 +0200
@@ -247,8 +247,8 @@
}
 
if (ret == true) {
-   DL((REACT,Found EvtH \%s\(0x%X)\n, 
-   eh_-get_id ().c_str (),int(eh_)));
+   DL((REACT,Found EvtH \%s\(%p)\n, 
+   eh_-get_id ().c_str (),eh_));
eh_-handle_close (fd);
}
 
@@ -327,8 +327,8 @@
}
 
if (ret == true  ehp != NULL) {
-   DL((REACT,Removed EvtH \%s\(0x%X)\n, 
-   ehp-get_id ().c_str (), int(ehp)));
+   DL((REACT,Removed EvtH \%s\(%p)\n, 
+   ehp-get_id ().c_str (), ehp));
ehp-handle_close (fd_);
}

Bug#387908: ftbfs: 500_ping_icmp fails on VServer

2006-09-17 Thread Max Kellermann 
On 2006/09/17 23:25, Steve Langasek [EMAIL PROTECTED] wrote:
 This is a reasonable assumption on any sanely configured Unix
 system.  VServer's failure to provide a loopback interface is
 inexcusable design brokenness.

While VServer's design decision is indeed arguable, there might be
other reasons why there is no echo-response from 127.0.0.1,
e.g. firewall rules, rate limits, icmp_echo_ignore_all.

Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#383467: fix for the upstream bug

2006-09-16 Thread Max Kellermann 
wipe-383467-lseek_returns_off_t_not_long.patch

the lseek() result is casted down to a long, which is 32 bit on
i386.  The patch changes that to off_t.


wipe-383467-target_linux.patch

shorter version of Piotr's lfs-bug-workaround.patch which allows build
on non-linux.

--- wipe.c.orig 2006-09-16 18:41:39.119581000 +0200
+++ wipe.c  2006-09-16 18:41:50.996323250 +0200
@@ -719,7 +719,7 @@
 debugf (lseek - %d, l);
 o_wipe_length = l;
 #else
-long l;
+off_t l;
 /* find device size by seeking... might work on some 
devices */
 l = lseek (fd, 0, SEEK_END);
 if (!l) {
--- debian/rules.orig   2006-09-16 18:44:15.325343250 +0200
+++ debian/rules2006-09-16 18:44:25.229962250 +0200
@@ -12,7 +12,7 @@
 
 DEB_HOST_GNU_SYSTEM := $(shell dpkg-architecture -qDEB_HOST_GNU_SYSTEM)
 
-ifeq ($(DEB_HOST_GNU_SYSTEM), linux)
+ifeq ($(DEB_HOST_GNU_SYSTEM), linux-gnu)
target = linux
 else
target = generic

Bug#337127: gaim-encryption patch: check sscanf() return value

2006-09-16 Thread Max Kellermann 
The bug is caused by a wrong sscanf() return value check.  The
sscanf() is called with two escapes, but the caller only checks
whether one of those is valid.  This patch expands the check to both
values.

--- keys.c.orig 2006-09-16 20:07:30.137499500 +0200
+++ keys.c  2006-09-16 20:07:35.621842250 +0200
@@ -211,7 +211,7 @@
   return;
}
 
-   if ( (sscanf(key_len_msg, : Len %u:%n, length, realstart)  1) ||
+   if ( (sscanf(key_len_msg, : Len %u:%n, length, realstart)  2) ||
 (realstart == 0) ) {
   gaim_debug(GAIM_DEBUG_ERROR, gaim-encryption, Error in key header\n);
   return;

Bug#337127: gaim-encryption patch: check sscanf() return value

2006-09-16 Thread Max Kellermann 
On 2006/09/16 20:11, Max Kellermann [EMAIL PROTECTED] wrote:
 The bug is caused by a wrong sscanf() return value check.  The
 sscanf() is called with two escapes, but the caller only checks
 whether one of those is valid.  This patch expands the check to both
 values.

I was wrong, since '%n' does not increment sscanf's return value.
Unfortunately, there is no way for the sscanf caller to see the
difference between everything was parsed fine and no colon
detected, the variable 'realstart' wasn't assigned.

I changed the patch and removed the colon from the sscanf format
string.  The colon check is performed manually.

--- keys.c.orig 2006-09-16 20:37:43.474826000 +0200
+++ keys.c  2006-09-16 20:32:56.464889000 +0200
@@ -211,13 +211,20 @@
   return;
}
 
-   if ( (sscanf(key_len_msg, : Len %u:%n, length, realstart)  1) ||
+   if ( (sscanf(key_len_msg, : Len %u%n, length, realstart)  1) ||
 (realstart == 0) ) {
   gaim_debug(GAIM_DEBUG_ERROR, gaim-encryption, Error in key header\n);
   return;
}
 
key_len_msg += realstart;
+   if (key_len_msg[0] != ':') {
+  gaim_debug(GAIM_DEBUG_ERROR, gaim-encryption, Colon expected\n);
+  return;
+   }
+
+   ++key_len_msg;
+
if (strlen(key_len_msg)  length) {
   gaim_debug(GAIM_DEBUG_ERROR, gaim-encryption, Length doesn't match in 
add_key\n);
   return;

Bug#374867: fixed by egenix-mx-base 2.0.6-4

2006-09-16 Thread Max Kellermann 
reassign 374867 python-egenix-mxdatetime 2.0.6-3.1
close 374867 2.0.6-4
thanks

The bug was caused by the broken version 2.0.6-3.1 of
python-egenix-mxdatetime which was missing the dependency on
python-egenix-mxtools.  Has been fixed in 2.0.6-4.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#348649: ftbfs: I can't find file `policy.aux'.

2006-02-13 Thread Max Kellermann 
On 2006/02/10 16:46, Wolfgang Baer [EMAIL PROTECTED] wrote:
 I just tried it on an uptodate sid and with an uptodate pbuilder and
 both built java-common without a problem.

It does not fail anymore; I suspect the build dependencies were
somehow not sufficient, and I upgraded a lot of other packages
meanwhile.

Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#294746: libantlr-dev is empty

2005-02-21 Thread Max Kellermann 
On 2005/02/21 23:30, Arnaud Vandyck [EMAIL PROTECTED] wrote:
 Excuse my stupid question but which files should be there?

What about the header files and the libantlr.a which were present in
previous versions of libantlr-dev? ;)

http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelistword=libantlr-devversion=testingarch=i386

Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#290496: circular build dependency

2005-01-14 Thread Max Kellermann 
Package: mcs
Version: 1.0.4-1
Severity: serious

mcs build-depends on mono-utils, which in turn depends on
mono-assemblies-base. mono-assemblies-base is a binary package
provided by mcs itself.

-- System Information:
Debian Release: 3.0
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: LANG=en_US, LC_CTYPE=de_DE (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]