failed assertions when DISPATCH_DEBUG enabled
When I define DISPATCH_DEBUG=1 and build the library under Linux, almost all of the test programs fail. I checked a couple of them, and they both fail a dispatch_assert() test at the same place: in _dispatch_ccache_init(). See below for a backtrace: $ gdb ./dispatch_api GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/mheily/proj/libdispatch/trunk/testing/.libs/dispatch_api...done. (gdb) r Starting program: /home/mheily/proj/libdispatch/trunk/testing/.libs/dispatch_api [Thread debugging using libthread_db enabled] ================================================== [TEST] Dispatch (Public) API [PID] 17941 ================================================== Actual: 0x6020a0 Expected: 0x6020a0 [PASS] dispatch_get_main_queue Program received signal SIGABRT, Aborted. 0x00007ffff72604b5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) bt #0 0x00007ffff72604b5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff7263f50 in *__GI_abort () at abort.c:92 #2 0x00007ffff7bd023e in _dispatch_abort (line=<value optimized out>, val=<value optimized out>) at queue.c:1774 #3 0x00007ffff7bd02ab in _dispatch_ccache_init (context=<value optimized out>) at queue.c:1697 #4 0x00007ffff7bcfb15 in dispatch_once_f (val=0x7ffff7dd8dc8, ctxt=0x4615, func=0x6) at once.c:43 #5 0x00007ffff7bd02ec in _dispatch_continuation_alloc_from_heap () at queue.c:1707 #6 0x00007ffff7bd05f1 in _dispatch_async_f_slow (dq=0x4615, context=0x4615, func=0x6) at queue.c:681 #7 0x0000000000400bd8 in main () (gdb)
On Tuesday 22 December 2009 06:06:28 am Mark Heily wrote:
When I define DISPATCH_DEBUG=1 and build the library under Linux, almost all of the test programs fail. I checked a couple of them, and they both fail a dispatch_assert() test at the same place: in _dispatch_ccache_init().
The reason is that the current implementation of malloc_zone for linux (src/shims/malloc_zone.h) is just a dummy implementation and returns always a null-pointer. Therefore, this assertion will always fail. The current dummy implementation just dispatches the zone_malloc calls to the normal malloc routine. The attached "patch" circumvents the problem with the assertion by allocating a zone and returning a pointer to it. The behavior of the zone_malloc remains the same. Martin
On Wed, 23 Dec 2009, Martin Nowack wrote:
On Tuesday 22 December 2009 06:06:28 am Mark Heily wrote:
When I define DISPATCH_DEBUG=1 and build the library under Linux, almost all of the test programs fail. I checked a couple of them, and they both fail a dispatch_assert() test at the same place: in _dispatch_ccache_init().
The reason is that the current implementation of malloc_zone for linux (src/shims/malloc_zone.h) is just a dummy implementation and returns always a null-pointer. Therefore, this assertion will always fail.
The current dummy implementation just dispatches the zone_malloc calls to the normal malloc routine. The attached "patch" circumvents the problem with the assertion by allocating a zone and returning a pointer to it. The behavior of the zone_malloc remains the same.
Hi Martin-- I've committed a slight variation on this patch as r176: specifically, I return (void *)-1 rather than malloc'ing state. As we don't implement the internals of malloc zones, I would rather cause a segfault if a consumer of the API decides to muck around with the internals, as that implies more support for malloc zones than the stubs provide. Could you let me know if this adequately addresses the assertion failures you've been running into? Robert N M Watson Computer Laboratory University of Cambridge
participants (3)
-
Mark Heily
-
Martin Nowack
-
Robert Watson