file opening in a mixed-mode solution

  • Thread starter Thread starter Lee Crabtree
  • Start date Start date
L

Lee Crabtree

I've got a solution that has a C++ project that compiles to a DLL, and a
C# project that is the main piece of the program.

The DLL is managed C++ on top of regular C++. In one of the native
functions, I make a call that looks a little like this:

file = _fsopen(path, mode, SH_DENYNO);

That call generates a System.NullReferenceException, which makes
ABSOLUTELY no sense, since it's happening in unmanaged code. On top of
all that, both the path and mode are correctly set.

What am I doing wrong?

Lee
 
Lee said:
I've got a solution that has a C++ project that compiles to a DLL, and a
C# project that is the main piece of the program.

The DLL is managed C++ on top of regular C++. In one of the native
functions, I make a call that looks a little like this:

file = _fsopen(path, mode, SH_DENYNO);

That call generates a System.NullReferenceException, which makes
ABSOLUTELY no sense, since it's happening in unmanaged code. On top of
all that, both the path and mode are correctly set.

What am I doing wrong?

Lee
Click to expand...

Some experimentation has shown that it's got something to do with where
the file is located. If it's in the same directory as the executable
(so that the path is ".\\file.ext"), it works. Likewise, if the file is
in the root (so that the path is "c:\\file.ext"), there's no problem.
However, in any other folder (where the path is something like
"c:\\dir\\file.ext"), there's a System.NullReferenceException.

I've checked permissions already, so that's not it. I'm completely at a
loss here.

Lee
 
Lee Crabtree said:
I've got a solution that has a C++ project that compiles to a DLL, and a
C# project that is the main piece of the program.

The DLL is managed C++ on top of regular C++. In one of the native
functions, I make a call that looks a little like this:

file = _fsopen(path, mode, SH_DENYNO);

That call generates a System.NullReferenceException, which makes
ABSOLUTELY no sense, since it's happening in unmanaged code. On top of
all that, both the path and mode are correctly set.

What am I doing wrong?
Click to expand...

Just a guess... but most likely, you've misdiagnosed where the exception is
coming from, because you're absolutely right - getting a managed exception
out of a native library function makes no sense.

Are you absolutely 100% sure that's where the exception is coming from?

-cd
 
Carl said:
Just a guess... but most likely, you've misdiagnosed where the exception is
coming from, because you're absolutely right - getting a managed exception
out of a native library function makes no sense.

Are you absolutely 100% sure that's where the exception is coming from?

-cd
Click to expand...

I'm stepping through one at a time, and that line is what always
triggers it.

Lee
 
Lee Crabtree said:
I'm stepping through one at a time, and that line is what always triggers
it.
Click to expand...

Interesting. Have you tried doing something like using CreateFile to open
the file instead? I can't think of any reason why it should make any
difference, but you're in wierd territory here.

-cd
 
Carl said:
Interesting. Have you tried doing something like using CreateFile to open
the file instead? I can't think of any reason why it should make any
difference, but you're in wierd territory here.

-cd
Click to expand...
Not yet. I put a wee test app together to try and see if managed C++
got in the way of fopen or something. It's never been the case in the
past, but when you have no other options... Anyway, it was no good. It
worked just like it always has (that's odd...the fact that it worked is
somehow BAD).

I'm getting a flat forehead.

Lee
 
Lee said:
I'm stepping through one at a time, and that line is what always
triggers it.
Click to expand...

Is the offending line compiled to native or CLR?

Make sure you debug in mixed or native mode. My guess is that there is
something wrong with the native code (though you haven't shown enough code
for us to spot it), whoses neat effect is to generate a
NullReferenceException when switching back from nativeto managed. But what
you are seing is probably the symptom, not the cause.

Arnaud
MVP - VC
 
Arnaud said:
Is the offending line compiled to native or CLR?

Make sure you debug in mixed or native mode. My guess is that there is
something wrong with the native code (though you haven't shown enough code
for us to spot it), whoses neat effect is to generate a
NullReferenceException when switching back from nativeto managed. But what
you are seing is probably the symptom, not the cause.

Arnaud
MVP - VC
Click to expand...

I've done some more testing, and it's the act of opening a file that's
causing the exception. Anywhere in my unmanaged code, I can do
something like

FILE* file = fopen("C:\\file", "rb");

and I generate an exception. What gives?

Lee
 
Okay, I have officially coded myself into a straitjacket.

I have two projects in this solution (as I said). One is a C# form app,
and the other is a mixed-mode DLL. When I set the debugging mode of the
C# app to allow unmanaged debugging, the fopen executes without a hitch.
When I turn off unmanaged debugging, I get the NullReferenceException.

Lee
 
Lee said:
Okay, I have officially coded myself into a straitjacket.

I have two projects in this solution (as I said). One is a C# form
app, and the other is a mixed-mode DLL. When I set the debugging
mode of the C# app to allow unmanaged debugging, the fopen executes
without a hitch. When I turn off unmanaged debugging, I get the
NullReferenceException.
Click to expand...

What happens without any debugger?

Also, if you debug with "allow unmanaged" turned on, are you sure, it's not
some native code *after* the file opening that triggers the exception? Can
you debug step-by-step the unmanaged code until you go back to the managed
caller?

Arnaud
MVP - VC
 
Arnaud said:
What happens without any debugger?

Also, if you debug with "allow unmanaged" turned on, are you sure, it's not
some native code *after* the file opening that triggers the exception? Can
you debug step-by-step the unmanaged code until you go back to the managed
caller?

Arnaud
MVP - VC
Click to expand...

I found it, finally. I turned on the "allow unmanaged" debugger and
went looking for some other possible problem. I found out that my
predecessor had used a strcpy to copy the entirety of a file into a
buffer. The problem was, you guessed it, that the buffer wasn't always
big enough. That wasn't a problem for them, because the files they were
working with were always small. I, however, had to enlarge the size of
said file, and boom.

In the end, a liberal usage of asserts and some pointer arithmetic saved
the day.

Let this be a lesson to us all - never trust the debugger. It's handy,
it points out a lot of things, but it'll never be able to track things
down to your satisfaction. If I'd stopped and used my gray matter, I
might have found this earlier and saved myself several hours of pain.
Oh well. We live and learn. At any rate, we live.

Lee

P.S. Thanks for the debugger setting. I'd never even noticed that one.
 
Lee said:
I found it, finally. I turned on the "allow unmanaged" debugger and
went looking for some other possible problem. I found out that my
predecessor had used a strcpy to copy the entirety of a file into a
buffer. The problem was, you guessed it, that the buffer wasn't
always big enough. That wasn't a problem for them, because the files
they were working with were always small. I, however, had to enlarge
the size of said file, and boom.

In the end, a liberal usage of asserts and some pointer arithmetic
saved the day.

Let this be a lesson to us all - never trust the debugger. It's
handy, it points out a lot of things, but it'll never be able to
track things down to your satisfaction. If I'd stopped and used my
gray matter, I might have found this earlier and saved myself several
hours of pain. Oh well. We live and learn. At any rate, we live.
Click to expand...


Ah, the good ol'one stack overflow !!!! ;-) I milit for an internal code
policy that FORBIDS strcpy, raw pointer arithmetic and the like... STL gives
you about the same flexibility but is much more secure...

Arnaud
MVP - VC
 
Back
Top