[C++/STL] Vaag gedrag samenvoegen STL strings

[Verwijderd]

Ik zit momenteel met een vaag probleem met betrekking tot STL strings. Bij het samenvoegen van een tweetal strings krijg ik een derde string met daarin een bult rotzooi (no pun intended )

Het gaat hierbij om een omgeving met meerdere threads. Het idiote is dat er door de gehele applicatie strings worden gebruikt en dat dit probleem zich spontaan manifesteerd.

Het is net alsof de waardes van de ascii karakters worden opgeteld i.p.v. dat de strings worden samengevoegd.

Hierbij de regel welke het probleem veroorzaakt. Alle drie de variabelen zijn van het type STL string.

code:

string fieldName = queryData->m_tableNamePrefix + queryData->m_tableName;

De waardes in m_tableNamePrefix en m_tableName bevatten geldige waarden. Echter worden de strings zoals gezegd niet samengevoegd, maar gewoon als rotzooi in fieldName gestopt. Logischerwijs verzorgt dit verderop in de code voor allerlei akelige situaties .

Laat de ideeën maar komen

[moto-moi]

Weet je zeker dat je c++ libs threadsafe zijn? (aangezien je er geen os of compiler bij verteld)

[ Voor 33% gewijzigd door moto-moi op 22-12-2006 12:10 ]

[Verwijderd]

Het gaat hier om de multithreaded libraries behorende bij ms visual studio 2005. Voor zover ik weet behoren deze threadsafe te zijn. Mocht ik het hierbij fout hebben, dan hoor ik het graag van je

[farlane]

Een bug ergens anders in je prog die je strings overschrijft?

[Verwijderd]

Hoe kan ik ergens anders in mijn programma een string overschrijven in de regel code die ik eerder heb gepost? . Voordat ik de regel code uitvoer zijn mijn strings leeg en nadat de desbetreffende regel is uitgevoerd bevat de uitvoer complete rotzooi.

Het gaat ergens fout bij de coderegel die ik heb geplaatst. Ik heb stap voor stap het gehele programma getraced tot op het punt dat het fout gaat. Dus het lijkt me erg onwaarschijnlijk dat ik ergens een string overschrijf.

[.oisyn]

Misschien ten overvloede, maar hoe ben je tot de conclusie gekomen dat er rotzooi in staat? En dat de source strings wel klopten?

[ Voor 17% gewijzigd door .oisyn op 22-12-2006 14:00 ]

[Verwijderd]

.oisyn schreef op vrijdag 22 december 2006 @ 14:00:
Misschien ten overvloede, maar hoe ben je tot de conclusie gekomen dat er rotzooi in staat? En dat de source strings wel klopten?

Door een breakpoint te plaatsen en vervolgens stap voor de stap de code doorstappen met f10/f11. Het gaat te allen tijde goed, totdat ik bij de eerder genoemde regel aankom.

[.oisyn]

Mwoa, de debugger hoeft het niet per se bij het goede eind te hebben. Ik zou de waarden even outputten dmv code.

[Verwijderd]

En voor de zekerheid zonet met OutputDebugString gevalideerd. Nog steeds komt er met de goede input, verkeerde output uit .

Iemand nog ideeën, ik heb er geen meer namelijk

[.oisyn]

Ik gooi het op heap corruption. Wellicht gebruik je ergens een ongeinitialiseerde pointer, free je een stuk mem meerdere keren, of schrijf je simpelweg buiten je buffers. Gaat het wel goed als je alle threads pauzeert voor de assignment?

[Verwijderd]

Heap corruption was idd wel in mijn hoofd opgekomen, echter vind ik het dan zo vreemd dat het probleem spontaan opduikt zonder dat er grote wijzigingen zijn gemaakt.

We hebben een tijdje geleden echter wel problemen gehad met het string type als parameter. Dit leverde i.d.d. heap corruption problemen op.

Momenteel zit ik te spelen met de gedachte om het string type in zijn geheel te dumpen en te vervangen met een custom class of de goede ouderwetse char* . Ik ben nog nooit echt een fan geweest van STL strings en dit draagt geen positieve ervaringen bij .

[.oisyn]

Verwijderd schreef op vrijdag 22 december 2006 @ 14:44:
Heap corruption was idd wel in mijn hoofd opgekomen, echter vind ik het dan zo vreemd dat het probleem spontaan opduikt zonder dat er grote wijzigingen zijn gemaakt.

Da's het mooie van heap corruption, het kan gewoon goed gaan tot een kleine aanpassing catastrophale gevolgen heeft

Momenteel zit ik te spelen met de gedachte om het string type in zijn geheel te dumpen en te vervangen met een custom class of de goede ouderwetse char* . Ik ben nog nooit echt een fan geweest van STL strings en dit draagt geen positieve ervaringen bij .

Geloof me, je probleem zit niet in de std::string class. Ik gok zelfs dat als je die ene regel vervangt door een allocatie van een char buffer en een strcat dat het resultaat exact hetzelfde is (want veel meer doet die string intern ook niet)

[ Voor 11% gewijzigd door .oisyn op 22-12-2006 14:54 ]

[farlane]

Verwijderd schreef op vrijdag 22 december 2006 @ 13:57:
Hoe kan ik ergens anders in mijn programma een string overschrijven in de regel code die ik eerder heb gepost? .

Ik gooi het op heap corruption

Op die manier dus

[Verwijderd]

.oisyn schreef op vrijdag 22 december 2006 @ 14:52:
Da's het mooie van heap corruption, het kan gewoon goed gaan tot een kleine aanpassing catastrophale gevolgen heeft

Het is maar wat je mooi vind .

.oisyn schreef op vrijdag 22 december 2006 @ 14:52:
Geloof me, je probleem zit niet in de std::string class. Ik gok zelfs dat als je die ene regel vervangt door een allocatie van een char buffer en een strcat dat het resultaat exact hetzelfde is (want veel meer doet die string intern ook niet)

Ik zal zo eens kijken of PurifyPlus me iets kan vertellen. Ik zal ook eens even kijken of het anders wordt wanneer ik gebruik maak van een char*. Tenslotte kan ik tijdelijk nog een aantal externe libraries tijdelijk uitschakelen (De oracle occi api is ook een lelijk beest )

[.oisyn]

Werk je trouwens met cross-dll allocated mem? Dat is ook een recipe for disaster .

[Verwijderd]

We maken geen gebruik van cross-dll allocated mem.

[farlane]

Verwijderd schreef op vrijdag 22 december 2006 @ 14:44:
We hebben een tijdje geleden echter wel problemen gehad met het string type als parameter. Dit leverde i.d.d. heap corruption problemen op.

Momenteel zit ik te spelen met de gedachte om het string type in zijn geheel te dumpen en te vervangen met een custom class of de goede ouderwetse char* . Ik ben nog nooit echt een fan geweest van STL strings en dit draagt geen positieve ervaringen bij .

Je kunt ervan uit gaan dat als dat soort dingen gebeuren je het echt wel in je eigen stuff moet zoeken, en niet in de string class zelf
Het zelf schrijven van een string class zal meer bugs opleveren dan oplossen, neem dat maar van me aan.

[MSalters]

De string class beschermt z'n interne buffers behoorlijk goed. VS6 had nog een boundary case waar het multithreaded mis kon, maar die is niet meer relevant. Alleen: de std::string is alleen beschermd als je twee strings in twee threads wijzigt. Nog steeds geldt dat als je een std::string gebruikt in twee threads, dan ben je zelf verantwoordelijk voor de lock. Dat is niet voor std:string anders dan double, alleen is de kans op ongelukken iets hoger.

[Olaf van der Spek]

Verwijderd schreef op vrijdag 22 december 2006 @ 12:03:

code:

string fieldName = queryData->m_tableNamePrefix + queryData->m_tableName;

De waardes in m_tableNamePrefix en m_tableName bevatten geldige waarden. Echter worden de strings zoals gezegd niet samengevoegd, maar gewoon als rotzooi in fieldName gestopt. Logischerwijs verzorgt dit verderop in de code voor allerlei akelige situaties .

Laat de ideeën maar komen

Heb je de source code niet geinstalleerd?
Anders kun je toch gewoon door de code stappen en zelf zien wat er precies gebeurd?

[farlane]

Olaf van der Spek schreef op zaterdag 23 december 2006 @ 19:09:
[...]

Heb je de source code niet geinstalleerd?
Anders kun je toch gewoon door de code stappen en zelf zien wat er precies gebeurd?

Het probleem met dit soort dingen is dat je door het door de code stappen de timing verandert en dus de bug wel of niet zal opduiken. Beetje vervelend.

Maargoed, ik acht de kans waarschijnlijker dat de string al kapot is, en door het plakken pas de resultaten ervan zichtbaar worden.

[Verwijderd]

MSalters schreef op vrijdag 22 december 2006 @ 21:53:
De string class beschermt z'n interne buffers behoorlijk goed. VS6 had nog een boundary case waar het multithreaded mis kon, maar die is niet meer relevant. Alleen: de std::string is alleen beschermd als je twee strings in twee threads wijzigt. Nog steeds geldt dat als je een std::string gebruikt in twee threads, dan ben je zelf verantwoordelijk voor de lock. Dat is niet voor std:string anders dan double, alleen is de kans op ongelukken iets hoger.

In ons geval wordt de string slechts in één enkele thread gebruikt. Ook reeds geprobeerd alle threads te stoppen. Het probleem is ook prima te repliceren in één enkele thread.

farlane schreef op zondag 24 december 2006 @ 18:38:
[...]


Het probleem met dit soort dingen is dat je door het door de code stappen de timing verandert en dus de bug wel of niet zal opduiken. Beetje vervelend.

Maargoed, ik acht de kans waarschijnlijker dat de string al kapot is, en door het plakken pas de resultaten ervan zichtbaar worden.

Lijkt mij ook waarschijnlijk. Wanneer ik weer aan het werk ben zal ik eens gaan sporen naar heap corruption . Momenteel lijkt me dat het waarschijnlijkste.

[ Voor 27% gewijzigd door Verwijderd op 26-12-2006 09:59 ]