OK, C# can be a PITA
-
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around!
I would normally just alloc the 'unmanaged' memory :)
**
xacc.ide-0.2.0.57 - now with C# 2.0 parser and seamless VS2005 solution support!
**
-
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithJust a hint: in .NET you can pin objects so the GC doesn't move them in memory.
________________________________________________ Personal Blog [ITA] - Tech Blog [ENG] Developing ScrewTurn Wiki 2.0 (2.0 Alpha is out)
-
I honestly don't understand why people use p/invoke in c#. I've never had to use it and I've written a lot of code over the last few years in c# with the single exception of an article here for the .net platform on pocket pc. I must be missing something on this one, why did you need to use it and was there no other way to accomplish what you did without it?
Monitoring for changes to files on a SAMBA share. The modern API wrapped by FileSystemWatcher isn't supported by Samba, and based on a message I managed to excavate from a mailing list archive won't be in the future because implementing it with acceptable performance would require large chucks of kernal level code. I've done several other minor things but that was the biggie.
-- Rules of thumb should not be taken for the whole hand.
-
Maybe I'll have to write some articles on this when I get a chance! :-) Any suggestions on where to start?
J. Dunlap wrote:
Any suggestions on where to start?
With USB, or working with unsafe code? Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithI would recommend wrapping unsafe code in its own app domain if possible. At least the main app will be safe from unexpected errors.
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
-
So if your essential point is
Marc Clifton wrote:
P/Invoke is dangerous
why not have that as the title?
Yes, let's change the subject... :) Why wasn't the title P/Invoke is dangerous? As if the poor guy hasn't been flamed enough for pointing out what apparently was obvious to everyone else. :)
-
I just spend most of today trying to figure out why changing movie channels on the kiosk would crash the kiosk application. It didn't do this before, and the change I made was to replace the USB I/O code, that was in C++, with a major rewrite of the USBSharp code. I should have stuck with the C++ code, because it turns out that garbage collection was happening, and my read/write buffers and overlapped structures were moving around! Fixed now (pun intended). And the app is working just fine now. This should be a lesson to everyone. P/Invoke is dangerous because things can look like they're working fine for quite a while. The code examples on the www.pinvoke.net site are wrong. Most of those structs need to be converted to a fixed pointer, especially if you're calling them in a thread and/or asynchronously. Third party libraries that you think have been tested is a bad assumption. In other words, C# can be as, if not more, dangerous than C++ because the interaction between the GC and unsafe P/Invokes can result in non-deterministic crashes. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smiththe problem you are talking about is well known. there is a away solving it using: GCHandle?.Alloc(data, GCHandleType.Pinned); UnmanagedFunction(gcHandle.Value.AddrOfPinnedObject(), (UIntPtr)0, (uint)flags); the first function, tells the gc not to move the data from it's memory block. and the second one send the pointer to data to your unmanaged function. hope that helps, Roey
Don't believe to what you hear on the news...
-
the problem you are talking about is well known. there is a away solving it using: GCHandle?.Alloc(data, GCHandleType.Pinned); UnmanagedFunction(gcHandle.Value.AddrOfPinnedObject(), (UIntPtr)0, (uint)flags); the first function, tells the gc not to move the data from it's memory block. and the second one send the pointer to data to your unmanaged function. hope that helps, Roey
Don't believe to what you hear on the news...
Roey C wrote:
the problem you are talking about is well known.
If it's well known, then why does a prominent site dealing with p/invoke have examples that are flat out wrong? Why does that site not even discuss the issue on the front page? Also, I consider myself very proficient in C# programming. I rarely however need to use p/invoke, except last week, when I was writing some asynchronous read/write functions for USB comm. I totally forgot about the GC! I imagine this happens to other people as well. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Greeeg wrote:
if you're not aware what you're actually programming there.
Quite true. Except that with C++, it's the ethos that you need to be careful about those things. With C#, it looks very easy with PInvoke. There's a lot of blank space on that www.pinvoke.net site to use for a big warning message about structures, GC, and native code. While the language may not be more dangerous than another one, it is the sense of security that C# gives you that lulls you to sleep, thus, IMO, making it more dangerous. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith>> the sense of security that C# gives you that lulls you to sleep, thus, IMO, making it more dangerous << I finally got to the bottom of my inbox, so the late reply. Just in case you haven't chanced across Raymond Chen's classic essays on this. "Cleaner, more elegant, and harder to recognize" "Cleaner, more elegant, and wrong" Google Query I actually remembered: (( CHEN EXCEPTIONS )) The paradigm of cleaning up stuff by sweeping it under a rug, or dumping it into a limitless ocean will be around a while yet...
pg--az