I don’t think the actual bug has been reported twice, just Alexander already
picked it up (maybe it’s affecting him, too). My colleague opened the bug
report because we updated the mono framework we are certifying against to
3.12.1 and this issue appeared. He said we didn’t have issues with
Found the issue and created PR 1839: https://github.com/mono/mono/pull/1839
Please take a look and let me know if you have any concerns with the fix.
Thanks,
Dave
On May 28, 2015, at 3:51 PM, David Curylo cury...@asme.org wrote:
I’m researching an issue reported by a colleague of mine. The
Hello,
There is already a similar pull request.
The issue is that returning NULL there has a slightly different meaning.
So the complete fix is to restructure some of the code.
https://github.com/mono/mono/pull/1817
Miguel
On Thu, May 28, 2015 at 4:25 PM, David Curylo cury...@asme.org wrote:
Cool. I didn’t see any traffic on the bug report so didn’t know you were
already addressing this. Anything I can do to help move the other PR forward?
On May 28, 2015, at 4:29 PM, Miguel de Icaza mig...@xamarin.com wrote:
Hello,
There is already a similar pull request.
The issue is
I'm not keen on introducing yield calls all over the place in the runtime
to work around bad test-environment combinations.
Adding them to the test suite it fine though.
Maybe the 200ms timeout is too low to deal with overloaded systems and must
be increased. The goal is to
detect bugs in the
Good catch!
That's indeed a bug.
On Thu, May 28, 2015 at 2:35 PM, Neale Ferguson ne...@sinenomine.net
wrote:
Hi,
When a hash table exceeds a threshold a rehash operation is triggered. At
the moment the new table is allocated and its address placed in the table
field of the structure. The
I’m researching an issue reported by a colleague of mine. The error is rather
serious as the use of a bad type name causes a native SIGSEGV and kills the
runtime, when it really should just return a null because it can’t find the
type. This code reproduces the issue:
I tried to compile from the tarball (mono-3.2.0.tar.bz2) and got the same
results on OS-X. Is this a tool dependency related error?
Is there at list of tool versions that are required to build 3.2.x on OS-X?
The OS-X Compile page lists autoconf/automake/libtool/m4 with versions. Are
there
Hi,
When a hash table exceeds a threshold a rehash operation is triggered. At
the moment the new table is allocated and its address placed in the table
field of the structure. The do_rehash also then copies the entries from
the old table to the new. However, if there is another thread active that
The problem is confirmed Xamarin.Mac specific. And steps to reproduce are here:
http://forums.xamarin.com/discussion/42318/sslstream-on-mac
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
I;m building mono on android, and while I've finally managed to get make to
finish without errors, 'make check' always fails at the same point...no matter
what ./configure I use:
make[3]: Entering directory `/bld/mono/mono-4.0.0/mono/mini'
make check-local
make[4]: Entering directory
Recently, I'm encountering a problem where Mozroots is throwing
NullReferenceException. I am working on a reproducible example, but until then,
I'd like to revisit this issue:
First, here is reproduction code that shows the mac client requires mozroots to
be run. This code throws exception on
12 matches
Mail list logo
