search for: mallopt

...= Parsing '/etc/asterisk/queues.conf': Found -- Reloading module 'pbx_config.so' (Text Extension Configuration) == Parsing '/etc/asterisk/extensions.conf': Found Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2159)] 0x4015b9fc in mallopt () from /lib/i686/libc.so.6 (gdb) bt #0 0x4015b9fc in mallopt () from /lib/i686/libc.so.6 #1 0x4015ac61 in malloc () from /lib/i686/libc.so.6 #2 0x40161dd0 in strdup () from /lib/i686/libc.so.6 #3 0x08055a2f in cfg_process (tmp=0x80e5950, _tmpc=0xbffff360, _last=0xbffff364, buf=0x6c636e69 <A...

...__libc_secure_getenv(const char *); + /* Compile-time options @@ -3365,15 +3367,15 @@ if(__libc_malloc_initialized) return; __libc_malloc_initialized = 1; - if((s = getenv("MALLOC_TRIM_THRESHOLD_"))) + if((s = __libc_secure_getenv("MALLOC_TRIM_THRESHOLD_"))) mALLOPt(M_TRIM_THRESHOLD, atoi(s)); - if((s = getenv("MALLOC_TOP_PAD_"))) + if((s = __libc_secure_getenv("MALLOC_TOP_PAD_"))) mALLOPt(M_TOP_PAD, atoi(s)); - if((s = getenv("MALLOC_MMAP_THRESHOLD_"))) + if((s = __libc_secure_getenv("MALLOC_MMAP_THRESHOLD_")))...

...t/output error Reading symbols from /usr/lib/libxenctrl.so.3.0...done. Loaded symbols for /usr/lib/libxenctrl.so.3.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0xb7e35e35 in mallopt () from /lib/libc.so.6 (gdb) where #0 0xb7e35e35 in mallopt () from /lib/libc.so.6 #1 0xb7e34fb3 in malloc () from /lib/libc.so.6 #2 0x08049eca in putpkt (buf=0x8053090 "T0505:b4ff5ac3;04:9cff5ac3;08:431b16c0;") at ../../../gdb-6.2.1/gdb/gdbserver/remote-utils.c:273 #3 0x0804b27e...

hi just after talking to Jeremy, I downloaded the source he's using and compiled. core dump! This was without gatekeeper: (gdb) bt #0 0x40141118 in mallopt () from /lib/libc.so.6 #1 0x401400fc in malloc () from /lib/libc.so.6 #2 0x405e981b in PAbstractArray::SetSize(int) () from /usr/src/pwlib/lib/libpt_linux_x86_r.so.1 #3 0x405ed006 in PString::SetSize(int) () from /usr/src/pwlib/lib/libpt_linux_x86_r.so.1 #4 0x405e8d4c in PContainer::SetMinSiz...

...== Parsing '/etc/asterisk/queues.conf': Found -- Reloading module 'pbx_config.so' (Text Extension Configuration) == Parsing '/etc/asterisk/extensions.conf': Found Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4824)] 0x4015b9fc in mallopt () from /lib/i686/libc.so.6 (gdb) bt #0 0x4015b9fc in mallopt () from /lib/i686/libc.so.6 #1 0x4015ac61 in malloc () from /lib/i686/libc.so.6 #2 0x40161dd0 in strdup () from /lib/i686/libc.so.6 #3 0x080559eb in cfg_process (tmp=0x80e3000, _tmpc=0xbffff360, _last=0xbffff364, buf=0x61666564 &...

On 11/21/2014 06:12 AM, Ian Campbell wrote: > On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote: >> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about >> various dynamic thresholds for growing and shrinking the heap. My guess >> is that we are bouncing up and down over some threshold with every other >> reboot. > IOW I'm not overly concerned with this apparent bi-modality, so long as > the amoun...

On Fri, 2014-11-21 at 15:25 -0500, Gedalya wrote: > On 11/21/2014 06:12 AM, Ian Campbell wrote: > > On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote: > >> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about > >> various dynamic thresholds for growing and shrinking the heap. My guess > >> is that we are bouncing up and down over some threshold with every other > >> reboot. > > IOW I'm not overly concerned with this apparent bi-modality, so lo...

On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote: > http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about > various dynamic thresholds for growing and shrinking the heap. My guess > is that we are bouncing up and down over some threshold with every other > reboot. IOW I'm not overly concerned with this apparent bi-modality, so long as the amount isn't increasin...

...s found)... (no debugging symbols found)...0x4024ef46 in waitpid () from /lib/libc.so.6 #0 0x4024ef46 in waitpid () from /lib/libc.so.6 #1 0x401e7594 in strtold_l () from /lib/libc.so.6 #2 0x081bcea6 in smb_panic () #3 0x081ab587 in dbgtext () #4 <signal handler called> #5 0x40219abd in mallopt () from /lib/libc.so.6 #6 0x40219368 in mallopt () from /lib/libc.so.6 #7 0x40218553 in malloc () from /lib/libc.so.6 #8 0x4020e0e1 in open_memstream () from /lib/libc.so.6 #9 0x4027adb0 in vsyslog () from /lib/libc.so.6 #10 0x4027ad1f in syslog () from /lib/libc.so.6 #11 0x081ab067 in Debug1 (...

...e the official debian packages), in case it rings any bells.. (gdb) s oe_encode (opt=0xbffff870) at encode.c:201 201 vorbis_encode_setup_init(&vi); (gdb) s 208 vorbis_analysis_init(&vd,&vi); (gdb) s Program received signal SIGSEGV, Segmentation fault. 0xb7da0bd6 in mallopt () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7da0bd6 in mallopt () from /lib/tls/libc.so.6 #1 0xb7da0394 in calloc () from /lib/tls/libc.so.6 #2 0xb7ee73a1 in _book_unquantize () from /usr/lib/libvorbis.so.0 #3 0xb7ee7846 in vorbis_book_init_encode () from /usr/lib/libvorbis.so.0 #4 0xb7ed97fb in...

...latest code I get given crap for it. Given that most of the time you don't know HOW to reproduce a problem on the latest code anyway, not accepting bugs from older versions does the community no service, because potential bugs are never accepted for submission. (gdb) bt full #0 0xb7da8d3c in mallopt () from /lib/libc.so.6 No symbol table info available. #1 0xb7da7e3a in malloc () from /lib/libc.so.6 No symbol table info available. #2 0xb7b30aa1 in create_transaction (p=0x0) at pbx_dundi.c:2787 trans = (struct dundi_transaction *) 0x0 #3 0xb7b3e616 in find_transaction (hdr=0xbe9fda40...

our * crashed twice in a month with segmentation fault & a core dump. here's the stack trace: #0 0xb7e11965 in mallopt () from /lib/tls/libc.so.6 #1 0xb7e10c43 in malloc () from /lib/tls/libc.so.6 #2 0xb7e17090 in strdup () from /lib/tls/libc.so.6 #3 0x08057ada in ast_verbose (fmt=0x0) at logger.c:879 #4 0xb7b29009 in moh_files_release (chan=0x9455ca0, data=0xb657be48) at res_musiconhold.c:180 #5 0x080673ae in...

...; exten => s,4,Hangup Running asterisk (with the above versions) through gdb and doing a backtrace gives me: #0 0xa7d45947 in raise () from /lib/tls/libc.so.6 #1 0xa7d470c9 in abort () from /lib/tls/libc.so.6 #2 0xa7d7afda in __fsetlocking () from /lib/tls/libc.so.6 #3 0xa7d8289f in mallopt () from /lib/tls/libc.so .6 #4 0xa7d82942 in free () from /lib/tls/libc.so.6 #5 0xa75efd68 in rxfax_exec (chan=0x818c5f8, data=0xa74a4798) at app_rxfax.c:327 #6 0x08090088 in pbx_extension_helper (c=0x818c5f8, con=<value optimized out>, context=<value optimized out>, exten=0x818c...

...of free memory). ...investigates... So, http://man7.org/linux/man-pages/man3/malloc.3.html talks about special behaviour using mmap for allocations above MMAP_THRESHOLD (128K by default), which we will be hitting here I think. That explains the anon mapping. http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about various dynamic thresholds for growing and shrinking the heap. My guess is that we are bouncing up and down over some threshold with every other reboot. Ian.

...ime you don't know HOW to > > reproduce a problem on the latest code anyway, not > accepting bugs from older versions does > > the community no service, because potential bugs are never > accepted for submission. > > > > (gdb) bt full > > #0 0xb7da8d3c in mallopt () from /lib/libc.so.6 > > No symbol table info available. > > #1 0xb7da7e3a in malloc () from /lib/libc.so.6 > > No symbol table info available. > > #2 0xb7b30aa1 in create_transaction (p=0x0) at pbx_dundi.c:2787 > > trans = (struct dundi_transaction *) 0x0...

...() from /lib/libc.so.6 >>#2 0x401e8712 in strtold_l () from /lib/libc.so.6 >>#3 0x401e8815 in system () from /lib/libc.so.6 >>#4 0x0817da35 in smb_panic () >>#5 0x0816f256 in dbgtext () >>#6 0x401d29d8 in sigaction () from /lib/libc.so.6 >>#7 0x4021677a in mallopt () from /lib/libc.so.6 >>#8 0x40215467 in realloc () from /lib/libc.so.6 >>#9 0x0817ce91 in Realloc () >>#10 0x080c4ce6 in asn1_write () >>#11 0x080c4d62 in asn1_write_uint8 () >>#12 0x080c4f23 in asn1_write_OID () >>#13 0x080c4afd in spnego_gen_auth_response (...

On 08/26/2014 04:34 AM, Stefan Hajnoczi wrote: > On Mon, Aug 25, 2014 at 8:42 PM, Chris Friesen > <chris.friesen at windriver.com> wrote: >> I'm trying to figure out if there are any limits on how high the inflight >> numbers can go, but I'm not having much luck. >> >> I was hopeful when I saw qemu calling virtio_add_queue() with a queue size, >>

On 08/26/2014 04:34 AM, Stefan Hajnoczi wrote: > On Mon, Aug 25, 2014 at 8:42 PM, Chris Friesen > <chris.friesen at windriver.com> wrote: >> I'm trying to figure out if there are any limits on how high the inflight >> numbers can go, but I'm not having much luck. >> >> I was hopeful when I saw qemu calling virtio_add_queue() with a queue size, >>

...process 9 sent handshake: PID 11589 dovecot-auth: Jan 06 12:21:33 Info: Login process 10 connected dovecot-auth: Jan 06 12:21:33 Info: Login process 10 sent handshake: PID 11590 ---- Core was generated by `dovecot-auth'. Program terminated with signal 11, Segmentation fault. #0 0x402c0284 in mallopt () from /lib/libc.so.6 dovecot.conf base_dir = /var/run/dovecot # Protocols we want to be serving: # imap imaps pop3 pop3s protocols = imap disable_plaintext_auth = no log_path = /var/log/dovecot.log info_log_path = /var/log/dovecot.log login_chroot = no login = imap login_user = dovecot login...

On 11/20/2014 03:21 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote: >> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which >> is freed by xc_dom_release. However the various xc_try_*_decode routines (other >> than the gzip one) just use plain malloc/realloc and therefore the buffer ends >> up