On Tue, Jul 03, 2012 at 11:32:11AM +0200, Etienne Millon wrote:
> > My first idea was to check if strlen(format->matrix) is within
> > reasonable boundaries, before using it to allocate memory.
>
> I think that it's perfectly reasonable for libao to segfault in such a
> case. That's the same when
> My first idea was to check if strlen(format->matrix) is within
> reasonable boundaries, before using it to allocate memory.
I think that it's perfectly reasonable for libao to segfault in such a
case. That's the same when one passes an invalid pointer to strlen or
such a function with a "strong"
On Tue, Jul 03, 2012 at 09:27:21AM +0200, Fabian Greffrath wrote:
> Am 03.07.2012 01:13, schrieb Ron:
> >Well, no ... _sanitize_matrix() only gets called if format->matrix is
> >not NULL. So I don't really see what "more robust" check it could do.
>
> My first idea was to check if strlen(format-
* Fabian Greffrath [120703 10:36]:
> Am 02.07.2012 21:36, schrieb Etienne Millon:
> >I applied the patch (including the memset - good idea !) and everything
> >works : within a i386 chroot or the multiarch version.
>
> Great! Are you going to request a freeze exception?
Yes, this fixes two RC bu
Am 02.07.2012 21:36, schrieb Etienne Millon:
I applied the patch (including the memset - good idea !) and everything
works : within a i386 chroot or the multiarch version.
Great! Are you going to request a freeze exception?
The only problem I've found is that with the alsa backend, the sound
Am 03.07.2012 01:13, schrieb Ron:
Well, no ... _sanitize_matrix() only gets called if format->matrix is
not NULL. So I don't really see what "more robust" check it could do.
My first idea was to check if strlen(format->matrix) is within
reasonable boundaries, before using it to allocate memo
On Mon, Jul 02, 2012 at 11:35:54AM +0200, Fabian Greffrath wrote:
> Am 02.07.2012 11:15, schrieb Fabian Greffrath:
> >_open_device(). I haven't digged through libao sources that much, but
> >I believe a more robust check in _sanitize_matrix() (which is where
> >the crash actually occurs) may be app
* Goswin von Brederlow [120702 13:27]:
> might I suggest adding
> memset(&driver_format, 0, sizeof(driver_format));
> That way even if the API changes and the driver_format structure grows
> it will still initialize all fields to 0, which is usualy a good default.
I applied the patch (includi
Hi,
might I suggest adding
memset(&driver_format, 0, sizeof(driver_format));
That way even if the API changes and the driver_format structure grows
it will still initialize all fields to 0, which is usualy a good default.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-dist-req
Great ! I will test that and prepare a package if everything else
works.
Thanks a lot for the debugging and the patch.
--
Etienne Millon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Am 02.07.2012 11:15, schrieb Fabian Greffrath:
_open_device(). I haven't digged through libao sources that much, but
I believe a more robust check in _sanitize_matrix() (which is where
the crash actually occurs) may be appropriate.
The critical part is _sanitize_matrix() calling "char *ret =
c
tags 679826 + patch
thanks
Am 02.07.2012 10:40, schrieb Fabian Greffrath:
I have reproduced this. It crashes in src/linux/audio.c in
SoundInit_ao() around line 195 when it calls "audio_device =
ao_open_live(driver_id, &driver_format, 0);". The return value of
audio_device is checked, but it does
Am 02.07.2012 10:00, schrieb Goswin von Brederlow:
The first one looks like a problem in libxcb and I would start with the other
errors.So look at InitSound (audio.c:197) and initwinvideo (sdllink.c:1088).
Maybe add some printfs in there or set breakpoints in gdb.
I have reproduced this. It cra
On Mon, 2 Jul 2012 07:35:57 +0930, Ron wrote:
> FWIW severity 'grave' for #679826 looks just a tad hysterical.
grave: makes the package in question unusable by most or all users,
or causes data loss, or introduces a security hole allowing
access to the accounts of users who use the p
On Sun, Jul 01, 2012 at 11:13:23PM +0200, Etienne Millon wrote:
> * Ron [120701 23:07]:
> > Strace probably won't help a lot here, the problem isn't really tied
> > to interactions with system calls - my first guess would probably be
> > that something in zsnes isn't checking an error return that
Package: zsnes
Version: 1.510+bz2-3
Severity: grave
Running zsnes in a wheezy i386 chroot gives a segfault:
# zsnes
ZSNES v1.51, (c) 1997-2007, ZSNES Team
Be sure to check http://www.zsnes.com/ for the latest version.
ZSNES is written by the ZSNES Team (See AUTHORS.TXT)
ZSNES comes with ABSOLUTE
16 matches
Mail list logo
