st-
> > boun...@lists.ximian.com] On Behalf Of River Satya
> >
> > We have a c# binary running under mono on Ubuntu 14.04 which hangs
> > periodically.
> >
> > When it hangs, SIGQUIT does not generate a thread dump, and all threads,
> > including one heartbeat
ps a new version (4.0.4) just got pushed today, which is great, but it
meant out deployment broke again :( ). I'm really happy to see new versions
getting pushed, but we need to be able to make conscious decisions about
if/when to upgrade.
On 13 November 2015 at 18:16, River Satya <river
Ooops. 4.5.1 is the new version.
On 13 November 2015 at 18:04, River Satya <river.sa...@gmail.com> wrote:
> ps a new version (4.0.4) just got pushed today, which is great, but it
> meant out deployment broke again :( ). I'm really happy to see new versions
> getting push
Hi mono folks!
We have a c# binary running under mono on Ubuntu 14.04 which hangs
periodically.
When it hangs, SIGQUIT does not generate a thread dump, and all threads,
including one heartbeat thread that does very little but pulse the logs
once a minute, seem to stop.
I've tried building with
Hi mono folks!
We've been using the repo at download.mono-project.com to pull our mono
binaries, following the instructions at
http://www.mono-project.com/docs/getting-started/install/linux/. All seemed
to be working fine, and I'd fixed the version for our deployment at
4.0.3.20-0xamarin1.
At
Thanks Timotheus,
We're using Ubuntu 14.04.3 LTS.
I don't know that the equivalent of versionlock would help, since the issue
isn't of packages getting upgraded, but that we want deployment to be
stable.
ie when bringing up a new VM instance, I want to make sure that it has the
same version of
Thanks Timotheus, but the issue is not that we're getting unrequested
upgrades; Ubuntu does not do /that/ fortunately!!
The issue is that when we deploy a new server, I want to know what version
it is getting. I want the new servers to have the same mono version as the
existing ones.
Hope this
Thanks Timotheus,
To be honest, I'd probably just deploy the pkg file from our own servers
rather than create a repository just for one package. However, this seems
like a bug to me. Why would the mono package maintainers not want to retain
old binaries? I can't imagine disk space is the issue,
Hi mono list,
I find that when I catch exceptions from XML deserialisation code, they
don't contain the stack trace of my calling code, so it's difficult to
determine exactly what's happened.
Is this a known issue? Is there a better workaround than catching and
re-throwing the exception?
A piece of code I inherited recently uses separate AppDomains to
parallelise calls to a SOAP web service.
We were seeing an intermittent bug in Mono which caused crashes when the
AppDomains were unloaded, and since AppDomains seemed like overkill for the
purposes of multithreading calls to the
for the
single AppDomain case.
Does anyone have any idea why this would be happening? Is this a bug in the
Mono SOAP stack?
Thanks,
River
On 4 January 2016 at 16:47, River Satya <river.sa...@gmail.com> wrote:
> A piece of code I inherited recently uses separate AppDomains to
> paral
ut kernel
> versions. We still see this bug using 3.13 or 3.19 kernels.
>
> Matt
>
>
> On Fri, Nov 27, 2015 at 5:31 AM, River Satya <river.sa...@gmail.com>
> wrote:
>
>>
>> Stack trace flavour 3:
>>
>> --
>> :Stacktrace:
>> -
>
Any idea if it's been fixed again in 4.2?
On 27 November 2015 at 23:26, River Satya <river.sa...@gmail.com> wrote:
> Ah, of course, thank-you!! We had seen this in the past but not for a
> while now. It resurfaced when we moved to a new instance, which still had
> the old kern
ny idea what I'm doing wrong?
Thanks,
River
On 24 November 2015 at 08:58, River Satya <river.sa...@gmail.com> wrote:
> Hi Alexander!
>
> Thanks for the detailed reply. The new format looks good to me. I think it
> will work really well for our purposes.
>
> Cheers,
>
&
t;
This seems to have worked, though I'm not sure why.
Thanks,
River
On 25 November 2015 at 13:55, River Satya <river.sa...@gmail.com> wrote:
> I just tried adding:
>
> deb http://download.mono-project.com/repo/debian wheezy/snapshots/4.0.5.1
>> main
>>
>
I've had two recent messages to this list bounce for being "too long". The
first was a message that contained a few (non-enormous) stack traces for
debugging purposes, and the second was a short message which contained the
quoted responses of the thread, as is the norm for most email clients.
properly?
Thanks,
River
On 27 November 2015 at 23:32, River Satya <river.sa...@gmail.com> wrote:
> Any idea if it's been fixed again in 4.2?
>
> On 27 November 2015 at 23:26, River Satya <river.sa...@gmail.com> wrote:
>
>> Ah, of course, thank-you!
Hi mono list,
We see a lot of segfaults (~10 / day) in our program running on Ubuntu
Wheezy. I was hoping that upgrading to mono 4.2 would resolve it, but we're
still seeing them.
The stack traces take a few different forms, so it's possible that they're
actually separate issues.
We mostly see
75f8]
- /usr/bin/mono() [0x623b66]
- /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7fb78e494182]
- /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fb78e1c147d]
-
On 27 November 2015 at 20:31, River Satya <river.sa...@gmail.com> wrote:
> Hi mono list,
>
> W
your feedback on this, does the above work for your
> use case?
>
> Thanks!
>
> - Alex
>
>
> 2015-11-13 11:21 GMT+01:00 River Satya <[hidden email]
> <http:///user/SendEmail.jtp?type=node=4666967=0>>:
>
>> Thanks Timotheus, but the issue is not that
20 matches
Mail list logo
