[Mono-list] GLib Critical Error at attemting to embed Mono (and other minor troubles).
Lucyberad
Lucyberad at gmail.com
Mon Aug 24 07:04:18 EDT 2009
I've made some further test. This time on Unix system (fresh install with
mono --version producing 2.4.2.3).
After checking my helloworld.exe is launching well (which is the case),
updating all path: mono_set_dirs("/usr/etc", "usr/lib") and my const char*
file.
I launch it and it produce the following output:
lucyberad at VMBuntu:~/Desktop/mono test$ g++ main.cpp `pkg-config --cflags
--libs mono`
lucyberad at VMBuntu:~/Desktop/mono test$ ./a.out
(process:20855): GLib-CRITICAL **: g_path_is_absolute: assertion `file_name
!= NULL' failed
(process:20855): GLib-CRITICAL **: g_path_get_basename: assertion `file_name
!= NULL' failed
Stacktrace:
Native stacktrace:
/usr/lib/libmono.so.0 [0xb7dfd162]
/usr/lib/libmono.so.0 [0xb7e1db03]
[0xb800a410]
/usr/lib/libmono.so.0(mono_jit_exec+0x62) [0xb7de8882]
./a.out(main+0xe6) [0x8048bb6]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7a37775]
./a.out [0x80489e1]
Debug info from gdb:
[Thread debugging using libthread_db enabled]
[New Thread 0xb79ed6f0 (LWP 20855)]
[New Thread 0xb7357b90 (LWP 20857)]
[New Thread 0xb737bb90 (LWP 20856)]
0xb800a422 in __kernel_vsyscall ()
3 Thread 0xb737bb90 (LWP 20856) 0xb800a422 in __kernel_vsyscall ()
2 Thread 0xb7357b90 (LWP 20857) 0xb800a422 in __kernel_vsyscall ()
1 Thread 0xb79ed6f0 (LWP 20855) 0xb800a422 in __kernel_vsyscall ()
Thread 3 (Thread 0xb737bb90 (LWP 20856)):
#0 0xb800a422 in __kernel_vsyscall ()
#1 0xb7d7d8f6 in nanosleep () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7ef2ce8 in ?? () from /usr/lib/libmono.so.0
#3 0xb7d764ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#4 0xb7b0549e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 2 (Thread 0xb7357b90 (LWP 20857)):
#0 0xb800a422 in __kernel_vsyscall ()
#1 0xb7d7a0e5 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7ef6017 in ?? () from /usr/lib/libmono.so.0
#3 0xb7ef8c04 in ?? () from /usr/lib/libmono.so.0
#4 0xb7ef8c6c in ?? () from /usr/lib/libmono.so.0
#5 0xb7f13512 in ?? () from /usr/lib/libmono.so.0
#6 0xb7e72e3e in ?? () from /usr/lib/libmono.so.0
#7 0xb7e97ebf in ?? () from /usr/lib/libmono.so.0
#8 0xb7f0edc6 in ?? () from /usr/lib/libmono.so.0
#9 0xb7f33007 in ?? () from /usr/lib/libmono.so.0
#10 0xb7d764ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#11 0xb7b0549e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 1 (Thread 0xb79ed6f0 (LWP 20855)):
#0 0xb800a422 in __kernel_vsyscall ()
#1 0xb7d7d0fb in read () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7dfd29e in ?? () from /usr/lib/libmono.so.0
#3 0xb7e1db03 in ?? () from /usr/lib/libmono.so.0
#4 <signal handler called>
#5 0xb7e564e3 in mono_runtime_run_main () from /usr/lib/libmono.so.0
#6 0xb7de8882 in mono_jit_exec () from /usr/lib/libmono.so.0
#7 0x08048bb6 in main ()
#0 0xb800a422 in __kernel_vsyscall ()
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Abandon
lucyberad at VMBuntu:~/Desktop/mono test$
I hope this will help.
Lucyberad
Lucyberad wrote:
>
> Hi,
>
>
> Robert Jordan wrote:
>>
>> Lucyberad wrote:
>>> I got an assertion error on mono_jit_exec. The console output an error
>>> from
>>> Glib:
>>> http://www.nabble.com/file/p25093790/visual_mono_glib_asssertion_error.png
>>> (right-click: show image to view it fullsize)
>>
>> Are you calling mono_set_dirs ()? If yes, post the code.
>>
>>> More than this errors, I had many troubles at embeding Mono.
>>> The first is about linking to a library:
>>> mono_domain_assembly_open(domain,
>>> file) don't work if the mscorlib.dll library file is not located to
>>> "../lib/mono/1.0/mscorlib.dll" (relative to the main exe). I made a copy
>>> of
>>> this dll to the path but I don't know how to put it on the same folder
>>> than
>>> the exe (or use this dll as static). In fact, I don't really know what
>>> to do
>>> with this dll. If my memory is good, it's the main dll of .NET langage.
>>
>> The assembly must be placed in $libdir/mono/x.x/, where $libdir
>> is the directory you've passed to mono_set_dirs ().
>>
>
> No, I don't call mono_set_dirs(). The result console in screenshot is the
> code you see in VC behind (with mono_set_dirs commented).
> I've un-comment mono_set_dirs to this:
> mono_set_dirs("C:\\Program Files (x86)\\Mono-2.4.2.3\\lib\\", "C:\\Program
> Files (x86)\\Mono-2.4.2.3\\etc\\");
> and it don't works better than before (always glib error) but this time I
> don't need to care about mscorlib.dll. If I understand well, it tells
> where to find mscorlib.dll. So, to release the app I need to move each
> asked dll to a subfolder (and keep directory hierarchy) with
> mono_set_dirs("./lib", "./etc") where '.' is in fact the current folder
> (working directory)?
>
>
>
> Robert Jordan wrote:
>>
>>> The second is about understanding why compiler can't recognize
>>> mono_config_parse() but I finally found it in mono-config.h (which is
>>> not
>>> shown
>>> http://anonsvn.mono-project.com/viewvc/trunk/mono/samples/embed/teste.c?&view=markup
>>> in sample ).
>>
>> So this is solved.
>>
>
> It is, but I mention it to say that the sample is not up-to-date and
> compilable.
>
>
>
> Robert Jordan wrote:
>>
>>> The third is why is mscorlib.dll in "mono/1.0/". Does it means I try to
>>> embed Mono1.0 instead of 2.0 (or 2.4)?
>>
>> Yes. This is because you've compiled the assembly with mcs. If you
>> want .NET 2.0, you must use gmcs.
>>
>
> Ok, I didn't know. (for people looking for more information, I found this
> wiki thread talking about it: http://www.mono-project.com/CSharp_Compiler
> http://www.mono-project.com/CSharp_Compiler ).
> I've compiled with gmcs (because I plan to use C# 3.0 or 3.5
> implementation) and GLib error is still here.
>
>
> Robert Jordan wrote:
>>
>>> The last is why the path of my file must be absolute and not relative?
>>> If I
>>> do relative, the assembly var is = 0. Can't I just call with
>>> "helloworld.exe" (or "./helloworld.exe")?
>>
>> I don't understand this sentence. You seem to be speaking about
>> some source code you didn't share with us.
>>
>> Robert
>>
>
> Sorry, i'm not an english native-speaker.
> So, I mean why Mono don't handle relative path? As you see on the
> screenshot
> (http://www.nabble.com/file/p25093790/visual_mono_glib_asssertion_error.png),
> I give the path of my file in absolute way:
> const char* file = "C:\\Users\\Lucyberad\\Documents\\Visual Studio
> 2008\\OtherProject\\SandboxMono\\Builds\\Debug\\helloworld.exe";
> I want to do:
> const char* file = "helloworld.exe"; or const char* file =
> "./helloworld.exe";
> This allow me to make the program runnable on an other computer than mine.
> I'll make a "trick" which transform a relative path into an absolute path
> but I'm suprised that there is no relative path allowed as input in Mono
> Path (mono_set_dirs() or mono_domain_assembly_open()).
> I'm not sure if it's more about C++ than Mono.
> Probably it will no longer be a problem for me because I plan to use AOT
> and use Bundles (I don't know yet exactly how it works, but I actually
> focus on making a simple helloworld working on embed app).
>
> -----------------------
>
> More info on GLib error (maybe it will help): The only link I made is to
> mono.lib, created from mono.dll with mono.def file. I've made a copy of
> mono.dll, libgthread-2.0-0.dll & libglib-2.0-0.dll into the working
> directory.
>
> I attached to this thread the
> http://www.nabble.com/file/p25108056/main.cpp main.cpp file.
>
> Thanks for help,
> Lucyberad.
>
--
View this message in context: http://www.nabble.com/GLib-Critical-Error-at-attemting-to-embed-Mono-%28and-other-minor-troubles%29.-tp25093790p25114083.html
Sent from the Mono - General mailing list archive at Nabble.com.
More information about the Mono-list
mailing list