[C++] std::string doet weer eens lastig *

[Verwijderd]

Let niet op de briljante titel . Het is weer eens zover, de STL string is weer eens lastig aan het doen. Ik heb reeds getracht in een losstaande applicatie de ellende te reproduceren. Tot op heden is dit nog niet gelukt. Het gaat om de volgende code:

C++:

void ClassA::methodA(string input)
{
  // Binnen deze functie is de waarde van input niet in orde. Of ik hem nu afdruk of in de debugger
  // bekijk. Het maakt allemaal helemaal niets uit :)
}

ClassA classInstance;

// De eerste aanroep naar methodA werkt zonder problemen. Hierbij komt de waarde "test" braaf
// in de input string terecht.
classInstance.methodA("test");

// De tweede maal dat dezelfde methode op dezelfde manier wordt aangeroepen gaat het fout.
// Dan staat er enkel rommel in de input string. De rommel is iedere keer hetzelfde.
// De aanroepen staan niet op dezelfde plek in de applicatie. Ze volgende elkaar echter vrij
// snel op.
classInstance.methodA("test2");

Momenteel, na een aantal dagen, heb ik werkelijk geen idee meer hoe dit veroorzaakt kan worden of hoe ik bij de oorzaak kan komen. Graag enige tips van mede-gotters .

[ Voor 0% gewijzigd door RobIII op 08-03-2007 11:08 ]

[Janoz]

STL is al redelijk uitontwikkeld. Hierom, en vanwege mijn ervaring met 'rare' problemen durf ik wel te stellen dat het hier gaat om 'flapster doet weer eens raar' ipv 'String doet weer eens raar' .

Maw, wat doe je precies in je methodA en hoe wordt deze verder aangeroepen? Gebeurt die in dezelfde thread? Gebruik je altijd constante waarden om mee te geven aan je methoden of is het in het echte programma gewoon een variabale?

[Verwijderd]

Janoz schreef op donderdag 08 maart 2007 @ 11:08:
STL is al redelijk uitontwikkeld. Hierom, en vanwege mijn ervaring met 'rare' problemen durf ik wel te stellen dat het hier gaat om 'flapster doet weer eens raar' ipv 'String doet weer eens raar' .

Ik geloof je direct, maar met die wetenschap heb ik mijn probleem nog niet opgelost .

Janoz schreef op donderdag 08 maart 2007 @ 11:08:Maw, wat doe je precies in je methodA en hoe wordt deze verder aangeroepen? Gebeurt die in dezelfde thread? Gebruik je altijd constante waarden om mee te geven aan je methoden of is het in het echte programma gewoon een variabale?

Het is verder niet zo interessant wat er in methodA gebeurt, de input string is direct vernaggeld bij het binnenkomen van de methode. De string bevat al verkeerde waardes voordat de functie ook maar iets gedaan heeft.

De betrokken methodes lopen allemaal binnen dezelfde thread.

Het probleem treedt op wanneer ik constante waardes gebruik. Met het vreemde detail dat het de eerste keer wel goed gaat en de tweede keer niet.

Momenteel heb ik geen idee meer hoe ik terug zou moeten traceren to the cause .

Update:
Ik heb zonet eens geprobeerd om de eerste aanroep naar methodA er eens tussen weg te trekken. Ik had verwacht dat de tweede aanroep nu succesvol zou verlopen. Dit is echter nog steeds niet het geval, dus moet er iets fout gaan bij de tweede aanroep. Al wordt die aanroep hetzelfde gedaan als de eerste maal.

Conclusie: het wordt alleen maar vager

[ Voor 13% gewijzigd door Verwijderd op 08-03-2007 11:29 ]

[Icelus]

Welke compiler en STL versie gebruik je?

[ Voor 38% gewijzigd door Icelus op 08-03-2007 11:56 ]

[Verwijderd]

Visual Studio 2005 in combinatie met de bijgeleverde STL zut

[.oisyn]

Kun je je probleem meer isoleren in een klein compileerbaar programmaatje? Want aan deze context hebben we weinig, het zou zo goed moeten gaan, maar blijkbaar is dat niet zo, dus er is iets anders wat je verkeerd doet .

Wild guess: heap corruption. Overigens is het efficienter om objecten met dure constructors zoals std::string (en std::vector etc.) te passen als const reference ipv als value. Worden er ook geen onnodige kopieën gemaakt. Let wel: dit lost waarschijnlijk het symptoom van je probleem op, maar niet je probleem, dus deze aanpassing kun je beter niet maken totdat je probleem is opgelost

[ Voor 41% gewijzigd door .oisyn op 08-03-2007 13:15 ]

[Verwijderd]

.oisyn schreef op donderdag 08 maart 2007 @ 13:12:
Kun je je probleem meer isoleren in een klein compileerbaar programmaatje? Want aan deze context hebben we weinig, het zou zo goed moeten gaan, maar blijkbaar is dat niet zo, dus er is iets anders wat je verkeerd doet .

Ik kan het probleem nog niet reproduceren in een kleine testopzet.

.oisyn schreef op donderdag 08 maart 2007 @ 13:12:Wild guess: heap corruption. Overigens is het efficienter om objecten met dure constructors zoals std::string (en std::vector etc.) te passen als const reference ipv als value. Worden er ook geen onnodige kopieën gemaakt. Let wel: dit lost waarschijnlijk het symptoom van je probleem op, maar niet je probleem, dus deze aanpassing kun je beter niet maken totdat je probleem is opgelost

Dan denken wij hetzelfde, echter kan ik geen heap corruption meer lokaliseren . Ik heb de meest exotische tooltjes er al over laten lopen (o.a. Purify en Memory validator). Verder controleer ik momenteel om de 5-10 regels code met _CrtCheckMemory met de volgende macro.

C++:

#define CHECK_HEAP _ASSERTE(_CrtCheckMemory());

Dit levert verder geen vreemde resultaten op. Ik heb verder geen enkel idee meer hoe ik een eventuele heap corruption zou moeten kunnen vinden. Suggesties zijn natuurlijk altijd welkom

[OxiMoron]

Zou er iig een

void ClassA::methodA(string &input)

van maken.

Beetje onzin om de string te kopieeren..

[Verwijderd]

Gisteren zag het er idd ook nog als volgt uit:

C++:

void Class::methodA(string &input)
{
}

instance->methodA(string("test"));

Dit leverde echter dezelfde problemen op.

[.oisyn]

OxiMoron schreef op donderdag 08 maart 2007 @ 13:58:
Zou er iig een

void ClassA::methodA(string &input)

van maken.

Beetje onzin om de string te kopieeren..

Ik zou er een const string & van maken, beetje onzin om te eisen dat de gepasste string niet const mag zijn als je 'm toch niet aan gaat passen (met als bijkomend nadeel dat je geen string literals meer kunt opgeven - temporaries kunnen alleen aan const references binden)

[farlane]

Verwijderd schreef op donderdag 08 maart 2007 @ 13:26:
Ik heb verder geen enkel idee meer hoe ik een eventuele heap corruption zou moeten kunnen vinden. Suggesties zijn natuurlijk altijd welkom

Kijk eens in je map file waar de string staat die je meegeeft en kijk welke variabelen er in de buurt staan ( Arrays bijvoorbeeld zijn een behoorlijk gevoelig voor dit soort dingen )
Is je programma multithreaded?

[.oisyn]

Da's ook nog een optie natuurlijk. Output is gewoon die string literal. Dit dus:

C++:

//classInstance.methodA("test");  // deze regel even vervangen met:
std::cout << "test" << std::endl;

Als dat óók garbage is zit je idd ergens het geheugen van die string te overschrijven, en dan kun je zoals farlane suggereert in je map file opzoeken wat daarvoor zit.

[ Voor 30% gewijzigd door .oisyn op 09-03-2007 11:03 ]