This crash is either a bug on glibc malloc, which I find to be the less likely, or a bug on mono or your app.
Run it under the many malloc debugging tools that malloc(3) has or with a tool such as valgrind - it will very easily spot a memory overrun in mono/your app. On Fri, Aug 24, 2012 at 11:12 AM, Greg Young <gregoryyou...@gmail.com>wrote: > Will take a look. Not sure what it may not be liking. Code is very basic. > Literally allocates 16mb chunk then frees it (each object has one) code > works fine in windows with same calls. Will debug it on Sunday. > > > On Friday, August 24, 2012, Jonathan Pryor wrote: > >> On Aug 23, 2012, at 2:35 AM, Greg Young <gregoryyou...@gmail.com> wrote: >> > We are allocating and releasing unmanaged memory with >> marshal.allochglobal. In mono we are getting the following failure (no >> failures under clr). >> > >> > Any ideas? >> >> That's not a mono error, that's a glibc assert (and thus cannot become an >> exception, ever): >> >> > part from team city logs: >> > [20:55:52][Step 2/2] mono: malloc.c:2451: sYSMALLOc: Assertion >> `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - >> __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || >> ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof >> (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * >> (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned >> long)old_end & pagemask) == 0)' failed. >> >> Very probably coming from: >> >> >> http://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=0f1796c9134ffef289ec31fb1cd538f3a9490ae1;hb=HEAD#l2361 >> /* >> If not the first time through, we require old_size to be >> at least MINSIZE and to have prev_inuse set. >> */ >> >> assert((old_top == initial_top(av) && old_size == 0) || >> ((unsigned long) (old_size) >= MINSIZE && >> prev_inuse(old_top) && >> ((unsigned long)old_end & pagemask) == 0)); >> >> The line number is different, but it's the same file and the assert looks >> close enough (considering macro expansion, etc.). >> >> In short, malloc(3) doesn't like you or something that you're doing. I >> would suggest setting the MALLOC_CHECK_ environment variable (see the >> malloc(3) man page), and/or "porting" your malloc use to C to verify that >> it also crashes there. >> >> - Jon >> >> > > -- > Le doute n'est pas une condition agréable, mais la certitude est absurde. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list