On Fri, Feb 12, 2010 at 11:32 AM, Joerg Schilling < joerg.schill...@fokus.fraunhofer.de> wrote:
> Vincent Torri <vincent.to...@gmail.com> wrote: > > > I have a program that fails on realloc. dbx reports: > > > > t...@1 (l...@1) signal SEGV (no mapping at the fault address) in t_splay at > > 0xd078b710 > > 0xd078b710: t_splay+0x007e: movl %ebx,0x00000008(%eax) > > Current function is _eina_strbuf_resize > > 521 buffer = realloc(buf->buf, new_size); > > Such problems typically are a result of allocated memory that was > previously overwritten either at low or high boundary. You may like to > call: > > env LD_PRELOAD=libumem.so.1 UMEM_DEBUG=default UMEM_LOGGING=transaction > your-program > > and later call: > > mdb your-program core > ::umem_status > here is the log: to...@opensolaris:~$ mdb ~/local/e17/bin/elementary_test core Loading modules: [ libumem.so.1 libuutil.so.1 ld.so.1 ] > ::umem_status Status: ready and active Concurrency: 2 Logs: transaction=64k (inactive) Message buffer: umem allocator: redzone violation: write past end of buffer buffer=836c540 bufctl=836da78 cache: umem_alloc_40 previous transaction on buffer 836c540: thread=1 time=T-0.001211507 slab=828d610 cache: umem_alloc_40 libumem.so.1'umem_cache_alloc_debug+0x144 libumem.so.1'umem_cache_alloc+0x19a libumem.so.1'umem_alloc+0xcd libumem.so.1'malloc+0x2a libeina-ver-pre-svn-05.so.0.9.9'_eina_strbuf_init+0x59 libeina-ver-pre-svn-05.so.0.9.9'eina_strbuf_new+0x79 libedje-ver-pre-svn-05.so.0.9.93'_edje_textblock_style_parse_and_fix+0x7d libedje-ver-pre-svn-05.so.0.9.93'_edje_file_open+0x1ab libedje-ver-pre-svn-05.so.0.9.93'_edje_cache_file_coll_open+0x15a libedje-ver-pre-svn-05.so.0.9.93'edje_file_group_exists+0x61 libelementary-ver-pre-svn-05.so.0.6.0'_elm_theme_find_try+0x2e libelementary-ver-pre-svn-05.so.0.6.0'_elm_theme_theme_element_try+0x17f libelementary-ver-pre-svn-05.so.0.6.0'_elm_theme_group_file_find+0x152 libelementary-ver-pre-svn-05.so.0.6.0'_elm_theme_set+0x5f libelementary-ver-pre-svn-05.so.0.6.0'elm_bg_add+0xf7 umem: heap corruption detected stack trace: libumem.so.1'umem_err_recoverable+0x3f libumem.so.1'umem_error+0x4bc libumem.so.1'umem_free+0x10a libumem.so.1'process_free+0x55 libumem.so.1'free+0x1a libumem.so.1'realloc+0x7c libeina-ver-pre-svn-05.so.0.9.9'_eina_strbuf_resize+0x162 libeina-ver-pre-svn-05.so.0.9.9'eina_strbuf_append+0xbe libedje-ver-pre-svn-05.so.0.9.93'_edje_textblock_style_parse_and_fix+0x1b7 libedje-ver-pre-svn-05.so.0.9.93'_edje_file_open+0x1ab libedje-ver-pre-svn-05.so.0.9.93'_edje_cache_file_coll_open+0x15a libedje-ver-pre-svn-05.so.0.9.93'edje_file_group_exists+0x61 libelementary-ver-pre-svn-05.so.0.6.0'_elm_theme_find_try+0x2e libelementary-ver-pre-svn-05.so.0.6.0'_elm_theme_theme_element_try+0x17f libelementary-ver-pre-svn-05.so.0.6.0'_elm_theme_group_file_find+0x152 libelementary-ver-pre-svn-05.so.0.6.0'_elm_theme_set+0x5f libelementary-ver-pre-svn-05.so.0.6.0'elm_bg_add+0xf7 elementary_test'my_win_main+0x63 elementary_test'elm_main+0xb elementary_test'main+0x23 elementary_test'_start+0x7d there is indeed a report of heap corruption. but i don't know what to do with it :-) Note: there is no such problem on linux (valgrind does not report anything about read/write memory error) Vincent Torri
_______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
