Weird memory issue with /clr, no problems without

[Mesan]

This is baffling me - I'm coming here in a desperate plea that someone
smarter than myself (which isn't hard) might be able to explain what's
going on.

I've got a native C++ console app that has been working perfectly -
built using VCExpress 2005, VC Redist, platform SDK (include
Windows.h, define WIN32_LEAN_AND_MEAN - am I missing anything?)

I recently found out how to "CLR enable" the app by 1) changing my new-
make file to compile with "/EHac /clr" instead of "/EHsc" and 2)
adding "#using <mscorlib.dll>; using namespace System;" to my code.

If I compile the program with all that C++/CLI stuff there's a weird
bug that shows up at runtime but not if I'm stepping through the
debugger - it's as if the debugger is giving extra time for statements
to complete, but I'm just pulling at straws there. There aren't any
threads in the program, so I'm not running into race conditions or
deadlocks within my own code, the problem looks like it's coming from
the environment.

Here's the behavior:
"run" the code in debugger w/no breakpoints: buggy.
"walk" the code in the debugger line by line: no problems.
"run" the code natively (outside the debugger): buggy.
Re-compile without all the C++/CLI stuff and run outside the debugger:
no problems.

What's going on? Is it a difference between the /EHsc (synchronous)
vs. /EHac (async) exception handling? There aren't any exceptions
being thrown - why would that make a difference?

I'm really stuck with this one - has anyone seen anything like this
before?

With tons of appreciation and thanks,

Mesan

[Mark Salsbery [MVP]]

"Mesan" <93*****@gmail.comwrote in message
news:c1**********************************@j7g2000p rm.googlegroups.com...

This is baffling me - I'm coming here in a desperate plea that someone
smarter than myself (which isn't hard) might be able to explain what's
going on.

I've got a native C++ console app that has been working perfectly -
built using VCExpress 2005, VC Redist, platform SDK (include
Windows.h, define WIN32_LEAN_AND_MEAN - am I missing anything?)

I recently found out how to "CLR enable" the app by 1) changing my new-
make file to compile with "/EHac /clr" instead of "/EHsc" and 2)
adding "#using <mscorlib.dll>; using namespace System;" to my code.

If I compile the program with all that C++/CLI stuff there's a weird
bug that shows up at runtime but not if I'm stepping through the
debugger - it's as if the debugger is giving extra time for statements
to complete, but I'm just pulling at straws there. There aren't any
threads in the program, so I'm not running into race conditions or
deadlocks within my own code, the problem looks like it's coming from
the environment.

Here's the behavior:
"run" the code in debugger w/no breakpoints: buggy.
"walk" the code in the debugger line by line: no problems.
"run" the code natively (outside the debugger): buggy.
Re-compile without all the C++/CLI stuff and run outside the debugger:
no problems.

What is the buggy behavior?

>
What's going on? Is it a difference between the /EHsc (synchronous)
vs. /EHac (async) exception handling? There aren't any exceptions
being thrown - why would that make a difference?

From the docs:
"/clr implies /EHa, and no other /EH options are allowed with /clr."
Maybe try creating a managed console app with the wizard. Then compare the
compiler/linker settings to the settings in your makefile ...any
differences?

Mark

--
Mark Salsbery
Microsoft MVP - Visual C++

>
I'm really stuck with this one - has anyone seen anything like this
before?

With tons of appreciation and thanks,

Mesan

[Mark Salsbery [MVP]]

FWIW - here's the default command lines for a wizard-generated CLR console
project...

Compiler:

/Od /D "WIN32" /D "_DEBUG" /D "_UNICODE" /D "UNICODE"
/FD /EHa /MDd /Yu"stdafx.h" /Fp"Debug\TestCLRConsole.pch"
/Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /Zi /clr
/TP /errorReport:prompt
/FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\Sys tem.dll"
/FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\Sys tem.Data.dll"
/FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\Sys tem.XML.dll"
Linker:

/OUT:"E:\Source_LabCDM\Debug\TestCLRConsole.exe" /INCREMENTAL
/NOLOGO /MANIFEST
/MANIFESTFILE:"Debug\TestCLRConsole.exe.intermediat e.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/DEBUG /ASSEMBLYDEBUG /PDB:"e:\Source_LabCDM\Debug\TestCLRConsole.pdb"
/DYNAMICBASE /FIXED:No /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT
Mark

--
Mark Salsbery
Microsoft MVP - Visual C++

[Mesan]

On Aug 6, 12:06*pm, "Mark Salsbery [MVP]"
<MarkSalsbery[MVP]@newsgroup.nospamwrote:

FWIW - here's the default command lines for a wizard-generated CLR console
project...

Compiler:

/Od /D "WIN32" /D "_DEBUG" /D "_UNICODE" /D "UNICODE"
/FD /EHa /MDd /Yu"stdafx.h" /Fp"Debug\TestCLRConsole.pch"
/Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /Zi /clr
/TP /errorReport:prompt
/FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\Sys tem.dll"
/FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\Sys tem.Data.dll"
/FU "c:\Windows\Microsoft.NET\Framework\v2.0.50727\Sys tem.XML.dll"

Linker:

/OUT:"E:\Source_LabCDM\Debug\TestCLRConsole.exe" /INCREMENTAL
/NOLOGO /MANIFEST
/MANIFESTFILE:"Debug\TestCLRConsole.exe.intermediat e.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/DEBUG /ASSEMBLYDEBUG /PDB:"e:\Source_LabCDM\Debug\TestCLRConsole.pdb"
/DYNAMICBASE /FIXED:No /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT

Mark

--
Mark Salsbery
Microsoft MVP - Visual C++

Wow - I am so thankful to both of you for your responses. I'm in the
process of trying them - no luck yet, but I haven't tried anything yet
either. I just wanted to post back and say thank you.

Wish me luck!

Mesan

[Mark Salsbery [MVP]]

"Mesan" <93*****@gmail.comwrote in message
news:23**********************************@j7g2000p rm.googlegroups.com...

On Aug 6, 3:38 pm, Mesan <[e-mail]:

I replaced the atoi() call with System::Convert::ToInt32() and that
seems to have fixed it.
Is that a bad solution? It still seems kind of like voodoo to me, I
wish I had a better handle on exactly what caused the issue.

There's nothing wrong with the fix, but again, there wasn't enough info for
me to determine what was going wrong with your call to atoi().
Mark

--
Mark Salsbery
Microsoft MVP - Visual C++

>
Any ideas?

[Mark Salsbery [MVP]]

"Mesan" <93*****@gmail.comwrote in message
news:af**********************************@w39g2000 prb.googlegroups.com...

>
temp_led is defined as LED_LIST_type *

LED_LIST_type is defined as:

typedef struct def_LED {
long trans;
int line;
long acct;
long postdt;
long effdte;
char ref[3];
long amt;
char check[8];
char aslkey[7];
char name[67];
char descr[67];
char code[7];
int mos;
char imp[4];
char userid[4];
long rtrndt;
short
Fcheck,Faslkey,Fname,Fdescr,Fcode,Fmos,Fimp,Frtrnd t,Fuserid;
} LED_type;
typedef struct def_LED_LIST {
LED_type data;
struct def_LED_LIST *prior, *next;
} LED_LIST_type;

When atoi() is called, temp is a char[] with the contents "1".
check_months() is a validation function.
address_of_1 is an int, initialized to 1. The check_months() function
wants a pointer to a counter, but in this case I only want to send a
1, I couldn't say &1, so I used &address_of_1.
The magic +2 gets you to the actual string data. When you send
variable length strings back and forth to a DB2 database, the data
comes with the first two bytes as the length of the string, the
remainder is the string data. It's often used as a struct{} with a
short and a char[], but this company commonly used "(short)variable"
to get the length and "variable+2" to access the string data.

I don't have any other threads in the program, the only thing I can
think of is the MS implementation goo behind the scenes that hooks up
the .Net app domain with this native code.

Does this information give sufficient context to the code?

Excellent - thanks for the details!

I don't see anything that should be a problem.

Uninitialized or invalid variable (pointer!) maybe being used somewhere and
it just happens to work...?

If I think of something I'll let you know!

Mark

--
Mark Salsbery
Microsoft MVP - Visual C++

>
Thanks for not giving up on this - I can't help but feel like my use
of Convert::ToInt32() is just makeup - it looks better, but the
underlying problem is still lurking, waiting to catch me with other C+
+/CLI code when I least expect it.

[Mesan]

On Aug 7, 12:52*pm, "Mark Salsbery [MVP]"
<MarkSalsbery[MVP]@newsgroup.nospamwrote:

"Mesan" <[e-mail] in message

news:af**********************************@w39g2000 prb.googlegroups.com...

temp_led is defined as LED_LIST_type *

LED_LIST_type is defined as:

* typedef struct def_LED {
* * * long *trans;
* * * int * line;
* * * long *acct;
* * * long *postdt;
* * * long *effdte;
* * * char ref[3];
* * * long *amt;
* * * char check[8];
* * * char aslkey[7];
* * * char name[67];
* * * char descr[67];
* * * char code[7];
* * * int * mos;
* * * char imp[4];
* * * char userid[4];
* * * long *rtrndt;
* * * short
Fcheck,Faslkey,Fname,Fdescr,Fcode,Fmos,Fimp,Frtrnd t,Fuserid;
* * * } LED_type;
* typedef struct def_LED_LIST {
* * *LED_type data;
* * *struct def_LED_LIST *prior, *next;
* * *} LED_LIST_type;

When atoi() is called, temp is a char[] with the contents "1".
check_months() is a validation function.
address_of_1 is an int, initialized to 1. *The check_months() function
wants a pointer to a counter, but in this case I only want to send a
1, I couldn't say &1, so I used &address_of_1.
The magic +2 gets you to the actual string data. *When you send
variable length strings back and forth to a DB2 database, the data
comes with the first two bytes as the length of the string, the
remainder is the string data. *It's often used as a struct{} with a
short and a char[], but this company commonly used "(short)variable"
to get the length and "variable+2" to access the string data.

I don't have any other threads in the program, the only thing I can
think of is the MS implementation goo behind the scenes that hooks up
the .Net app domain with this native code.

Does this information give sufficient context to the code?

Excellent - thanks for the details!

I don't see anything that should be a problem.

Uninitialized or invalid variable (pointer!) maybe being used somewhere and
it just happens to work...?

If I think of something I'll let you know!

Mark

--
Mark Salsbery
Microsoft MVP - Visual C++

Thanks for not giving up on this - I can't help but feel like my use
of Convert::ToInt32() is just makeup - it looks better, but the
underlying problem is still lurking, waiting to catch me with other C+
+/CLI code when I least expect it.- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Mark - Any ideas come to mind?

Just curious.

[tfl_bibek]

Hi,

Found a good answer yet?

I have a very similar problem, and I found a solution: "/
ASSEMBLYDEBUG" (linker switch)

This enables runtime-tracking and disables JIT optimizations.

I __suspect__ the problem lies somewhere in the JIT optimizations -
but after two days of debugging, I still can't say for sure if that is
the case or not.

All I know is that after flipping all the switches that were different
between "debug" and "release" mode, this is the one that did the
trick. Now I've left everything else in standard "release" settings,
but changed this item. [Granted, with runtime debugging no JIT
optimizations, all the other switches may get washed away anyway.]

Be aware that the .Net Garbage Collector runs in a separate thread.
(supposedly you can turn this off with 'gcConcurrent' -
http://msdn.microsoft.com/en-us/library/yhwwzef8.aspx ). But there's
advantages to letting it run concurrently. Whether enough to justify
disabling JIT optimizations, I don't know; but I have a multi-threaded
program anyway, so it's not immediately relevant to me.

(I'm creating a .Net wrapper for a native C library. I have all of
one variable to initialize, and it only happens in a few places in one
file. There's slim chance of it not getting initialized, especially
after two days of me poring over the 8 places it could be. But it
could still be the _way_ I'm initializing things. Who knows...)

Good luck. And if you've found any other solutions, I'd love to hear
them.
Ciao!
Bibek
Mesan wrote:

Thanks for not giving up on this - I can't help but feel like my use
of Convert::ToInt32() is just makeup - it looks better, but the
underlying problem is still lurking, waiting to catch me with other C+
+/CLI code when I least expect it.- Hide quoted text -

Mark - Any ideas come to mind?

Just curious.