[Debian-med-packaging] Bug#816607: void EncoderStrategy::AppendToBitStream(LONG, LONG): Assertion `bitpos >=0' failed

Sjors Gielen sjors at sjorsgielen.nl
Thu Mar 3 22:09:16 UTC 2016


Hello Matthieu,

A test case is attached. It allocates an uncompressed 1165 by 1434 pixel
16-bit image, and writes a relatively small set of pixels while still
reproducing the issue.

It then fills a DcmFileFormat wih the values required to store it as a
valid Dicom JPEG-LS image. During the dcmff.saveFile() call, the assertion
failure happens:

test_dcmtk: /home/sjors/src/charls-1.0/encoderstrategy.h:81: void
EncoderStrategy::AppendToBitStream(LONG, LONG): Assertion `bitpos >=0'
failed.

Hopefully this will allow you to reproduce as well. I know about three
fixes/workarounds (I don't know which one applies):
1. The patch dcmtk applied, which returns before the assertion is ever
checked,
2. Calling Flush() again if bitpos is still lower than 0, or
3. Increasing the amount of iterations in Flush() so that bitpos cannot be
lower than 0 after returning from that function.

Maybe some input from the CharLS developers would be useful here.

Sjors

Op do 3 mrt. 2016 om 22:37 schreef Sjors Gielen <sjors at sjorsgielen.nl>:

> Hello Mathieu,
>
> I have a working test-case, but as it contains an uncompressed image, it
> is currently 7 MB. I'm trying to make it smaller before I'll upload it, and
> hope to have that done by tomorrow. It uses CharLS through DCMTK – which,
> on Debian, uses system CharLS, not the DCMTK-shipped one.
>
> I have been using the patch you linked as a workaround in the past, but
> upstream CharLS has expressed doubts over the patch as committed to DCMTK's
> shipped CharLS. I haven't verified these doubts myself, but the patch is
> not applied to CharLS upstream either. See:
> http://charls.codeplex.com/workitem/10742 and
> https://github.com/team-charls/charls/blob/master/src/encoderstrategy.h#L83
> .
>
> Interestingly, in the first link above, upstream says the problem is
> linked in this changeset:
> https://github.com/team-charls/charls/commit/c7cf959f348f8e0c47f1197c89ef959372c572e9> I can see that that changeset adds a test, but not that it fixes the actual
> issue upstream...
>
> Sjors
>
> Op do 3 mrt. 2016 om 21:15 schreef Mathieu Malaterre <malat at debian.org>:
>
>> Control: tags -1 moreinfo
>>
>> Dear OP,
>>
>> Since you did not provide material to reproduce the issue, did you try
>> the proposed patch ?
>>
>>
>> http://git.dcmtk.org/?p=dcmtk.git;a=commitdiff;h=d885abd90ef90f6566555298064190561ff0412a
>>
>> Unless some kind of sample file is provided I cannot possibly include
>> a fix for the next upload.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160303/82150e56/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_dcmtk.cpp
Type: text/x-c++src
Size: 1306349 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160303/82150e56/attachment-0001.cpp>


More information about the Debian-med-packaging mailing list