Petit Eric wrote: > 2008/7/15 Alessandro Vesely <[EMAIL PROTECTED]>: >> 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 _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
