Bug#413041: bug reproduces in standalone jasper

2007-04-06 Thread Roland Stigge
Hi Sam and Larry,

Sam Hocevar wrote:
 I don't know what went wrong the first time, I tried
 again and Electric Fence found it.  Please test.
 It works for me on both broken2.jp2 and broken4.jp2.
 
Your patch works, with all broken*.jp2 files. Here is a slightly
 better one that checks the numstepsizes value a bit before and returns
 an error instead of using assert().

Thanks for all your work on this! Your last patch looks good, and I
could upload it right away.

So, RMs, is there anything special I should care about when uploading
this lib (besides the usual QA-checks) at this stage of release? I would
just upload to unstable and ask you to let it into etch.

Thanks,

Roland


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



Bug#413041: bug reproduces in standalone jasper

2007-04-06 Thread Steve Langasek
On Fri, Apr 06, 2007 at 04:04:47PM +0200, Roland Stigge wrote:
 Hi Sam and Larry,

 Sam Hocevar wrote:
  I don't know what went wrong the first time, I tried
  again and Electric Fence found it.  Please test.
  It works for me on both broken2.jp2 and broken4.jp2.

 Your patch works, with all broken*.jp2 files. Here is a slightly
  better one that checks the numstepsizes value a bit before and returns
  an error instead of using assert().

 Thanks for all your work on this! Your last patch looks good, and I
 could upload it right away.

 So, RMs, is there anything special I should care about when uploading
 this lib (besides the usual QA-checks) at this stage of release? I would
 just upload to unstable and ask you to let it into etch.

Please do upload it to unstable, but it is no longer possible to push that
fix from unstable into etch because the binary packages will simply not be
available in time before etch is closed down for release.

So after uploading to unstable, please coordinate with the security team to
get security builds issued for both sarge and etch (this will not happen
before Monday).  Please note that sarge and etch will require separate
builds, and because sarge and etch have the same version of the package,
special care will need to be taken to ensure the etch version number sorts
after the sarge version number to cleanly support upgrades (since sarge 
etch alphabetically).

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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



Bug#413041: bug reproduces in standalone jasper

2007-04-05 Thread Sam Hocevar
tag 413041 +patch
thanks

On Tue, Mar 27, 2007, [EMAIL PROTECTED] wrote:

 I don't know what went wrong the first time, I tried
 again and Electric Fence found it.  Please test.
 It works for me on both broken2.jp2 and broken4.jp2.

   Your patch works, with all broken*.jp2 files. Here is a slightly
better one that checks the numstepsizes value a bit before and returns
an error instead of using assert().

Cheers,
-- 
Sam.
--- jasper-1.900.1.orig/src/libjasper/jpc/jpc_cs.c	2007-01-19 22:43:07.0 +0100
+++ jasper-1.900.1/src/libjasper/jpc/jpc_cs.c	2007-04-06 01:29:02.0 +0200
@@ -982,7 +982,10 @@ static int jpc_qcx_getcompparms(jpc_qcxc
 		compparms-numstepsizes = (len - n) / 2;
 		break;
 	}
-	if (compparms-numstepsizes  0) {
+	if (compparms-numstepsizes  3 * JPC_MAXRLVLS + 1) {
+		jpc_qcx_destroycompparms(compparms);
+return -1;
+} else if (compparms-numstepsizes  0) {
 		compparms-stepsizes = jas_malloc(compparms-numstepsizes *
 		  sizeof(uint_fast16_t));
 		assert(compparms-stepsizes);


Bug#413041: bug reproduces in standalone jasper

2007-03-27 Thread ldoolitt
I have to walk away from this bug for a while.  Maybe this
message can give someone else a head start.

It's quite a Heisenbug, disappearing when you put any
malloc in besides vanilla libc; I tried electric fence
and dmalloc, I understand valgrind is the same.

My comments refer to broken2.jp2.  The bug reproduces easily
in an out-of-the-box build of jasper_1.701.0.orig.tar.gz.
I find that much easier to work with than a full Debian build,
with all its shared library gyrations.

tar -xvzf jasper_1.701.0.orig.tar.gz
cd jasper-1.701.0
./configure
make
gdb src/appl/imginfo
run -f /path/to/broken2.jp2
*** glibc detected *** double free or corruption (!prev):
0x0054ecb0 ***

Program received signal SIGABRT, Aborted.
0x2b65b5d5907b in raise () from /lib/libc.so.6

I can trace the main file parsing loop that starts in
src/libjasper/jpc/jpc_dec.c:369.  It makes its way through the
get, check, process, and destroy phases of marker segments of
type SOC, SIZ, COM, COD, QCD, and QCC.  It crashes in the destroy
phase of a second QCC marker segment.  Yes, I added a bunch of
printf's.  They don't seem to affect the bug they way a different
malloc library does.

Just in case it's a hint to any jasper experts reading, the
two QCC headers printed by jpc_qcc_dumpparms() are
type = 0xff5d (QCC); len = 20;compno = 1; qntsty = 0; numguard = 2; 
numstepsizes = 16
type = 0xff5d (QCC); len = 2068;compno = 2; qntsty = 0; numguard = 2; 
numstepsizes = 2064

I have to admit that doesn't mean much to me.

 - Larry


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



Bug#413041: bug reproduces in standalone jasper

2007-03-27 Thread ldoolitt
On Tue, Mar 27, 2007 at 11:08:20AM -0700, [EMAIL PROTECTED] wrote:
 It's quite a Heisenbug, disappearing when you put any
 malloc in besides vanilla libc; I tried electric fence
 and dmalloc, I understand valgrind is the same.

I don't know what went wrong the first time, I tried
again and Electric Fence found it.  Please test.
It works for me on both broken2.jp2 and broken4.jp2.

diff -ur jasper-1.701.0/src/libjasper/jpc/jpc_dec.c 
jasper-1.701.0.new/src/libjasper/jpc/jpc_dec.c
--- jasper-1.701.0/src/libjasper/jpc/jpc_dec.c  2004-02-08 17:34:40.0 
-0800
+++ jasper-1.701.0.new/src/libjasper/jpc/jpc_dec.c  2007-03-27 
14:49:47.0 -0700
@@ -1706,6 +1706,7 @@
 
if ((flags  JPC_QCC) || !(ccp-flags  JPC_QCC)) {
ccp-flags |= flags | JPC_QSET;
+   assert (compparms-numstepsizes = 3 * JPC_MAXRLVLS + 1);
for (bandno = 0; bandno  compparms-numstepsizes; ++bandno) {
ccp-stepsizes[bandno] = compparms-stepsizes[bandno];
}


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