Weird memory issue with /clr, no problems without

**Mark Salsbery [MVP]** · Aug 6 '08, 07:05 PM

Re: Weird memory issue with /clr, no problems without

"Mesan" <935main@gmail. comwrote in message
news:c1474bcb-c8e0-424d-839c-7e0bc68ca778@j7 g2000prm.google groups.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]** · Aug 6 '08, 07:15 PM

Re: Weird memory issue with /clr, no problems without

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\TestCL RConsole.pch"
/Fo"Debug\\" /Fd"Debug\vc90.p db" /W3 /nologo /c /Zi /clr
/TP /errorReport:pro mpt
/FU "c:\Windows\Mic rosoft.NET\Fram ework\v2.0.5072 7\System.dll"
/FU "c:\Windows\Mic rosoft.NET\Fram ework\v2.0.5072 7\System.Data.d ll"
/FU "c:\Windows\Mic rosoft.NET\Fram ework\v2.0.5072 7\System.XML.dl l"

Linker:

/OUT:"E:\Source_ LabCDM\Debug\Te stCLRConsole.ex e" /INCREMENTAL
/NOLOGO /MANIFEST
/MANIFESTFILE:"D ebug\TestCLRCon sole.exe.interm ediate.manifest "
/MANIFESTUAC:"le vel='asInvoker' uiAccess='false '"
/DEBUG /ASSEMBLYDEBUG /PDB:"e:\Source_ LabCDM\Debug\Te stCLRConsole.pd b"
/DYNAMICBASE /FIXED:No /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PRO MPT

Mark

--
Mark Salsbery
Microsoft MVP - Visual C++

**Mesan** · Aug 6 '08, 07:25 PM

Re: Weird memory issue with /clr, no problems without

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

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\TestCL RConsole.pch"
/Fo"Debug\\" /Fd"Debug\vc90.p db" /W3 /nologo /c /Zi /clr
/TP /errorReport:pro mpt
/FU "c:\Windows\Mic rosoft.NET\Fram ework\v2.0.5072 7\System.dll"
/FU "c:\Windows\Mic rosoft.NET\Fram ework\v2.0.5072 7\System.Data.d ll"
/FU "c:\Windows\Mic rosoft.NET\Fram ework\v2.0.5072 7\System.XML.dl l"
>
Linker:
>
/OUT:"E:\Source_ LabCDM\Debug\Te stCLRConsole.ex e" /INCREMENTAL
/NOLOGO /MANIFEST
/MANIFESTFILE:"D ebug\TestCLRCon sole.exe.interm ediate.manifest "
/MANIFESTUAC:"le vel='asInvoker' uiAccess='false '"
/DEBUG /ASSEMBLYDEBUG /PDB:"e:\Source_ LabCDM\Debug\Te stCLRConsole.pd b"
/DYNAMICBASE /FIXED:No /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PRO MPT
>
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]** · Aug 7 '08, 06:25 PM

Re: Weird memory issue with /clr, no problems without

"Mesan" <935main@gmail. comwrote in message
news:23d874b0-e503-4227-99e2-8f27d84977f5@j7 g2000prm.google groups.com...

On Aug 6, 3:38 pm, Mesan <935m...@gmail. comwrote:
>
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]** · Aug 7 '08, 08:05 PM

Re: Weird memory issue with /clr, no problems without

"Mesan" <935main@gmail. comwrote in message
news:afff527e-ba61-4718-8ee8-9efac0c58533@w3 9g2000prb.googl egroups.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,Fc ode,Fmos,Fimp,F rtrndt,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)variabl e"
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::ToInt3 2() 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** · Aug 11 '08, 07:45 PM

Re: Weird memory issue with /clr, no problems without

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

"Mesan" <935m...@gmail. comwrote in message
>
news:afff527e-ba61-4718-8ee8-9efac0c58533@w3 9g2000prb.googl egroups.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,Fc ode,Fmos,Fimp,F rtrndt,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)variabl e"
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::ToInt3 2() 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@yahoo.com** · Aug 22 '08, 11:45 PM

Re: Weird memory issue with /clr, no problems without

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::ToInt3 2() 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.

Weird memory issue with /clr, no problems without

Weird memory issue with /clr, no problems without

Comment

Comment

Comment

Comment

Comment

Comment

Comment