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

Sjors Gielen sjors at sjorsgielen.nl
Thu Mar 3 22:10:36 UTC 2016


I forgot to mention, to compile this testcase:

g++ test_dcmtk.cpp -O0 -g -o test_dcmtk -rdynamic -ldcmdata -ldcmimage
-ldcmimgle -ldcmjpeg -ldcmnet -ldcmpstat -ldcmqrdb -ldcmsr -ldcmtls -lijg12
-lijg16 -lijg8 -lofstd -ldcmjpls -loflog -I/usr/include -DHAVE_CONFIG_H

It ignores any arguments given at runtime.

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

> 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/7c8f659f/attachment-0001.html>


More information about the Debian-med-packaging mailing list