[Mono-list] Stability problem under linux MDV 2008 Cooker

[Alessandro Vesely]

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.
> 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).

Ciao
Ale