[Mono-list] Stability problem under linux MDV 2008 Cooker
vesely at tana.it
Tue Jul 15 06:44:29 EDT 2008
Petit Eric wrote:
> 2008/7/15 Alessandro Vesely <vesely at tana.it>:
>> Hi Eric,
>>>> However, I found out the hard way that setting G_SLICE=debug-blocks is a
>>>> requirement for no-nonsense debugging with mono.
>>> Hé hé , yu think ishould do that ?
>> If there is a chance that a bug depends on a C written function, absolutely
> Yes i have a managed C program (obexftp), can yu say me if i need to
> compile the C programe with G_SLICE=debug-blocks or in environment or
> when compiling Mono ?
After compiling a managed C (i.e. C#) program one can always make sure
that the compilation is correct by inspecting the assembly. When
running it, [plain, i.e. unmanaged] C code supervises the execution.
In normal C code, releasing a non-allocated memory block results in a
core dump. In mono without debug-blocks, glib blindly accepts any
released memory for later reallocation. That may result in overlapping
variables at some further point during the execution.
> Better , do yu know a link with TODO to do that step by step
running "env G_SLICE=debug-blocks mono my.exe" would suffice for
dismissing an occasional doubt. However, I'd recommend setting "export
G_SLICE=debug-blocks" in a developer's .bashrc. The point is that,
even if memory errors a quite uncommon, one of them is enough for all
bets to be off. That's what managed code is all about.
> it is
> true i really need to see wath happen in the C code, a Valgrind for
> Mono should be very nice
Although mono can be instrumented with Valgrind tools, as mentioned in
http://www.mono-project.com/Debugging, that is likely to cause
performance degradation on a different scale w.r.t. glib internal
checking (noticeable vs. unnoticeable).
More information about the Mono-list