[Paraview] Crash when extracting surface in a big mesh
Berk Geveci
berk.geveci at kitware.com
Thu Oct 30 07:51:18 EDT 2008
Paul,
Awesome! Can you send me a patch please?
Thanks.
-berk
On Thu, Oct 30, 2008 at 6:41 AM, Paul Edwards <paul.m.edwards at gmail.com> wrote:
> Hi.
>
> I fixed the problem. I updated those 4 variables as suggested by Mike
> in vtkDataSetSurfaceFilter.h:
>
> int FastGeomQuadArrayLength;
> int NumberOfFastGeomQuadArrays;
> int NextArrayIndex;
> int NextQuadIndex;
>
> All are set to vtkIdType.
>
> Also, I needed to change how FastGeomQuadArrayLength is initialised in
> vtkDataSetSurfaceFilter::InitFastGeomQuadAllocation. So, I changed
> line 1662 from
>
> this->FastGeomQuadArrayLength = (numberOfCells / 2) * quadSize;
>
> to
>
> this->FastGeomQuadArrayLength = (numberOfCells / 2l) * quadSize;
>
> This now allows up to 2 billion cells (since the numberOfCells
> variable is passed as an int) which is sufficient for my users!
>
> Thanks for all the help,
> Paul
>
> 2008/10/28 Michael Jackson <mike.jackson at bluequartz.net>:
>> Sure he needs more than 2^31. 32 bit signed value of -1721647736
>> (0x9961BD88) can be reinterpreted as 2573319560 in unsigned 32 bit value. So
>> Paul has overflowed the capacity of a signed 32 bit integer. I had already
>> submitted a few patches for vtkDataSetSurfaceFilter for 32/64 bit issues.
>> There obviously seem to be more.
>>
>> In the header file we have:
>>
>> int FastGeomQuadArrayLength;
>>
>> And if we look at the debug session that Paul sent:
>>
>> (gdb) print this->FastGeomQuadArrayLength
>> $2 = -1721647736
>>
>> We can see that he is over flowing the index. My guess (and I have no way of
>> testing this) would be to declare some of the "int"s in that class to be
>> vtkIdType instead.
>>
>> At least these
>> int FastGeomQuadArrayLength;
>> int NumberOfFastGeomQuadArrays;
>>
>> // These indexes allow us to find the next available face.
>> int NextArrayIndex;
>> int NextQuadIndex;
>>
>> Paul, are you in a position where you can make the changes and recompile
>> paraview?
>>
>> _________________________________________________________
>> Mike Jackson mike.jackson at bluequartz.net
>> www.bluequartz.net
>>
>> On Oct 28, 2008, at 10:10 AM, Moreland, Kenneth wrote:
>>
>>> Paul,
>>>
>>> Have you compiled with VTK_USE_64BIT_IDS set to on? I wouldn't think you
>>> would be needing an id > 2^31, but if you did that could cause problems.
>>>
>>> -Ken
>>>
>>>
>>> On 10/28/08 2:12 AM, "Paul Edwards" <paul.m.edwards at gmail.com> wrote:
>>>
>>>> This is running the latest CVS version, linux (Suse 9.3) and 64bit.
>>>> It is definitely not a problem with memory allocation - the machine
>>>> has 64GB of RAM and it was only using about 14GB for the mesh with
>>>> solution (even less for the example in the last email). I did have a
>>>> quick try changing the variable to unsigned int but there were other
>>>> problems. I understand people use ParaView for much bigger meshes
>>>> but it must just be because it is all in one block.
>>>>
>>>> Regards,
>>>> Paul
>>>>
>>>> 2008/10/27 Michael Jackson <mike.jackson at bluequartz.net>:
>>>>>
>>>>> Looks like you may be running into a 32/64 bit bug. Does the program
>>>>> crash
>>>>> because it can not allocate enough memory or something else. Your gdb
>>>>> session below seems to indicate that the length variable needs to be a
>>>>> 64
>>>>> bit value, or at least unsigned.
>>>>>
>>>>> What system/compiler is this on?
>>>>> _________________________________________________________
>>>>> Mike Jackson mike.jackson at bluequartz.net
>>>>> BlueQuartz Software www.bluequartz.net
>>>>> Principal Software Engineer Dayton, Ohio
>>>>>
>>>>>
>>>>>
>>>>> On Oct 27, 2008, at 12:28 PM, Paul Edwards wrote:
>>>>>
>>>>>> Has anyone else experienced this problem? Is it just because I have
>>>>>> so many cells in one block? To reproduce: compile structured grid
>>>>>> generator that is attached, create grid with dimensions 1000 x 1000 x
>>>>>> 80, use clean to grid to make unstructured, and then try viewing the
>>>>>> surface.
>>>>>>
>>>>>> Note: this uses quite a bit of memory....
>>>>>>
>>>>>> Regards,
>>>>>> Paul
>>>>>>
>>>>>> 2008/10/17 Edwards, Paul <Paul.Edwards3 at rolls-royce.com>:
>>>>>>>
>>>>>>> I think this int needs to be unsigned (or more bits)S..
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> (gdb) frame 3
>>>>>>>
>>>>>>> #3 0x00002aaab2c053ea in vtkDataSetSurfaceFilter::NewFastGeomQuad
>>>>>>> (this=0x14fe670, numPts=4)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>> /tmp/padramgui-1.1/tmp/src/paraview/VTK/Graphics/vtkDataSetSurfaceFilter.cx
>>>>>>> x:1730
>>>>>>>
>>>>>>> 1730 this->FastGeomQuadArrays[this->NextArrayIndex]
>>>>>>>
>>>>>>> (gdb) list
>>>>>>>
>>>>>>> 1720 }
>>>>>>>
>>>>>>> 1721 }
>>>>>>>
>>>>>>> 1722 delete [] this->FastGeomQuadArrays;
>>>>>>>
>>>>>>> 1723 this->FastGeomQuadArrays = newArrays;
>>>>>>>
>>>>>>> 1724 this->NumberOfFastGeomQuadArrays = num;
>>>>>>>
>>>>>>> 1725 }
>>>>>>>
>>>>>>> 1726
>>>>>>>
>>>>>>> 1727 // Next: allocate a new array if necessary.
>>>>>>>
>>>>>>> 1728 if (this->FastGeomQuadArrays[this->NextArrayIndex] == NULL)
>>>>>>>
>>>>>>> 1729 {
>>>>>>>
>>>>>>> 1730 this->FastGeomQuadArrays[this->NextArrayIndex]
>>>>>>>
>>>>>>> 1731 = new unsigned char[this->FastGeomQuadArrayLength];
>>>>>>>
>>>>>>> 1732 }
>>>>>>>
>>>>>>> 1733
>>>>>>>
>>>>>>> 1734 vtkFastGeomQuad* q = reinterpret_cast<vtkFastGeomQuad*>
>>>>>>>
>>>>>>> 1735 (this->FastGeomQuadArrays[this->NextArrayIndex] +
>>>>>>> this->NextQuadIndex);
>>>>>>>
>>>>>>> 1736 q->numPts = numPts;
>>>>>>>
>>>>>>> 1737
>>>>>>>
>>>>>>> 1738 this->NextQuadIndex += polySize;
>>>>>>>
>>>>>>> 1739
>>>>>>>
>>>>>>> (gdb) print this->FastGeomQuadArrayLength
>>>>>>>
>>>>>>> $2 = -1721647736
>>>>>>>
>>>>>>> (gdb) whatis this->FastGeomQuadArrayLength
>>>>>>>
>>>>>>> type = int
>>>>>>>
>>>>>>> (gdb)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> More than just that variable needs to be updated though.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I experienced this when viewing the surface of a mesh with 90M cells
>>>>>>> on a
>>>>>>> single machine. Cuts worked without any problems.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>> The data contained in, or attached to, this e-mail, may contain
>>>>>>> confidential
>>>>>>> information. If you have received it in error you should notify the
>>>>>>> sender
>>>>>>> immediately by reply e-mail, delete the message from your system and
>>>>>>> contact
>>>>>>> +44 (0) 1332 242424 (the Rolls-Royce IT Security Director) if you need
>>>>>>> assistance. Please do not copy it for any purpose, or disclose its
>>>>>>> contents
>>>>>>> to any other person.
>>>>>>>
>>>>>>> An e-mail response to this address may be subject to interception or
>>>>>>> monitoring for operational reasons or for lawful business practices.
>>>>>>>
>>>>>>> (c) 2008 Rolls-Royce plc
>>>>>>>
>>>>>>> Registered office: 65 Buckingham Gate, London SW1E 6AT Company number:
>>>>>>> 1003142. Registered in England.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ParaView mailing list
>>>>>>> ParaView at paraview.org
>>>>>>> http://www.paraview.org/mailman/listinfo/paraview
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> <vtkStructuredGridGenerator.h><vtkStructuredGridGenerator.cxx><vtkStructured
>>>>>> GridGenerator.xml>_______________________________________________
>>>>>> ParaView mailing list
>>>>>> ParaView at paraview.org
>>>>>> http://www.paraview.org/mailman/listinfo/paraview
>>>>>
>>>>>
>>>> _______________________________________________
>>>> ParaView mailing list
>>>> ParaView at paraview.org
>>>> http://www.paraview.org/mailman/listinfo/paraview
>>>>
>>>>
>>>
>>>
>>> **** Kenneth Moreland
>>> *** Sandia National Laboratories
>>> ***********
>>> *** *** *** email: kmorel at sandia.gov
>>> ** *** ** phone: (505) 844-8919
>>> *** fax: (505) 845-0833
>>>
>>>
>>>
>>
>> _______________________________________________
>> ParaView mailing list
>> ParaView at paraview.org
>> http://www.paraview.org/mailman/listinfo/paraview
>>
>
More information about the ParaView
mailing list