Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: stringstream crash



Permlink Replies: 2 - Last Post: Oct 22, 2015 5:24 AM Last Post By: david hoke
Mats karlsson

Posts: 64
Registered: 11/8/99
stringstream crash
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 27, 2014 12:39 PM
Hi,
I have an application that links to various third party libraries.
In my main, I can create a stringstream with no crash.
In a linked DLL, however, when trying to create a stringstream, just
simply as this:

     stringstream names;


I get a Debugger exception Notification:
Raised exception class $C0000005 with message 'access violation etc...

Clicking on the break button takes me to line 1881 in xlocale header
file, i.e.

  #if __BORLANDC__	/* compiler test */
	*(size_t *)&table_size = 1 << CHAR_BIT;	// <-- crash


And there is no way to move further from here.

I do believe this might(?) be related to mixing static and dynamic
runtime but can't find out how to fix it.

My DLL is compiled with -tR compiler flag, and my app is 'link with
dynamic RTL'.

Any clues??
tk

Edited by: totte karlsson on Sep 28, 2014 1:38 PM
Kerem Demir

Posts: 7
Registered: 7/26/12
Re: stringstream crash
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 13, 2015 3:18 AM   in response to: Mats karlsson in response to: Mats karlsson
totte karlsson wrote:
Hi,
I have an application that links to various third party libraries.
In my main, I can create a stringstream with no crash.
In a linked DLL, however, when trying to create a stringstream, just
simply as this:

     stringstream names;


I get a Debugger exception Notification:
Raised exception class $C0000005 with message 'access violation etc...

Clicking on the break button takes me to line 1881 in xlocale header
file, i.e.

  #if __BORLANDC__	/* compiler test */
	*(size_t *)&table_size = 1 << CHAR_BIT;	// <-- crash


And there is no way to move further from here.

I do believe this might(?) be related to mixing static and dynamic
runtime but can't find out how to fix it.

My DLL is compiled with -tR compiler flag, and my app is 'link with
dynamic RTL'.

Any clues??
tk

Edited by: totte karlsson on Sep 28, 2014 1:38 PM

Hello totte,

I am facing a very similar problem. Are you using C++Builder Seattle and the new CLANG enhanced C++11 compiler for win32?

Kerem
david hoke

Posts: 616
Registered: 2/9/07
Re: stringstream crash
Click to report abuse...   Click to reply to this thread Reply
  Posted: Oct 22, 2015 5:24 AM   in response to: Kerem Demir in response to: Kerem Demir
Kerem Demir wrote:

totte karlsson wrote:
Hi,
I have an application that links to various third party libraries.
In my main, I can create a stringstream with no crash.
In a linked DLL, however, when trying to create a stringstream,
just simply as this:

     stringstream names;


I get a Debugger exception Notification:
Raised exception class $C0000005 with message 'access violation
etc...

Clicking on the break button takes me to line 1881 in xlocale
header file, i.e.

  #if BORLANDC	/* compiler test */
	*(size_t *)&table_size = 1 << CHAR_BIT;	// <-- crash


And there is no way to move further from here.

I do believe this might(?) be related to mixing static and dynamic
runtime but can't find out how to fix it.

My DLL is compiled with -tR compiler flag, and my app is 'link with
dynamic RTL'.

Any clues??
tk

Edited by: totte karlsson on Sep 28, 2014 1:38 PM

Hello totte,

I am facing a very similar problem. Are you using C++Builder Seattle
and the new CLANG enhanced C++11 compiler for win32?

I apparently missed totte's OP...

I experienced something like this with much older version (bds2006),
but it did not (as far as I could tell) have anything to do with mixing
static and dynamic libs (although that's a bad idea.)

My solution to the problem was to simply declare an unused stream of
type's being needed in the .DLLs.***

The RTL implementation apparently does not handle initializing (some)
things in .DLL startup (or something of that sort), and if allowed to
initialize in the main program (I think it was simply by having one
declared, I forget now, it may have been as a global), that got
whatever needed to be inited done before the .DLLs needed
<whateveritis>...

***FWIW, I suspect a side-effect of this, is that it likely would not
be possible to successfully use a builder created .DLL with those types
that seem to require program-related RTL initialization, by some other
language system (python, VC, etc.)...
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02