possible unnamed temporary problem?

Hi,
I have code that goes something like
LNstring s = LNstring::convert(i) + ":" + LNTableMsg(vect[i]).toStr() +
LNLog::getMsgFieldSeparator();
and causes a crash. Stepping it through the debugger I noticed that the
statements are executed in the following order:
1) LNLog::getMsgFieldSeparator()
2) LNTableMsg::LNTableMsg(vect[i])
3) LNstring::convert(i)
Crash!!!
I was wondering if there is a possible compiler issue here with MSVC's
handling of unnamed variable LNTableMsg (hence .toStr() was never called)

Any info is appreciated!
thanks,
max

Victor
Fri Feb 25 13:59:09 CST 2005

"max khesin" <max@nospam.com> wrote...
> I have code that goes something like
> LNstring s = LNstring::convert(i) + ":" + LNTableMsg(vect[i]).toStr() +
> LNLog::getMsgFieldSeparator();
> and causes a crash. Stepping it through the debugger I noticed that the
> statements are executed in the following order:
> 1) LNLog::getMsgFieldSeparator()
> 2) LNTableMsg::LNTableMsg(vect[i])
> 3) LNstring::convert(i)
> Crash!!!
> I was wondering if there is a possible compiler issue here with MSVC's
> handling of unnamed variable LNTableMsg (hence .toStr() was never called)

IME, when the programmer thinks it's "a compiler issue" 99.98% of cases
are actually not that but some kind of mistake, like uninitialised pointer
or a dangling one. I am not saying that yours is the same case. With the
amount of code provided it's impossible to divine what's happening. Should
we know what 'LNstring' is? And what is 'LNTableMsg'? And what is 'vect'?
And how LNTableMsg constructs an object from an element of 'vect'...

Anyway, the "Crash!!!" apparently follows the call to LNstring::convert(i).
What's that one do? Have you actually tried to run it in the debugger,
which should tell you where the crash occurs?

You see, you need to make a tiny bit of effort and help us help you.

V

Larry
Fri Feb 25 14:35:13 CST 2005

"max khesin" <max@nospam.com> wrote in message
news:uMZ7oI3GFHA.3648@TK2MSFTNGP09.phx.gbl...
> Hi,
> I have code that goes something like
> LNstring s = LNstring::convert(i) + ":" + LNTableMsg(vect[i]).toStr() + LNLog::getMsgFieldSeparator();
> and causes a crash. Stepping it through the debugger I noticed that the statements are executed in the following order:
> 1) LNLog::getMsgFieldSeparator()
> 2) LNTableMsg::LNTableMsg(vect[i])
> 3) LNstring::convert(i)
> Crash!!!
> I was wondering if there is a possible compiler issue here with MSVC's handling of unnamed variable LNTableMsg (hence .toStr() was
> never called)
>
> Any info is appreciated!
> thanks,


I concur with Victor on this, but I'll add a comment to
help free your mind of compiler suspicion.

The order of evaluation you mention above is fully within
the latitude granted to implementers by the C++ standard.

As someone who has unearthed a few code generation
bugs, I remain convinced that, unless you are an extremely
expert programmer, (smarter than most people I have met),
the compiler should be the last place to focus your suspicion,
not the first. The "Crash!!!" (whatever that means) is much
more likely to be your doing rather than the compiler's.

--
--Larry Brasfield
email: donotspam_larry_brasfield@hotmail.com
Above views may belong only to me.

maxk
Sun Feb 27 06:56:22 CST 2005

Hey guys,
I have been around the block for at least a little while and do not
need to be patronized here. I would have never posted this code or
suspected the compiler without stepping into the code. Nothing remotely
dangerous happens in this code (other than possibly
LNTableMsg(vect[i]), which calls into a 3d party lib, so who knows). I
remember unnamed temps being mentioned as a problem in at least one
version of msvc, and wanted to confirm my recollection.

'the boy who cried "compiler!"'


Larry Brasfield wrote:
> "max khesin" <max@nospam.com> wrote in message
> news:uMZ7oI3GFHA.3648@TK2MSFTNGP09.phx.gbl...
> > Hi,
> > I have code that goes something like
> > LNstring s = LNstring::convert(i) + ":" +
LNTableMsg(vect[i]).toStr() + LNLog::getMsgFieldSeparator();
> > and causes a crash. Stepping it through the debugger I noticed that
the statements are executed in the following order:
> > 1) LNLog::getMsgFieldSeparator()
> > 2) LNTableMsg::LNTableMsg(vect[i])
> > 3) LNstring::convert(i)
> > Crash!!!
> > I was wondering if there is a possible compiler issue here with
MSVC's handling of unnamed variable LNTableMsg (hence .toStr() was
> > never called)
> >
> > Any info is appreciated!
> > thanks,
>
>
> I concur with Victor on this, but I'll add a comment to
> help free your mind of compiler suspicion.
>
> The order of evaluation you mention above is fully within
> the latitude granted to implementers by the C++ standard.
>
> As someone who has unearthed a few code generation
> bugs, I remain convinced that, unless you are an extremely
> expert programmer, (smarter than most people I have met),
> the compiler should be the last place to focus your suspicion,
> not the first. The "Crash!!!" (whatever that means) is much
> more likely to be your doing rather than the compiler's.
>
> --
> --Larry Brasfield
> email: donotspam_larry_brasfield@hotmail.com
> Above views may belong only to me.

Tom
Mon Feb 28 04:31:45 CST 2005

max khesin wrote:
> Hi,
> I have code that goes something like
> LNstring s = LNstring::convert(i) + ":" + LNTableMsg(vect[i]).toStr() +
> LNLog::getMsgFieldSeparator();
> and causes a crash. Stepping it through the debugger I noticed that the
> statements are executed in the following order:
> 1) LNLog::getMsgFieldSeparator()
> 2) LNTableMsg::LNTableMsg(vect[i])
> 3) LNstring::convert(i)
> Crash!!!
> I was wondering if there is a possible compiler issue here with MSVC's
> handling of unnamed variable LNTableMsg (hence .toStr() was never called)

Well, since according to your tracing of calls it doesn't get as far as
calling operator+(LNstring/cchar*), it doesn't matter that it hasn't
called toStr yet. Certainly I've never had any problems in MSVC with
temporaries being destroyed before the end of the full expression.

I'm assuming that the type of each sub-expression is LNstring (except
for ":" of course).

So, does it crash inside the convert call? Has that call completed? What
call is actually happening when the crash occurs? What exactly is the
crash? Is it a debug heap assertion?

Overwhelmingly the most likely cause of such a crash is a corrupt heap,
assuming the line in question has been verified as completely correct
(Are the LN classes yours? Are they fully tested?). The cause of the
corrupt heap might be that the memory allocation in LNTableMsg is using
a different heap to your application. Have you matched CRT versions with
the 3rd party DLL? Have you tried stripping down to a program that only
contains the problem line?

Tom