Fehler bei vector::resize, Bug im VS?

Pellaeon

HIho Leutz, folgendes

Ich habe einen Vektor(leer),
den übergebe ich per Referenz an eine Klasse aus einer Lib.
In der Lib wird für den Vektor resize aufgerufen. Im Release-Modus knallts dann(im debug gehts)
Es ist irgendein Zugriffsfehler mit entsprechender Adressangabe.
So sieht der Aufruf aus.

std::vector<double> data;
	if (!m_device->getCurrentData(data,constValues::timeOut))
        {
            ...

Wenn ich allerdings vor dem Aufruf schon ein resize mache, dann geht es. Selbst wenn es ein resize(0) ist.

std::vector<double> data;
	data.resize(0);
	if (!m_device->getCurrentData(data,constValues::timeOut))

Ich wüsste nicht, dass ich hier was falsch gemacht habe. Ist das ein Bug im VS?

Die statische Lib wie auch die Anwendung sind im Release mit MT kompiliert. Wenn ich beides auf MD umstelle, passiert aber dasselbe. Die Lib nutzt nur Windows-Header, die Anwendung die MFC statisch gelinkt. Beide werden optimiert im Release-Modus.
Service Pack fürs VS 2005 habe ich installiert.

Artchi

Versuch doch mal die Exception abzufangen (ich vermute mal, es wird eine geworfen... kannst du aber meistens auch an dem Fehlerdialog sehen) und dir den what-Text auszugeben.

try
{
   data.resize(10);
}
catch(const std::exception &e)
{
   std::cerr << e.what() << std::endl; // oder wohin auch immer du etwas sehen kannst...
}

Könnte gut sein, das der Allokator nämlich ne Exception wirft.

Pellaeon

ok also das ist die Fehlermeldung momentab:

Unbehandelte Ausnahme bei 0x00405803 in RobCal.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0x0000000a.

Ein try-catch drum bringt nix.
Laut Debugger(aber vorsicht, wie gesgat release-Modus) fliegt das in der insert-Methde, welche vom resize aufgerufen wird.
Der vector enthält nur doubles, also nix besonders.

Kann es auch sein, dass sich irgendwelche Compile-Einstellungen nicht vertragen?
Ich bin grad am durchgehen und schauen, wo es Unterschiede gibt
In einem extra Testprojekt, wo ich das nur mit dem Vektor und nichts anderem mal nachgebaut habe, gehts nämlich, also das resize in der lib.

MFK

Pellaeon schrieb:

0xC0000005: Zugriffsverletzung beim Lesen an Position 0x0000000a.

Es scheint, du hantierst da irgendwo mit einem Nullzeiger. Möglicherweise m_device.

Pellaeon

MFK schrieb:

Pellaeon schrieb:

0xC0000005: Zugriffsverletzung beim Lesen an Position 0x0000000a.

Es scheint, du hantierst da irgendwo mit einem Nullzeiger. Möglicherweise m_device.

Das device ist eine normale Membervariable einer Klasse, also es wurde nicht mit new erstellt oder so.
Und wie gesagt, mache ich außerhalb vorher das resize(0) dann gehts ja auf einmal.
Für mich sieht es aus, als würde im Vector was nicht stimmen.

Pellaeon

Also irgendwie hatte das VS 2005 schluckauf.
Ich hab noch ein bisschen rumgetestet, mal die Optimierung ausgeschalten, dann wieder hinzugenommen und jetzt auf einmal gehts (anscheinend), einfach so. Sind dieselben EInstellungen, wie wo der Fehler aufgetreten ist.

Sehr seltsam, naja mal schauen wie lange es hält ... .

Artchi

Kann tatsächlich sein, das deine statische Lib noch "ungültig" war. "Projekt bereinigen" kann da schon mal helfen. Durch deine "optimierungs"-Änderung hat sich das aber folglich selbst nochmal bereinigt.

Pellaeon

So ok, jetzt tritt der Fehler wieder auf oO
Ich habe dann nochmal beide Projekte bereinigt und neu erstellt. Trotzdem kommt wieder dieser Fehler.
Was kann es denn noch sein?
SO langsam nervt mich das oO

Martin Richter

Linkst Du die CRT statisch oder dynamisch?

Bist Du gaz sicher, dass die Projekt Einstellungen für LIB und EXE identisch sind?

Pellaeon

Martin Richter schrieb:

Linkst Du die CRT statisch oder dynamisch?

Bist Du gaz sicher, dass die Projekt Einstellungen für LIB und EXE identisch sind?

Ich linke sie statisch, hatte gestern auch mal MD probiert, da kam auch der Fehler. Ich kontrollier die Einstellungen nochmal, aber sie waren identisch soweit ich gesehen habe.
Und im Debug-Modus gehts ja, und mit einem resiz(0) außerhalb auch.

Die lib nimmt keine vorkommpiliereten HEader und keine MFC, aber das dürfte ja nichts ausmachen.

Martin Richter

Bist Du ganz sicher, dass beide die selbe CRT verwenden?
Bist Du ganz sicher, dass beide die gleiche STL verwenden?

Pellaeon

Martin Richter schrieb:

Bist Du ganz sicher, dass beide die selbe CRT verwenden?
Bist Du ganz sicher, dass beide die gleiche STL verwenden?

Wie kann ich das testen, bzw. wo muss ich da nachschauen?
Unter Compiler->Codegererierung stehen beide auf /MT

Pellaeon

Das wird immer wirrer:

//
void CRobCalDlg::OnBnClickedButtonTest()
{
	CString tmp;
	std::vector<double> data;
	CNiUsb6008 dev;
	data.resize(0);
	dev.getCurrentData(data,5,1);
	tmp.Format(_T("%d"),data.size());

	std::vector<double> data2;
	dev.getCurrentData(data2,5,1);
	tmp.Format(_T("%d"),data2.size());

Ein resize-Aufruf scheint zu reichen ?!?!
Wenn ich da einen zweiten Vektor anlege, und bei dem ersten das resize kam, dann funktioniert auch der Auruf mit dem 2. Vektor. Scheint wohl wirklich ein VS Bug zu sein, oder?
Komisch ist auch, wenn ich außen reserve anstatt resize mache, dann fliegt der Fehler wieder. Was auch immer es ist, liegt dann also nicht am Allokieren.
Und das resize(0) tut auch im release-Modous keinen Speicher anlegen(habe mir capacity nmal ausgeben lassen, die bleibt auf 0!)

Pellaeon

So wieder was rausgefunden: das resize im Hauptprogramm muss nicht vor dem getCurrentData kommen. Es muss einfach irgendwo stehen, Ich hatte jetzt einen Vektor, der nach dem getCurrentData angelegt wurde und das resize nutzt. Dann fliegt auch kein Fehler.
Nehm ich das resize raus -> Fehler

Template-Methoden werden ja nur angelegt, wenn sie auch benutzt werden.
Kann es evtl. sein, dass in der statischen Lib nur ein Aufruf der resize Methode ist und diese im Hauptprogramm erwartet. Wenn das Hauptprogramm nun kein resize macht, wird es nicht anlegt und dann kracht es in der lib?
Andererseits habe ich ein extra Testprojekt gemacht wo ein Vektor "resized" wird, da ging alles.

Hat niemand mehr Ideen, was das verursachen könnte?

Pellaeon

Auslöser gefunden:

#define _SECURE_SCL 0

Das war definiert um so ein paar unchecked-Warnungen nicht anzeigen zu lassen.
Warum kommt es denn zu so einem komischen Verhalten, wenn man checked Iterators deaktiviert?