The function ves_icall_System_IO_FSW_SupportsFSW inside
mono/metadata/filewatcher.c appears to be wrong.
The function incorrectly calls mono_dl_build_path with a full library name
as an argument and thus gets back an incorrectly library name
(libfam.so.soinstead of
libfam.so) so neither gamin
I've upgraded mono to the latest stable version
]# mono --version
Mono JIT compiler version 1.2.4 (tarball)
but I've the same problem.
I've done some log and I noticed that, for system assemblies it
search in the gac
Mono-INFO: Assembly Loader probing location:
On 07/07/07 Lionel Cuir wrote:
I've looked at the Mono roadmap which gives no information on the
release date for the next release (1.2.5?). Would it be possible, at
this stage, to have some indications, even rough ones?
We'll aim for a release in 3-4 weeks.
lupus
--
http://bugzilla.ximian.com/show_bug.cgi?id=82046
Fixed runtime reporting WARNING **: Cannot load type errors when trying
to call GetCustomAttributes on a property with an attribute of the form:
[MyAttribute(typeof(GenericTypeCustomType))]
public class MyClass
{
}
Occurs when the program
On 07/09/07 Thong Nguyen wrote:
The function incorrectly calls mono_dl_build_path with a full library name
as an argument and thus gets back an incorrectly library name
(libfam.so.soinstead of
libfam.so) so neither gamin nor fam gets used and mono falls back to the
polling watcher.
Thanks,
On 07/06/07 Rodrigo Kumpera wrote:
The attached patch fixes #82022. The fix is quite simple, it just checks if
the enum field is null and abort the loading process. But there are two
issues with this patch, first it could return a more informative message
about the problem and I'm not sure if
Hi,
I was working on sending mail with authentication and debugging an
authentication problem I noticed that in
System.Web.Mail.SmtpClient.StartSend there's a couple of lines with
this statement:
username != null password != null authenticate != 1
Checking M$ documentation
I think it's a mistake cause for test I created a link
Consts.AssemblyMono_Security.dll pointing to Mono.Security.dll into
gac and it runs well but maybe it's only an hack and I'm not
understanding what is going on :-)
At 10.59 09/07/2007, you wrote:
I've upgraded mono to the latest stable
On 07/09/07 APS wrote:
I checked source code, this is the incriminated piece of code:
Assembly a;
try {
a = Assembly.Load(Consts.AssemblyMono_Security);
Thanks, this clearly shouldn't be a string. fixed in svn.
lupus
--
Hi there
When I send a thread an interrupt, I seem to not get an
ThreadInterruptException, but rather a
System.Threading.SynchronizationLockException: Object is not synchronized
at System.Threading.Monitor.Wait (System.Object obj, Int32
millisecondsTimeout) [0x0004d]
in
At the suggestion of Paolo, I ran:
strings /usr/lib/libMonoPosixHelper.so |grep overflow
against the file that shipped in the 1.2.3.1 rpm, with no results.
Jonathan, could you try running this?
Also, could there possibly be another libMonoPosixHelper.so that is
getting called?
Wade
On Wed,
I have no results too when running the given command. I found another
libMonoPosixHelper.so on the machine although they give no results too when
using the strings command.
I tried running the following command instead grep overflow
/usr/lib/libMonoPosixHelper.so and it returned no result too.
I looked at the build logs, and DEBUG is not defined anywhere. (I also checked
config.h)
Here's the exact make output for trees.c:
if /bin/sh ../libtool --tag=CC --mode=compile /usr/bin/gcc -DHAVE_CONFIG_H -I.
-I. -I.. -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I..
run the program with first setting:
MONO_LOG_LEVEL=debug
That should give sufficient output as to what file is being used.
Wade
On Mon, 2007-07-09 at 13:34 -0400, Jonathan Gagnon wrote:
I have no results too when running the given command. I found another
libMonoPosixHelper.so on the
14 matches
Mail list logo
