I'm ready to pack it in. I've been outsmarted by .NET's garbage collector (A rant, not a question)
-
Update: I killed it. It took me the better part of the day to get it right, and then get advanced with how i was using it, and then integrate that into the projects that go with the library but it's done. Woo. Changed the way I was doing interop somewhat, and it's more complicated now but it still works - although perf could be slightly improved (does two HGlobal allocs where it could in theory use one) I sometimes really can't stand managed code. I've got a MIDI callback I'm using while streaming playback, and it's supposed to notify me when the stream needs more data. It forwards that callback to an event off of my MidiStream object Well, it does that fine, and in the console app i wrote it has no problem feeding more data to the stream each time. I had been working on it all night, and finally thought I had it licked. In a windows forms app on the the other hand, it works for awhile, and then randomly crashes because for some reason the delegate that handles the callback has been garbage collected. I have no idea why. It never should have been and doesn't appear to go out of scope anywhere. Worse, I can't even catch the crash in the debugger - it just exits entirely without so much as an error message I'm at a loss, and I can't release with this stability issue. I miss C and C++ right about now. :(
Real programmers use butterflies
I have the same-ish problem! :~ It's not garbage collected, but disposed. I'm reading some files and then process them. The processing takes a while, around 45 minutes. For the first 30 minutes everything goes well, but after 30 minutes I suddenly get an ObjectDisposedException from my Entity Framework Core context :~ I'm not disposing it and if I did, I'd expect it to blow well before 30 minutes since it's a loop. I'm not aware of any automatic disposes, but 30 minutes sounds like some timeout setting. While writing this I'm thinking of something that could be the problem... :D
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I have the same-ish problem! :~ It's not garbage collected, but disposed. I'm reading some files and then process them. The processing takes a while, around 45 minutes. For the first 30 minutes everything goes well, but after 30 minutes I suddenly get an ObjectDisposedException from my Entity Framework Core context :~ I'm not disposing it and if I did, I'd expect it to blow well before 30 minutes since it's a loop. I'm not aware of any automatic disposes, but 30 minutes sounds like some timeout setting. While writing this I'm thinking of something that could be the problem... :D
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Ouch! Good luck!
Real programmers use butterflies
-
I have the same-ish problem! :~ It's not garbage collected, but disposed. I'm reading some files and then process them. The processing takes a while, around 45 minutes. For the first 30 minutes everything goes well, but after 30 minutes I suddenly get an ObjectDisposedException from my Entity Framework Core context :~ I'm not disposing it and if I did, I'd expect it to blow well before 30 minutes since it's a loop. I'm not aware of any automatic disposes, but 30 minutes sounds like some timeout setting. While writing this I'm thinking of something that could be the problem... :D
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
While writing this I'm thinking of something that could be the problem...
Isn't your rubber duck listening today? :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
<p><a href="https://github.com/GregUtas/robust-services-core/blob/master/README.md">Robust Services Core</a>
<em>The fox knows many things, but the hedgehog knows one big thing.</em></p> -
Sander Rossel wrote:
While writing this I'm thinking of something that could be the problem...
Isn't your rubber duck listening today? :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
A friend once asked the same, but made a typo. He ended up asked about my rubber d... Well, just check the letter next to "U" :laugh: Since then I can't read or hear "rubber duck" without thinking about it :~
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
A friend once asked the same, but made a typo. He ended up asked about my rubber d... Well, just check the letter next to "U" :laugh: Since then I can't read or hear "rubber duck" without thinking about it :~
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
If that's what you do to your rubber duck, no wonder it isn't listening. :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
-
Update: I killed it. It took me the better part of the day to get it right, and then get advanced with how i was using it, and then integrate that into the projects that go with the library but it's done. Woo. Changed the way I was doing interop somewhat, and it's more complicated now but it still works - although perf could be slightly improved (does two HGlobal allocs where it could in theory use one) I sometimes really can't stand managed code. I've got a MIDI callback I'm using while streaming playback, and it's supposed to notify me when the stream needs more data. It forwards that callback to an event off of my MidiStream object Well, it does that fine, and in the console app i wrote it has no problem feeding more data to the stream each time. I had been working on it all night, and finally thought I had it licked. In a windows forms app on the the other hand, it works for awhile, and then randomly crashes because for some reason the delegate that handles the callback has been garbage collected. I have no idea why. It never should have been and doesn't appear to go out of scope anywhere. Worse, I can't even catch the crash in the debugger - it just exits entirely without so much as an error message I'm at a loss, and I can't release with this stability issue. I miss C and C++ right about now. :(
Real programmers use butterflies
We had similar(-ish, but the opposite way round) problems with the JVM's GC, while interfacing it to a COM component we needed to use. Instead of releasing objects before we wanted, the GC was holding onto COM reference wrapper objects long after their lifetime was over (because the objects were small, so the GC wasn't experiencing any memory pressure). This meant that the actual COM objects weren't being released, so were exhausting memory outside of the JVM :-/ GC works fine for memory allocated and used solely within the containing virtual machine environment - anything slightly more complex, and you're dicing with death (of your hopes and dreams).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
We had similar(-ish, but the opposite way round) problems with the JVM's GC, while interfacing it to a COM component we needed to use. Instead of releasing objects before we wanted, the GC was holding onto COM reference wrapper objects long after their lifetime was over (because the objects were small, so the GC wasn't experiencing any memory pressure). This meant that the actual COM objects weren't being released, so were exhausting memory outside of the JVM :-/ GC works fine for memory allocated and used solely within the containing virtual machine environment - anything slightly more complex, and you're dicing with death (of your hopes and dreams).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
I've run into the same problem as you before. The solution is to marshal the objects as IntPtrs, and manually release them when you're done, if I recall correctly. That way you control the lifetime explicitly. It makes things easier. I solved the problem with my MIDI code in the OP, and then improved on it several times :-D to make it more efficient and easier to read the code. Now in my entire streaming codebase i only have one win32 global heap allocation that happens once you open a device, until you close it. I've taken to marshalling all structs as
ref (struct)except for a very complicated vector of variable length structs which I have to mangle manually. So it's golden now, and even mostly easier to read and maintain when I'm done. Cool beans.Real programmers use butterflies
-
I've run into the same problem as you before. The solution is to marshal the objects as IntPtrs, and manually release them when you're done, if I recall correctly. That way you control the lifetime explicitly. It makes things easier. I solved the problem with my MIDI code in the OP, and then improved on it several times :-D to make it more efficient and easier to read the code. Now in my entire streaming codebase i only have one win32 global heap allocation that happens once you open a device, until you close it. I've taken to marshalling all structs as
ref (struct)except for a very complicated vector of variable length structs which I have to mangle manually. So it's golden now, and even mostly easier to read and maintain when I'm done. Cool beans.Real programmers use butterflies
I did it slightly differently - I wrote a class to implement something like an [Objective-C autorelease pool](https://www.informit.com/articles/article.aspx?p=1806938&seqNum=7), which our COM object wrappers added themselves to automatically. The pool was released in a [`finally` block](https://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html) & that would release all the COM objects that had been allocated and finished - something like this... ```java AutoReleasePool.createPool(); // Push a new pool onto the stack of pools try { ... Do stuff ... } finally { AutoReleasePool.releasePool(); // Pop the top pool in the stack , releasing all the objects in it } ```
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
I did it slightly differently - I wrote a class to implement something like an [Objective-C autorelease pool](https://www.informit.com/articles/article.aspx?p=1806938&seqNum=7), which our COM object wrappers added themselves to automatically. The pool was released in a [`finally` block](https://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html) & that would release all the COM objects that had been allocated and finished - something like this... ```java AutoReleasePool.createPool(); // Push a new pool onto the stack of pools try { ... Do stuff ... } finally { AutoReleasePool.releasePool(); // Pop the top pool in the stack , releasing all the objects in it } ```
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
that seems even more complicated, but you do you. I don't know the whole picture anyway so I'm just talking smack here. :laugh:
Real programmers use butterflies
-
that seems even more complicated, but you do you. I don't know the whole picture anyway so I'm just talking smack here. :laugh:
Real programmers use butterflies
Yeah, completely different scenario - I was dealing with potentially hundreds of thousands of COM objects that needed to be created from Java, so couldn't go with a single C memory reference.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
