Hello,
Lately I’ve been investigating a thread pool related hang on arm64
which I tracked it down to some missing memory barriers. It seems that,
although the documentation doesn’t seem to imply memory fences for Interlocked
functions, the thread pool MS code assumes it does.
H
Hi Angelo,
Sounds like a problem with __thread keyword. You should be able to work
around by adding --with-tls=pthread to autogen.
Vlad
From: Mono-devel-list
mailto:mono-devel-list-boun...@lists.dot.net>>
on behalf of Angelo Compagnucci
mailto:angelo.compagnu...@gmail.com>>
Date: Wedne
Hello Ran,
Yes, it's ok to not inline if the compiler has problems with it.
It seems like you have problems with the installation path. The
mono executable has a default path included in itself where it expects to have
been installed, along with the assemblies. (in your
Hello Damien,
Would you be able to build mono from source and reproduce this issue ?
If so, would you like to try a potential fix ?
Thanks,
Vlad
From: Mono-devel-list on behalf of
Damien
Date: Wednesday, 12 October 2016 at 05:53
To: "mono-devel-l...@lists.ximian.com"
Subject: [M
Hello,
I have never cross-compiled mono so I can’t help you there.
This patch [1] should fix the issue. It might be worthwhile to try to
test it out, by compiling from source. Worst case scenario, I know I compiled
mono once on a raspberry and it took around 10 hours.
Vlad
[1]
Hey,
You can call mono_pmip (ip) or mono_print_method_from_ip (ip). For going
deeper, you can either unwind the stack manually looking for the return ip’s
on the stack (which will be similar to 0x40013eca), or call
mono_print_thread_dump (0)
Vlad
From: Mono-devel-list on behalf of M
Ja
Hello David,
Based on the crash site, it would seem that we fail to allocate memory from
the OS, which means we have an OOM situation, which we poorly handle as of
right now.
Could you check whether this is the case, whether there are mono instances
that use more memory than expected.
Hey David,
Would it be possible to repro this issue ? Is this project available
somewhere ?
If it’s not an OOM issue, then additional debugging would be
required. Judging from the stacktrace and source code,
mono_valloc/mono_valloc_aligned fails for whatever reason. Either
Hello Burkhard,
This should be fixed on master by [1].
Is there any reason to use such big nursery sizes ? Is this a
workaround for the stack overflow problem that you submitted earlier ?
You could also consider using the minor=split params, in order to
delay promo
Hello Pablo,
Normally, logging gc activity in real time is done by passing
MONO_LOG_LEVEL=debug and MONO_LOG_MASK=gc. This will output time and memory
information about each collection (minor + major). Another option, if you want
to force your application to log the standard counters (o
Hey Greg,
Aside from the smaller major pause times, the concurrent collector is
typically faster since it’s doing part of its job concurrently with the mutator
(which likely doesn’t use the cpu at 100%). You can see our results on our
benchmarks at [1]. You should be fine with using it
Hey Neale,
How are you getting this crash ? Is it reliable ? Do you know what
commit seems to trigger it ?
You can try running with MONO_GC_DEBUG=nursery-canaries for additional
logging.
Vlad
From: Mono-devel-list on behalf of
Neale Ferguson
Date: Wednesday, 12 July 2017 at 0
The vtable that you are printing is not a vtable (MONO_TYPE_END is 0). You can
see that in major_copy_or_mark_object_with_evacuation ptr and obj are equal
which doesn’t make any sense. Looks like something corrupted the static_data
that the gc scans. Maybe some bug around mono_alloc_special_stat
13 matches
Mail list logo
