Re: Ginkgo-CADx segfaults
On Fri, Nov 11, 2011 at 10:26 PM, Sebastian Hilbert
<sebastian.hilbert@gmx.net> wrote:
> On Friday, November 11, 2011 09:42:23 PM Mathieu Malaterre wrote:
>> On Fri, Nov 11, 2011 at 6:12 PM, Sebastian Hilbert
>>
>> <sebastian.hilbert@gmx.net> wrote:
>> > On Friday, November 11, 2011 01:55:51 AM Steve M. Robbins wrote:
>> >> On Thu, Nov 10, 2011 at 10:23:01AM +0100, Sebastian Hilbert wrote:
>> >> > On Thursday, November 10, 2011 10:03:09 AM Steffen Möller wrote:
>> >> > > Sorry for saying the obvious here, but if the bug is not
>> >> > > Debian-specific, then it should go to ITK upstream.
>> >>
>> >> I definitely encourage that patches for upstream bugs be sent
>> >> upstream.
>> >>
>> >> > The question was more along the lines if Debian packages accept
>> >> > patches which upstream refuses (have not checked with upstream ITK
>> >> > but have had issues with wxwidgets).
>> >>
>> >> It's common for Debian to have patches not in upstream. Often, in my
>> >> experience, it's not because of upstream refusal but due to differing
>> >> priority or differing release cycles. I generally have a number of
>> >> patches for Boost that upstream takes multiple releases to
>> >> incorporate.
>> >>
>> >> If you have a patch for the problem, I encourage you to submit a
>> >> Debian bug report as well as the upstream one, and link them.
>> >
>> > Raising this problem upstream at Ginkgo I was pointed to
>> >
>> > this bug report against itk upstream
>> >
>> > https://itk.icts.uiowa.edu/jira/browse/ITK-2457
>> >
>> > The comment from Mathieu there made me check which gdcm libinsighttolkit
>> > depends on in Debian
>> >
>> > http://packages.debian.org/sid/libinsighttoolkit3.20
>> >
>> > This however indicates that it already depends on gdcm 2.x
>> >
>> > which in turn means the bug is not fixed ?
>> >
>> > Supposedly most work is on itk4 which might make the problem go away.
>>
>> That's correct. ITK in debian has not been using the old GDCM 1.x
>> where a static buffer was used to decompress JPEG segment since years.
>> ITK uses a thread safe implementation in GDCM 2.x. I would think the
>> issue is not the one described in bug ITK-2457
>>
>> HTH
>
> Now that I think of it upstream release 2.6.0 seems to work better. I will
> follow up on this when this is packaged for Debian.
>
> Has the patch mentioned ever made it into ITK ?
There is no "patch" per-say. ITK policy is very strict with regards to
backward compatible API. Unfortunately GDCM 2.x did break quite a lot
of GDCM 1.x API. Since the low level GDCM API was used so much, it was
considered that breaking GDCM API would mean breaking ITK API, and
thus never made it officially into ITK. ITKv4 effort was specifically
designed with this goal in mind: break the API and cleanup old cruft.
Because I needed better DICOM functionalities in ITK, I made an option
'system GDCM' from the ITK configuration which allowed advanced users
to compile ITK against both a GDCM 1.x and GDCM 2.x API.
I believe there has been a first rc for ITKv4, so this issue should
soon be solved.
HTH
--
Mathieu
Reply to: