[Mono-dev] Something bad happened between 2.6.1 and 2.6.3?
Ben Clewett
Ben.Clewett at roadtech.co.uk
Tue May 4 09:53:03 EDT 2010
I have found a work-around for this bug.
Remove directives such as this from the Apache mono.conf:
MonoMaxMemory tgstats_webservice 134217728
(It is large, but I have need of lots of memory.)
Now Mono starts up correctly.
This bug also seems to appear in version 2.6.4. Although I note
mod_mono is still only available in 2.6.3 so I can't further test.
Regards,
Ben
Ben Clewett wrote:
>
>
> Dear List,
>
> Been using Mono through Mod-mono and stand-alone programs for years with
> great success, great product.
>
> Had an issue with 2.6.1 where a file handler in VB.NET was returning
> null, so upgraded to 2.6.3, and now nothing through Mod-Mono is working,
> and getting things like this in Apache error.log.
>
> Please, am I doing something wrong??
>
> Regards,
>
> Ben.
>
>
>
> =================================================================
> Got a SIGABRT while executing native code. This usually indicates
> a fatal error in the mono runtime or one of the native libraries
> used by your application.
> =================================================================
>
> /bin/sh: error while loading shared libraries: libdl.so.2: failed to map
> segment from shared object: Cannot allocate memory
> [Fri Mar 26 17:02:31 2010] [error] Failed to connect to mod-mono-server
> after several attempts to spawn the process.
>
> ***MEMORY-ERROR***: /usr/lib/mono/2.0/mod-mono-server2.exe[27013]:
> GSlice: failed to allocate 1008 bytes (alignment: 1024): Cannot allocate
> memory
>
> Stacktrace:
>
>
> Native stacktrace:
>
> /usr/bin/mono [0x48c250]
> /lib64/libpthread.so.0 [0x7f78c06feb30]
> /lib64/libc.so.6(gsignal+0x35) [0x7f78c01735c5]
> /lib64/libc.so.6(abort+0x183) [0x7f78c0174bb3]
> /usr/lib64/libglib-2.0.so.0 [0x7f78c0f97b3a]
> /usr/lib64/libglib-2.0.so.0 [0x7f78c0f988e5]
> /usr/lib64/libglib-2.0.so.0(g_slice_alloc+0x7c7) [0x7f78c0f99927]
> /usr/lib64/libglib-2.0.so.0(g_hash_table_new_full+0x33)
> [0x7f78c0f6e273]
> /usr/bin/mono [0x521694]
> /usr/bin/mono [0x52facb]
> /usr/bin/mono [0x51ec3f]
> /usr/bin/mono [0x5b87f8]
> /usr/bin/mono [0x51edea]
> /usr/bin/mono [0x51a9f8]
> /usr/bin/mono [0x58f60b]
> /usr/bin/mono [0x5bca42]
> /lib64/libpthread.so.0 [0x7f78c06f7040]
> /lib64/libc.so.6(clone+0x6d) [0x7f78c021408d]
>
> Debug info from gdb:
>
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7f78c1601730 (LWP 27013)]
> [New Thread 0x41d99950 (LWP 27018)]
> [New Thread 0x4070a950 (LWP 27017)]
> [New Thread 0x4362c950 (LWP 27016)]
> [New Thread 0x42e2b950 (LWP 27015)]
> [New Thread 0x4262a950 (LWP 27014)]
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> 0x00007f78c06fd4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
> 6 Thread 0x4262a950 (LWP 27014) 0x00007f78c06fadd9 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 5 Thread 0x42e2b950 (LWP 27015) 0x00007f78c06fadd9 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 4 Thread 0x4362c950 (LWP 27016) 0x00007f78c06fadd9 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 3 Thread 0x4070a950 (LWP 27017) 0x00007f78c06fe251 in nanosleep ()
> from /lib64/libpthread.so.0
> 2 Thread 0x41d99950 (LWP 27018) 0x00007f78c06fd90b in read ()
> from /lib64/libpthread.so.0
> 1 Thread 0x7f78c1601730 (LWP 27013) 0x00007f78c06fd4c4 in
> __lll_lock_wait ()
> from /lib64/libpthread.so.0
>
> Thread 6 (Thread 0x4262a950 (LWP 27014)):
> #0 0x00007f78c06fadd9 in pthread_cond_wait@@GLIBC_2.3.2 ()
> from /lib64/libpthread.so.0
> #1 0x00000000005bb4e3 in ?? ()
> #2 0x00000000005c2465 in ?? ()
> #3 0x00000000005bc32c in ?? ()
> #4 0x00007f78c06f7040 in start_thread () from /lib64/libpthread.so.0
> #5 0x00007f78c021408d in clone () from /lib64/libc.so.6
> #6 0x0000000000000000 in ?? ()
>
> Thread 5 (Thread 0x42e2b950 (LWP 27015)):
> #0 0x00007f78c06fadd9 in pthread_cond_wait@@GLIBC_2.3.2 ()
> from /lib64/libpthread.so.0
> #1 0x00000000005bb4e3 in ?? ()
> #2 0x00000000005c2465 in ?? ()
> #3 0x00000000005bc32c in ?? ()
> #4 0x00007f78c06f7040 in start_thread () from /lib64/libpthread.so.0
> #5 0x00007f78c021408d in clone () from /lib64/libc.so.6
> #6 0x0000000000000000 in ?? ()
>
> Thread 4 (Thread 0x4362c950 (LWP 27016)):
> #0 0x00007f78c06fadd9 in pthread_cond_wait@@GLIBC_2.3.2 ()
> from /lib64/libpthread.so.0
> #1 0x00000000005bb4e3 in ?? ()
> #2 0x00000000005c2465 in ?? ()
> #3 0x00000000005bc32c in ?? ()
> #4 0x00007f78c06f7040 in start_thread () from /lib64/libpthread.so.0
> #5 0x00007f78c021408d in clone () from /lib64/libc.so.6
> #6 0x0000000000000000 in ?? ()
>
> Thread 3 (Thread 0x4070a950 (LWP 27017)):
> #0 0x00007f78c06fe251 in nanosleep () from /lib64/libpthread.so.0
> #1 0x0000000000596f52 in ?? ()
> #2 0x00007f78c06f7040 in start_thread () from /lib64/libpthread.so.0
> #3 0x00007f78c021408d in clone () from /lib64/libc.so.6
> #4 0x0000000000000000 in ?? ()
>
> Thread 2 (Thread 0x41d99950 (LWP 27018)):
> #0 0x00007f78c06fd90b in read () from /lib64/libpthread.so.0
> #1 0x000000000048c3dd in ?? ()
> #2 <signal handler called>
> #3 0x00007f78c01735c5 in raise () from /lib64/libc.so.6
> #4 0x00007f78c0174bb3 in abort () from /lib64/libc.so.6
> #5 0x00007f78c0f97b3a in ?? () from /usr/lib64/libglib-2.0.so.0
> #6 0x00007f78c0f988e5 in ?? () from /usr/lib64/libglib-2.0.so.0
> #7 0x00007f78c0f99927 in g_slice_alloc () from /usr/lib64/libglib-2.0.so.0
> #8 0x00007f78c0f6e273 in g_hash_table_new_full ()
> from /usr/lib64/libglib-2.0.so.0
> #9 0x0000000000521694 in ?? ()
> #10 0x000000000052facb in ?? ()
> #11 0x000000000051ec3f in ?? ()
> #12 0x00000000005b87f8 in ?? ()
> #13 0x000000000051edea in ?? ()
> #14 0x000000000051a9f8 in ?? ()
> #15 0x000000000058f60b in ?? ()
> #16 0x00000000005bca42 in ?? ()
> #17 0x00007f78c06f7040 in start_thread () from /lib64/libpthread.so.0
> #18 0x00007f78c021408d in clone () from /lib64/libc.so.6
> #19 0x0000000000000000 in ?? ()
>
> Thread 1 (Thread 0x7f78c1601730 (LWP 27013)):
> #0 0x00007f78c06fd4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
> #1 0x00007f78c06f8cbb in _L_lock_312 () from /lib64/libpthread.so.0
> #2 0x00007f78c06f86e1 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #3 0x000000000052d0c6 in ?? ()
> #4 0x000000000052fa7b in ?? ()
> #5 0x00000000004200b0 in ?? ()
> #6 0x000000000057503c in mono_runtime_invoke ()
> #7 0x000000000057a2de in mono_runtime_invoke_array ()
> #8 0x0000000000506127 in ?? ()
> #9 0x00000000406fd418 in ?? ()
> #10 0x00007fffc9627700 in ?? ()
> #11 0x00007f78bf3808a0 in ?? ()
> #12 0x00007f78bf3a3910 in ?? ()
> #13 0x00007f78c1480220 in ?? ()
> #14 0x0000000000000000 in ?? ()
> #0 0x00007f78c06fd4c4 in __lll_lock_wait () from /lib64/libpthread.so.0
>
>
> *************************************************************************
> This e-mail is confidential and may be legally privileged. It is intended
> solely for the use of the individual(s) to whom it is addressed. Any
> content in this message is not necessarily a view or statement from Road
> Tech Computer Systems Limited but is that of the individual sender. If
> you are not the intended recipient, be advised that you have received
> this e-mail in error and that any use, dissemination, forwarding,
> printing, or copying of this e-mail is strictly prohibited. We use
> reasonable endeavours to virus scan all e-mails leaving the company but
> no warranty is given that this e-mail and any attachments are virus free.
> You should undertake your own virus checking. The right to monitor e-mail
> communications through our networks is reserved by us
>
> Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley,
> Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17
> Registered in England No: 02017435, Registered Address: Charter Court,
> Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE.
> *************************************************************************
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
> *RT IMSS Scanned*
>
*************************************************************************
This e-mail is confidential and may be legally privileged. It is intended
solely for the use of the individual(s) to whom it is addressed. Any
content in this message is not necessarily a view or statement from Road
Tech Computer Systems Limited but is that of the individual sender. If
you are not the intended recipient, be advised that you have received
this e-mail in error and that any use, dissemination, forwarding,
printing, or copying of this e-mail is strictly prohibited. We use
reasonable endeavours to virus scan all e-mails leaving the company but
no warranty is given that this e-mail and any attachments are virus free.
You should undertake your own virus checking. The right to monitor e-mail
communications through our networks is reserved by us
Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley,
Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17
Registered in England No: 02017435, Registered Address: Charter Court,
Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE.
*************************************************************************
More information about the Mono-devel-list
mailing list