Heap problem with CVIXML library?

[jr_2005]

I have started a new project which requires an XML file (~ 2MB) to be processed, so the CVIXML library functions are proving to be very useful. The code is at an early stage, so I am compiling and running under debug all the time as I incrementally add more functionality and test it. The code compiles and runs without error, but yesterday I noticed that the Debug Output workspace window contained several identical lines: "HEAP[XMLRead_dbg.exe]: Invalid allocation size - 90900048 (exceeded 7ffdefff)"

Upon investigation, I have found that the line is added to the debug window at the same moment as the "Look in:" drop-down control on either a FileSelectPopup or a DirSelectPopup library panel is clicked. Just clicking the drop-down arrow generates the line - I don't have to actually select anything. Although no errors are produced and my code seems to run correctly, I can't help wondering what is going on and that there might be some fundamental problem that will bite me in the weeks ahead.

Does anyone recognise this symptom?

JR

[SachaE]

Hi,

  what version of cvi are you using?

I've tried this with a quick code snippet in LabWIndows/CVI 8.0 and I don't see anything in the Debug Output window. (you'll obviously need to include the cvixml.fp top the project.

Could you try the code below please and let me knwo what happens?

Thanks

Sacha Emery
National Instruments (UK)

#include "cvixml.h"
#include <userint.h>
#include <cvirte.h>

int main (int argc, char *argv[])
{
 CVIXMLElement newElement;
 CVIXMLElement rootElement;
 CVIXMLDocument xmlDoc;
 char File_path[MAX_PATHNAME_LEN];
 if (InitCVIRTE (0, argv, 0) == 0)
  return -1;    /* out of memory */
 
 CVIXMLNewDocument ("root", &xmlDoc);
 
 CVIXMLGetRootElement (xmlDoc, &rootElement);
 CVIXMLNewElement (rootElement, -1, "newTag", &newElement);
 CVIXMLSetElementValue (newElement, "3.141592");
 
 CVIXMLDiscardElement (newElement);
 CVIXMLDiscardElement (rootElement);
 
 CVIXMLSaveDocument (xmlDoc, 0, "c:\\new.xml");
 
 CVIXMLDiscardDocument (xmlDoc);
  
 FileSelectPopup ("C:\\", "*.*", "", "test for heap", VAL_LOAD_BUTTON,
      0, 0, 1, 0, File_path);
 
 DirSelectPopup ("c:\\", "Test for heap Directory", 1, 1, File_path);
  
 return 0;
}

[jr_2005]

Sacha,

I am using CVI 7.0.0 (393) running on XP Home and to my surprise (and relief) your code also generates exactly the same symptoms and words in the Debug Output window as mine! (OK, the filename is different...) I was a bit worried that it might have had something to do with the size of my xml file but clearly this is not the case now.

Is this phenomenon something that either of us should be worried about? The code seems to run OK, although it is nowhere near fully tested yet.

JR

[SachaE]

Hi,

  unfortunately I don't have a copy of XP home to try this against - only Pro with service pack 2.

Do you have any service packs installed? Another option would be to write your own popup for this :

http://digital.ni.com/public.nsf/websearch/85F2BDF6127EFF7086256E690067EBAF?OpenDocument

Without being able to reproduce it here, I'm not sure where the problem actually lies. XP Pro and Home differ primarily in their file sharing capabilities :

http://www.microsoft.com/windowsxp/pro/howtobuy/choosing2.mspx

so it could be down to the OS, or CVI 7, or the actual installation.
Do you have another computer you could try this on?

Without knowing why the messages are showing in the Debug Output window, I can't say if there will be a future problem to be worried about or not.

Thanks

Sacha Emery
National Instruments (UK)

[jr_2005]

Sacha,

You suggest writing my own Popup to avoid this situation, but this will not help if there is a fundamental problem in the CVIXML library. In your sample code, I can delete every CVIXML function call except the first, so there is only a single CVIXMLNewDocument () call remaining, and the problem still occurs. It seems that as soon as the library is invoked this sets the scene for a future error message. Corrupting the heap, maybe? (My code does not use this particular call - I open an existing document with CVIXMLLoadDocument ().)

I can try the software on an XP Pro development machine - I will try to do this but I am away for a couple of weeks after today .

JR

[jr_2005]

Tried it on our XP Pro development platform and got the same results again. Going on holiday now so looking forward to a solution being posted on the board for when I get back. 

JR

[SachaE]

Hi,

  this is very strange. I've tried it on a fresh install of LabWindows/CVI 7.0 on xp pro sp 2 and I don't see anything in the Debug Output window.

What are your environment and build options set to currently?

Thanks

Sacha Emery
National Instruments (UK)

[SachaE]

Hi,

  I just received a message from someone in R&D here, and he's asked me to look into the version of the MicrosoftXML component which the CVI-XMLdriver uses underneath since this is the likely culprit.

My version of   c:\windows\system32\msxml3.dll. In my PC, I have version 8.50.2162.0 (service pack 5). It's possible that you might have a different version.

It's really hard to do a true comparison unless both of us are testing this on a clean, XP pro machine, because a lot of applications re-install this component.

Thanks

(and thanks R&D guy)

Sacha Emery
National Instruments (UK)

[jr_2005]

On the development machine, we are currently using the original (I think) version of the file that came with XP - the msxml3.dll file is dated 18 August 2001 and indicates a version of 8.20.8730.1. If this is the culprit, maybe there is no real problem, as the target machines that will eventually receive and run the final executable will most probably have the SP2 version of XP.

Seems odd, though, that a MS library file can cause messages to appear in a NI debug window. Are we all comfortable leaving this as it is?

JR

[SachaE]

I think the best bet is to try the latest version of the msxml3 by installing the service pack, or installing LabWindows/CVI temporarily on a PC with the later service pack on, and then you can be sure.

The fact that something shows up in the debug window could easily be a catch point whereby we've wrapped over the functionality in that dll to get the xml functions integrated, so it's not that odd really.

Thanks

Sacha.