(0013849)
Zhanping Liu (developer)
2008-10-10 16:32

The bug has been fixed.

It was due to not providing a name for

   ==========================
   vtkFloatArray *newTCoords;
   ==========================

   in vtkLineSource::RequestData() --- line 85 ~ line 88

   =====================================
   newTCoords = vtkFloatArray::New();
   newTCoords->SetNumberOfComponents(2);
   newTCoords->Allocate(2*numPts);
   newLines = vtkCellArray::New();
   =====================================

   which is, though, then evaluated in tkExodusIIWriter::FlattenOutVariableNames() --- line 1027 --- through

   ======================================
   if (strlen(nms[i]) > MAX_STR_LENGTH-2)
   ======================================

   Now a name "Texture Coordinates" has been provided in the very segment

   ==========================================
   newTCoords = vtkFloatArray::New();
   newTCoords->SetNumberOfComponents(2);
   newTCoords->Allocate(2*numPts);
   newTCoords->SetName("Texture Coordinates");
   ===========================================

   and the bug is hence fixed.

   Thanks for reporting the bug.

   new revision: 1.48; previous revision: 1.47

(0013930)
Alan Scott (manager)
2008-10-24 20:09

This still crashes as of the current ParaView trunk. You list lines changed, but not the name of the file. Thus, I cannot check to see if I have pulled this file.

(0013933)
Zhanping Liu (developer)
2008-10-24 22:13

As mentioned in my explanation on Oct 10, I made the fix in vtkLineSource::RequestData(), a function which is certainly in file vtkLineSource.cxx because the name of a VTK class (here "vtkLineSource") is the same as the name of the associated "cxx" file (here "vtkLineSource.cxx" under "ParaView3\VTK\Graphics\"). Please note that there is no change to vtkExodusIIWriter.cxx regarding this fix.

Now this issue can be closed. If you find further problems, please let me know.

(0013934)
Clinton Stimpson (developer)
2008-10-24 23:08

I had an issue with another data set. I wanted the Exodus reader fixed so it would check for null pointers and not crash. I simply used a vtkLineSource to reproduce the problem I was seeing.

(0013935)
Zhanping Liu (developer)
2008-10-25 01:42

Sorry, but I do not understand the problem you have right now. Since a name ("Texture Coordinates") has been assigned in vtkLineSource::RequestData(), no null pointers are now checked in tkExodusIIWriter::FlattenOutVariableNames(). If you still find further problems with vtkLineSource COUPLED WITH vtkExodusIIWriter, please let me know and also please upload your dataset or please tell me the exact procedures used to reproduce the problem. For problems not caused by vtkLineSource COUPLED WITH vtkExodusIIWriter, please create a new report.

Thanks.

(0014098)
Utkarsh Ayachit (administrator)
2008-11-13 09:22

Nathan has already (on Nov 07, 2008) committed a fix to the writer so that it produces an error message "Array in input has Null name, cannot proceed" and does not crash. I tested the same by locally reverting the changes to vtkLineSource.cxx and saving the file as exodus. I got the nice error message without any crashes.

(0014141)
Alan Scott (manager)
2008-11-19 18:12

It still crashes for me. I am attaching a screenshot from how it crashed.

Clint - can you replicate this fix?

alan

(0014142)
Alan Scott (manager)
2008-11-19 18:15

Sorry, should have been moved to feedback.

(0014146)
Clinton Stimpson (developer)
2008-11-19 18:55

That error message means that the exodus writer is not available.

Someone asked me today about the exodus code and found it had been disabled in VTK recently. Perhaps that's why you're having that problem. Paraview shouldn't crash in that case either, so that looks like another bug report :)

(0014148)
Zhanping Liu (developer)
2008-11-20 10:33

It seems fixing this bug has become complicated.

When I was fixing this bug in Oct, the version of vtkExodusIIWriter.cxx on my PC is 1.23 (2008/4/28 20:28:42. In other words, I forgot to update it with the then latest version 1.26. see "vtkExodusIIWriter.cxx" and "Log_vtkExodusIIWriter.txt" for version 1.23 and the log). Thus I made changes to ONLY vtkLineSource.cxx (see "Log_vtkLineSource.txt" from the atatchment for the log) and the bug was just fixed.

    In a word, this bug was fixed based on version 1.23 of vtkExodusIIWriter.cxx. As vtkExodusIIWriter.cxx has been modified so much since Sept 26, the bug might appear again.

    According to Clinton, the exodus writer is not available now. Fixing the bug is more complicated.

    I apologize for not updating vtkExodusIIWriter.cxx timely before fixing the bug.

    Thanks.

(0014149)
Utkarsh Ayachit (administrator)
2008-11-20 10:55

In conclusion:
* When Alan tried to reproduce this bug someone had (apparently) disabled the writer. Now it looks like the writer is back enabled and hence should work as expected.
* ParaView is not crashing, it's 'aborting' -- giving up since it does not know what to do if it cannot create the requested VTKObject. It's the developer error that one simply disabled the Exodus writer without disabling it's use in ParaView. This a temporary bug and now seems to be non-issue since the writer is enabled.
* Nathan has fixed the original issue in the writer to not crash but spit out an error when non-named arrays are encountered.

(0014297)
Alan Scott (manager)
2008-12-04 22:02

Tested client/server.

Issue History
Date Modified	Username	Field	Change
2008-03-07 15:33	Clinton Stimpson	New Issue
2008-04-10 17:13	Ken Moreland	Category	Development => 3.6
2008-09-23 11:23	Berk Geveci	Status	backlog => tabled
2008-09-23 11:23	Berk Geveci	Assigned To	=> Zhanping Liu
2008-10-10 16:32	Zhanping Liu	Note Added: 0013849
2008-10-10 16:32	Zhanping Liu	Status	tabled => @80@
2008-10-24 20:09	Alan Scott	Note Added: 0013930
2008-10-24 20:09	Alan Scott	Status	@80@ => @20@
2008-10-24 20:09	Alan Scott	Resolution	open => reopened
2008-10-24 22:13	Zhanping Liu	Note Added: 0013933
2008-10-24 22:14	Zhanping Liu	Status	@20@ => @80@
2008-10-24 23:08	Clinton Stimpson	Note Added: 0013934
2008-10-24 23:08	Clinton Stimpson	Status	@80@ => @20@
2008-10-25 01:42	Zhanping Liu	Note Added: 0013935
2008-10-25 01:43	Zhanping Liu	Status	@20@ => @80@
2008-11-13 09:22	Utkarsh Ayachit	Note Added: 0014098
2008-11-19 18:12	Alan Scott	Note Added: 0014141
2008-11-19 18:12	Alan Scott	Status	@80@ => @30@
2008-11-19 18:12	Alan Scott	File Added: junkScreen.JPG
2008-11-19 18:15	Alan Scott	Note Added: 0014142
2008-11-19 18:15	Alan Scott	Status	@30@ => @20@
2008-11-19 18:55	Clinton Stimpson	Note Added: 0014146
2008-11-20 10:08	Zhanping Liu	File Added: Log_vtkLineSource.txt
2008-11-20 10:09	Zhanping Liu	File Added: Log_vtkExodusIIWriter.txt
2008-11-20 10:09	Zhanping Liu	File Added: vtkExodusIIWriter.h
2008-11-20 10:09	Zhanping Liu	File Added: vtkExodusIIWriter.cxx
2008-11-20 10:13	Zhanping Liu	File Deleted: vtkExodusIIWriter.h
2008-11-20 10:33	Zhanping Liu	Note Added: 0014148
2008-11-20 10:34	Zhanping Liu	Status	@20@ => @80@
2008-11-20 10:55	Utkarsh Ayachit	Note Added: 0014149
2008-12-04 22:02	Alan Scott	Note Added: 0014297
2008-12-04 22:02	Alan Scott	Status	@80@ => closed
2008-12-04 22:02	Alan Scott	Resolution	reopened => fixed
2009-05-13 13:47	Utkarsh Ayachit	Target Version	=> 3.6
2011-06-16 13:10	Zack Galbreath	Category	=> (No Category)

Notes
(0013849) Zhanping Liu (developer) 2008-10-10 16:32	The bug has been fixed. It was due to not providing a name for ========================== vtkFloatArray newTCoords; ========================== in vtkLineSource::RequestData() --- line 85 ~ line 88 ===================================== newTCoords = vtkFloatArray::New(); newTCoords->SetNumberOfComponents(2); newTCoords->Allocate(2numPts); newLines = vtkCellArray::New(); ===================================== which is, though, then evaluated in tkExodusIIWriter::FlattenOutVariableNames() --- line 1027 --- through ====================================== if (strlen(nms[i]) > MAX_STR_LENGTH-2) ====================================== Now a name "Texture Coordinates" has been provided in the very segment ========================================== newTCoords = vtkFloatArray::New(); newTCoords->SetNumberOfComponents(2); newTCoords->Allocate(2*numPts); newTCoords->SetName("Texture Coordinates"); =========================================== and the bug is hence fixed. Thanks for reporting the bug. new revision: 1.48; previous revision: 1.47

(0013930) Alan Scott (manager) 2008-10-24 20:09	This still crashes as of the current ParaView trunk. You list lines changed, but not the name of the file. Thus, I cannot check to see if I have pulled this file.

(0013933) Zhanping Liu (developer) 2008-10-24 22:13	As mentioned in my explanation on Oct 10, I made the fix in vtkLineSource::RequestData(), a function which is certainly in file vtkLineSource.cxx because the name of a VTK class (here "vtkLineSource") is the same as the name of the associated "cxx" file (here "vtkLineSource.cxx" under "ParaView3\VTK\Graphics\"). Please note that there is no change to vtkExodusIIWriter.cxx regarding this fix. Now this issue can be closed. If you find further problems, please let me know.

(0013934) Clinton Stimpson (developer) 2008-10-24 23:08	I had an issue with another data set. I wanted the Exodus reader fixed so it would check for null pointers and not crash. I simply used a vtkLineSource to reproduce the problem I was seeing.

(0013935) Zhanping Liu (developer) 2008-10-25 01:42	Sorry, but I do not understand the problem you have right now. Since a name ("Texture Coordinates") has been assigned in vtkLineSource::RequestData(), no null pointers are now checked in tkExodusIIWriter::FlattenOutVariableNames(). If you still find further problems with vtkLineSource COUPLED WITH vtkExodusIIWriter, please let me know and also please upload your dataset or please tell me the exact procedures used to reproduce the problem. For problems not caused by vtkLineSource COUPLED WITH vtkExodusIIWriter, please create a new report. Thanks.

(0014098) Utkarsh Ayachit (administrator) 2008-11-13 09:22	Nathan has already (on Nov 07, 2008) committed a fix to the writer so that it produces an error message "Array in input has Null name, cannot proceed" and does not crash. I tested the same by locally reverting the changes to vtkLineSource.cxx and saving the file as exodus. I got the nice error message without any crashes.

(0014141) Alan Scott (manager) 2008-11-19 18:12	It still crashes for me. I am attaching a screenshot from how it crashed. Clint - can you replicate this fix? alan

(0014142) Alan Scott (manager) 2008-11-19 18:15	Sorry, should have been moved to feedback.

(0014146) Clinton Stimpson (developer) 2008-11-19 18:55	That error message means that the exodus writer is not available. Someone asked me today about the exodus code and found it had been disabled in VTK recently. Perhaps that's why you're having that problem. Paraview shouldn't crash in that case either, so that looks like another bug report :)

(0014148) Zhanping Liu (developer) 2008-11-20 10:33	It seems fixing this bug has become complicated. When I was fixing this bug in Oct, the version of vtkExodusIIWriter.cxx on my PC is 1.23 (2008/4/28 20:28:42. In other words, I forgot to update it with the then latest version 1.26. see "vtkExodusIIWriter.cxx" and "Log_vtkExodusIIWriter.txt" for version 1.23 and the log). Thus I made changes to ONLY vtkLineSource.cxx (see "Log_vtkLineSource.txt" from the atatchment for the log) and the bug was just fixed. In a word, this bug was fixed based on version 1.23 of vtkExodusIIWriter.cxx. As vtkExodusIIWriter.cxx has been modified so much since Sept 26, the bug might appear again. According to Clinton, the exodus writer is not available now. Fixing the bug is more complicated. I apologize for not updating vtkExodusIIWriter.cxx timely before fixing the bug. Thanks.

(0014149) Utkarsh Ayachit (administrator) 2008-11-20 10:55	In conclusion: * When Alan tried to reproduce this bug someone had (apparently) disabled the writer. Now it looks like the writer is back enabled and hence should work as expected. * ParaView is not crashing, it's 'aborting' -- giving up since it does not know what to do if it cannot create the requested VTKObject. It's the developer error that one simply disabled the Exodus writer without disabling it's use in ParaView. This a temporary bug and now seems to be non-issue since the writer is enabled. * Nathan has fixed the original issue in the writer to not crash but spit out an error when non-named arrays are encountered.

(0014297) Alan Scott (manager) 2008-12-04 22:02	Tested client/server.

Relationships