Paolo, Sorry for the monologue...
>> If configured [...] --with- >> gc=included I get a segmentation fault: >> >> GC Warning: Large stack limit(10485760): only scanning 8 MB >> Segmentierungsfehler - Speicherabbild 'core' geschrieben >> >> gdb refers to libgc's GC_SysVGetDataStart > I added some debug output to GC_SysVGetDataStart and it appears to > return okay, that is it returns 0x64d000 (which it gets by calling > GC_find_limit(0x66a778, FALSE). I tried patching GC_find_limit to > match CVS (a boundary check was added) to no avail, also adding some > new assertions for the signal handling but they do not fail. > > Maybe gdb is simply confused because of the SIGSEGV signal handler in > GC_SysVGetDataStart and does not show where the actual segfault > happens? Are there any options or commands that might help? I've discovered the "continue" command in gdb, which confirmed that the reported SIGSEGV is the normal operation of GC_SysVGetDataStart. The problem instead turned out to be GC_pthread_detach: Mono appears to use the Boehm GC 6.6, and in 6.8 this function has apparently been removed for Solaris. If I comment it out, Mono compiles fine and does not segfault! I also found out where the GC warning is originating from: libgc/ solaris_threads.c defines MAX_ORIG_STACK_SIZE as 8 MB and uses this as an upper limit, emitting the warning if above. The code even documents that on Solaris/Intel this value is larger but a) only calculates this differing limit for I386 (not X86_64) and b) the calculation appears to be broken on both platforms under certain circumstances. It adds USRSTACK to the 8 MB but for I386 this does not fix it on this machine, and on X86_64 USRSTACK seems to be defined in terms of the undefined USERLIMIT which I haven't been able to locate. So as a personal workaround I have simply removed the limit on the value for now. Would it make sense to update Mono's Boehm GC to 6.8, fixing the segfault? Or should we limit the changes to the Boehm GC in light of the new SGen-GC you're working on? Andreas _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
