VC STL - STL String bug?

Author

STL String bug?

George

2006-03-13, 7:58 am

Visual Studio 6 Service Pack 5.

All,
Below is some Dr.Watson output from our server application which seems
to randomly crash indicating some sort of STL string problem. I am aware of
the dinkumware fixes but have been reluctant to apply these until certain
that the lack of a fix is the cause. STL strings are passed across DLL
boundaries but I am sure the CRT linkage is consistent throughout and
typically the strings are only read or copied. I suppose I'm after a strong
steer that the observations are due to a lack of applying the fixes.

cheers
G

function: set_sbh_threshold
7800cf8c 6a20 push 0x20
7800cf8e 234df8 and ecx,[ebp-0x8]
ss:0204db5a=00140204
7800cf91 5f pop edi
7800cf92 85c9 test ecx,ecx
7800cf94 7c05 jl set_sbh_threshold+0x5fe (7800cf9b)
7800cf96 d1e1 shl ecx,1
7800cf98 47 inc edi
7800cf99 ebf7 jmp set_sbh_threshold+0x5f5 (7800cf92)
7800cf9b 8b4df4 mov ecx,[ebp-0xc]
ss:0204db5a=00140204
7800cf9e 8b54f904 mov edx,[ecx+edi*8+0x4]
ds:0103ea0b=????????
FAULT ->7800cfa2 8b0a mov ecx,[edx]
ds:00000004=????????
7800cfa4 2b4df0 sub ecx,[ebp-0x10]
ss:0204db5a=00140204
7800cfa7 8bf1 mov esi,ecx
7800cfa9 894df8 mov [ebp-0x8],ecx
ss:0204db5a=00140204
7800cfac c1fe04 sar esi,0x4
7800cfaf 4e dec esi
7800cfb0 83fe3f cmp esi,0x3f
7800cfb3 7e03 jle set_sbh_threshold+0x61b (7800cfb8)
7800cfb5 6a3f push 0x3f
7800cfb7 5e pop esi
7800cfb8 3bf7 cmp esi,edi
7800cfba 0f84b5000000 je set_sbh_threshold+0x6d8 (7800d075)

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0100f154 7800c730 00bfb210 0100f440 0100f5b4 780c9dbb !set_sbh_threshold
0100f188 780012d7 0000001a 7800320e 0000001a 00000001 !exception::what
0100f5c0 780c2615 0000000b 0000000b 0100f604 780c2593 !malloc
0100ff54 0040fa76 00000001 00000024 00000000 00c00450
!std::basic_string<unsigned short,std::char_traits<unsigned
short>,std::allocator<unsigned short> >::_Grow
0100ffb8 77f04ee8 00c00450 00000024 00000000 00c00450 !<nosymbols>
0100ffec 00000000 00000000 00000000 00000000 00000000 kernel32!lstrcmpiW
00000000 00000000 00000000 00000000 00000000 00000000 !<nosymbols>

AND

function: set_sbh_threshold
7800d060 093b or [ebx],edi
ds:021cd9e8=f9000000
7800d062 bf00000080 mov edi,0x80000000
7800d067 8bce mov ecx,esi
7800d069 d3ef shr edi,cl
7800d06b 8b4dfc mov ecx,[ebp-0x4]
ss:04269e6e=00000000
7800d06e 097c8844 or [eax+ecx*4+0x44],edi
ds:14e97ffb=????????
7800d072 8b4df8 mov ecx,[ebp-0x8]
ss:04269e6e=00000000
7800d075 85c9 test ecx,ecx
7800d077 7406 jz set_sbh_threshold+0x6e2 (7800d07f)
7800d079 890a mov [edx],ecx
ds:13e597a8=13e595f4
FAULT ->7800d07b 894c11fc mov [ecx+edx-0x4],ecx
ds:14e981af=????????
7800d07f 8b75f0 mov esi,[ebp-0x10]
ss:04269e6e=00000000
7800d082 03d1 add edx,ecx
7800d084 8d4e01 lea ecx,[esi+0x1]
ds:0103ea45=00000000
7800d087 890a mov [edx],ecx
ds:13e597a8=13e595f4
7800d089 894c32fc mov [edx+esi-0x4],ecx
ds:0103ea46=00000000
7800d08d 8b75f4 mov esi,[ebp-0xc]
ss:04269e6e=00000000
7800d090 8b0e mov ecx,[esi]
ds:0000003f=????????
7800d092 85c9 test ecx,ecx
7800d094 8d7901 lea edi,[ecx+0x1]
ds:14e97ffa=????????
7800d097 893e mov [esi],edi
ds:0000003f=????????
7800d099 751a jnz set_sbh_threshold+0x718 (7800d0b5)

*----> Stack Back Trace <----*

FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0322b468 7800c730 021cd9e8 0322b754 0322b8c8 780c9dbb !set_sbh_threshold
0322b49c 780012d7 00000062 7800320e 00000062 00000001 !exception::what
0322b8d4 780c2615 0000002f 0000002f 00000013 01ac6e7e !malloc
0322ff84 78003820 0000001c 00000000 01320588 03087860
!std::basic_string<unsigned short,std::char_traits<unsigned
short>,std::allocator<unsigned short> >::_Grow
0322ffb8 77f04ee8 03087860 00000000 01320588 03087860 !beginthreadex
0322ffec 00000000 780037c5 03087860 00000000 00000000 kernel32!lstrcmpiW
00000000 00000000 00000000 00000000 00000000 00000000 !<nosymbols>

Stephen Howe

2006-03-13, 7:02 pm

> Below is some Dr.Watson output from our server application which seems
> to randomly crash indicating some sort of STL string problem. I am aware
of
> the dinkumware fixes but have been reluctant to apply these until certain
> that the lack of a fix is the cause. STL strings are passed across DLL
> boundaries but I am sure the CRT linkage is consistent throughout

Consistency is not in itself sufficient.
I hope you are linking with RTL in DLL form.
You can get away with static libraries, but in which case your DLL should
not be modifying the strings.

Stephen Howe

Tom Widmer [VC++ MVP]

2006-03-14, 7:58 am

George wrote:
> Visual Studio 6 Service Pack 5.
>
> All,
> Below is some Dr.Watson output from our server application which seems
> to randomly crash indicating some sort of STL string problem. I am aware of
> the dinkumware fixes but have been reluctant to apply these until certain
> that the lack of a fix is the cause. STL strings are passed across DLL
> boundaries but I am sure the CRT linkage is consistent throughout and
> typically the strings are only read or copied.

In addition to Stephen's reply:

Copying is a potential problem, since under VC6, std::basic_string is
reference counted and hence copies aren't real copies (and hence you may
end up destroying the characters of a string on the other side of the
DLL boundary). I believe the fixes you mention address this by telling
you how to disable reference counting...

Tom

David Wilkinson

2006-03-14, 7:03 pm

Tom Widmer [VC++ MVP] wrote:

> George wrote:
>
>
>
> In addition to Stephen's reply:
>
> Copying is a potential problem, since under VC6, std::basic_string is
> reference counted and hence copies aren't real copies (and hence you may
> end up destroying the characters of a string on the other side of the
> DLL boundary). I believe the fixes you mention address this by telling
> you how to disable reference counting...
>
> Tom

Tom:

But these fixes do not take effect unless you rebuild MSVCP60.DLL. See
the other recent thread started by Andreas Fabri.

David Wilkinson

Tom Widmer [VC++ MVP]

2006-03-15, 7:58 am

David Wilkinson wrote:
> Tom Widmer [VC++ MVP] wrote:
>
>
>
> Tom:
>
> But these fixes do not take effect unless you rebuild MSVCP60.DLL. See
> the other recent thread started by Andreas Fabri.

True (and upgrading to a newer VC or buying the Dinkumware upgrade
library is probably the best solution in the absence of an SP fix). A
workaround to avoid having to rebuild is to force unsharing of strings:

__declspec(dllimport) std::string const& dllFunc();

std::string s(dllFunc());
s[0]; //forces unshare and makes a local copy of the string.

It is only safe to pass/return const references, and to immediately
unshare any copies made. Ideally, std::string shouldn't be used at all
in a DLL interface, since it introduces a dependency on a particular
compiler and library version.

Tom

Sponsored Links