3. Speicherprobleme mit Xerces

Speicherprobleme mit Xerces

  • D

    Hallo,
    ich habe ein Problem mit XercesC_2.2.0.

    ...
DOMNodeList *vChildren = p_pNode->getChildNodes();
DOMNode *vElem = vChildren->item(0);

char *dat = new char[255];

if(vElem)
{
	if(XMLString::transcode(vElem->getNodeValue(), dat, 256))
	{
		val = dat;
	}
}
...

    Wenn versucht wird, mittels

    char *dat = new char[255];

    Speicher zu allokieren, bricht das Programm einfach weg.
    Das Seltsame ist, dass das nicht passiert, wenn ich Schritt für Schritt durch das Programm durch-debugge.
    Ich benutze Visual Studio 2003 7.1.3088.
    Weiss da jemand vielleicht Rat?

    0
  • ?

    Wenn ich mich rechtentsinne hat Xerces seinen eigenen Speichermanager. Kann sein, dass an dieser Stelle sich der std und der xerces-Speichermanager nicht vertragen.

    0
  • N

    Gegenfrage:
    Wieso setzt Du für den maxChars Parameter 256 ein?

    //edit:

    http://xml.apache.org/xerces-c/apiDocs/classXMLString.html#z520_13 schrieb:

    Parameters:

    toTranscode
    The string tobe transcoded

    toFill
    The buffer that is filled with the transcoded value. The size of this buffer should atleast be 'maxChars + 1'.

    maxChars
    The maximum number of bytes that the output buffer can hold (not including the null, which is why toFill should be at least maxChars+1.).

    manager
    The MemoryManager to use to allocate objects

    Dass heisst, Du solltest den Buffer 256 Zeichen groß machen und für maxChars 255 eingeben und wenns geht ein statisches Array verwenden:

    char buf[256];
    0
  • D

    @nillable
    Ja, da hast Du recht. Da handelt es sich um ein Versehen meinerseits. Danke.
    Aber, ebenso Gegenfrage, was hilft mir das bei meinem Problem mit new?
    Zur Erinnerung: das Programm bricht bei der Allokation weg, nicht beim Aufruf der Xerces-Methode. Die Allokation einfach weglassen ist sinnlos. Klar kann ich jetzt hier auf ein statisches Array setzen. Aber hier drumrumbauen bedeutet ja doch nur später wieder auf dasselbe Problem zu stossen!

    @Mathias
    Könnte sein, dass das Problem damit zusammenhängt. Ich werde dort mal ansetzen zu suchen.

    Wer darüberhinaus eine Lösung weiss, sei so frei diese zu posten. Danke.

    0
  • N

    Drakos schrieb:

    Das Seltsame ist, dass das nicht passiert, wenn ich Schritt für Schritt durch das Programm durch-debugge.

    Drakos schrieb:

    Zur Erinnerung: das Programm bricht bei der Allokation weg, nicht beim Aufruf der Xerces-Methode.

    Bist Du Dir wirklich sicher, dass es beim Allokieren passiert? Hast Du z. Bsp. mit Konsolen- bzw. Dateiausgabe versucht, etwas nach dem Allokieren auszugeben? Mit dem Debugger scheint man die Problemstelle ja, Deiner Aussage zufolge nicht finden zu können. Wenn Du wirklich unbedingt den Speicher dynamisch anfordern musst, müsste es genau auf die Art gehen, wie Du es geschrieben hast:

    #include <iostream>
using namespace std;

int main()
{
	char *buf = new char[256];

	for(int i=0;i<255;++i)
		buf[i] = 'x';
	buf[255]=0;

	cout << buf << endl;
	delete []buf;//freigeben nicht vergessen

	cin.get();
}
    0
  • A

    Wenn das Problem wirklich an dem mit new allokierten Array liegt, frage ich mich, warum die xerces-Entwickler kein std::string oder std::vector<char> benutzt haben? 😕 Das ist die Strafe kein C++ Std-Lib zu benutzen. 😉

    0
  • D

    nillable schrieb:

    Bist Du Dir wirklich sicher, dass es beim Allokieren passiert? Hast Du z. Bsp. mit Konsolen- bzw. Dateiausgabe versucht, etwas nach dem Allokieren auszugeben? Mit dem Debugger scheint man die Problemstelle ja, Deiner Aussage zufolge nicht finden zu können. Wenn Du wirklich unbedingt den Speicher dynamisch anfordern musst, müsste es genau auf die Art gehen, wie Du es geschrieben hast:

    Ja, da bin ich mir sicher, da ich direkt davor und danach eine Konsolenausgabe gemacht habe:

    std::cerr << "vorher" << std::endl;
char *dat = new char[255];
std::cerr << "nachher" << std::endl;

    'vorher' kam noch, 'nachher' nicht mehr.
    Das war das, was ich gemacht habe um die Problemstelle zu lokalisieren. Anders hätte das ja nicht viel Sinn gehabt.
    Ich war eben auch der Meinung, dass es so funktionieren sollte. Tut es aber in dem Fall leider nicht.

    0
  • N

    Drakos schrieb:

    Ja, da bin ich mir sicher, da ich direkt davor und danach eine Konsolenausgabe gemacht habe

    Das ist wohl eine Ausnahme. Probier das mal so:

    #include <stdexcept>
...
char *dat=0;
...
try
{
	dat = new char[256];
}
catch(const std::exception &ex)
{
	std::cerr << ex.what() << std::endl;
}
...
if(dat!=0)
	delete []dat;
    0
Anmelden zum Antworten