I suddenly started getting this crash in code that was previously working.
I use mono 2.10.8 built from sources in ubuntu 12.04.
Unhandled Exception: System.IO.IOException: Invalid handle to path
"../exe/path/[Unknown]"
at System.IO.FileStream.ReadData (IntPtr handle, System.Byte[] buf,
Int32 o
IMO the current stable release is not suitable for softrealtime
software such as algotrading.
To no fault to C# in general, I find mono to still lack a bit in terms
of stability compared with .Net. (That dreadful native side memory
leak has hurt me quite a bit but is supposedly fixed in master)
I
AFAIK, on windows, they should already have .net installed and as such
most mono applications should work as is if all dependencies are
installed (ie: gtk#/gtk). On linux, if they do not have mono
installed, they will need to install it.
There is also the option of bundling mono, see
http://www.mo
I would advise against a design relying on a crash callback to save data.
I do believe in mono (under linux only?) that you can hook into the
sigkill/sigterm or something similar. However, it probably isn't very
safe to do any amount of processing in those callbacks. I am also
pretty sure that it i
Hi,
Are there any plans to revamp the mono website?
Half the pages/links are broken. Most of the information also appears
to be out of date (except maybe for the download page???).
Xamarin's website seems mostly focused on the mobile side of things.
Maybe the mono non-mobile specific stuff could b
Dispose on async results is mostly to properly clear the
synchronization object (AsyncWaitHandle).
You can call dispose manually after calling EndSend(..) on the
AsyncWaitHandle. I do not believe this is required. It should be
called internally automatically.
This will not however fix the memory l
I wouldn't be surprised. There are other discrepancies with that
class. I've had a bug report for one of them open for 1.5 years now
that hasn't been touched :)
https://bugzilla.xamarin.com/show_bug.cgi?id=2315
https://bugzilla.novell.com/show_bug.cgi?id=666459
I'm not sure how heavily tested/mai
Yes that particular memory leak was present in 2.10.6 for sure and
possibly in 2.10.8 as well. I was told this is claim fixed in master
but haven't tested yet.
Note that this affected all callbacks called from native code. GTK#
was hit pretty bad by this particular leak. If you search the mailing
l
For the 3rd point, see this blog post about an identical problem in
the java implementation of a similar method:
http://googleresearch.blogspot.ca/2006/06/extra-extra-read-all-about-it-nearly.html
On Sun, Apr 1, 2012 at 3:42 PM, Nicholas Frechette wrote:
> In looking at the code in SortedL
Arrays in C#/.net don't allocate new elements for you when you access
an index outside the range of the list.
To add new elements, you must first allocate them and then Add them.
Only once it has been added to the list can you access them.
ie:
var list = new List();
// list is empty here, access w
In looking at the code in SortedList<>, I noticed the following things:
- Clear() causes a new allocation, this is inconsistent with other
generic containers such as List<> and Stack<> that simply perform an
Array.Clear() on their internal array.
- PutImpl(), if Find(key) throws an exception, it
Hi,
Using latest stable mono, I am getting a hang at process exit.
Mono 2.10.6 on ubuntu 11.04, x86
I know for a fact that all my threads have exited except the main
thread. It hangs when returning from main() or in Environment.Exit(0);
if I call it instead.
My shared mutex is created, released an
Works like a charm, thanks!
On Mon, Jan 23, 2012 at 10:09 AM, Nicholas Frechette wrote:
> The behavior is the same with "Global\\" prefix, in that it fails to work.
> I'll be sure to test this and report on the results as soon as I can.
> Thanks
>
> On Sun, Jan 22,
The behavior is the same with "Global\\" prefix, in that it fails to work.
I'll be sure to test this and report on the results as soon as I can.
Thanks
On Sun, Jan 22, 2012 at 7:01 AM, Robert Jordan wrote:
> On 22.01.2012 01:17, Nicholas Frechette wrote:
>
>> Are na
Hi,
I am using mono 2.10.6 under ubuntu 11.04.
Using the following line:
bool lWasMutexCreated;
Mutex lSystemMutex = new Mutex(true, "SystemMutex", out lWasMutexCreated);
The mutex is always acquired and created even if ran from multiple
concurrent processes. I also tried using Mutex(false, "Syst
Do be careful here, you are profiling 2 different scenarios here, one
with 1000 large allocations and one with 100 large allocations.
(an array of value types consists of 2 allocations, one for the array
object, and one for the array values, which is different from a
non-value type array where
s way it's a lot easier to
> diagnose and fix it.
>
> On Sat, Nov 5, 2011 at 5:26 PM, Nicholas Frechette
> wrote:
>>
>> I upgraded to mono 2.10.6, the latest official stable release. I still
>> get a similar result, see below.
>> Are there extra dependenc
mono --gc=sgen
--profile=log:heapshot rovisualizer.exe
On Mon, Oct 31, 2011 at 10:34 AM, Rodrigo Kumpera wrote:
> Please try a more current version of mono such as 2.10.7, there have been
> sgen related fixes since 2.10.2.
>
> On Mon, Oct 31, 2011 at 12:25 PM, Nicholas Freche
Hi,
I'm attempting to track down a memory leak in my application.
I managed to run heapshot a number of times as described in the wiki
page but unfortunately, now my application fails to start every time
with the profiler enabled.
Running a debug build on ubuntu 11.04 + mono 2.10.2 produces:
[mono
Don't forget to register a listener.
System.Diagnostics.Debug.Listeners.Add (new
System.Diagnostics.ConsoleTraceListener());
Cheers,
Nicholas
On Thu, Oct 27, 2011 at 1:33 PM, Steve Lessard wrote:
> Debug builds of my Mono command line application blow right by all
> Debug.Assert statements, even
Hi,
Over the weekend, I noticed the following behavior in my application.
I run the latest mono on top of ubuntu 11.04. (Dual installation)
I have an application A that launches a child application B (both C#,
both mono).
Over STD IN/OUT I transfer to application B the PID of application A.
The id
21 matches
Mail list logo