[Debian GNUstep maintainers] request for help: oolite

Ivan Vučica ivan at vucica.net
Mon Aug 1 10:32:08 UTC 2016


Gdb backtrace is sort-of useful, but reading the code I can't tell where
the bug in leakAt: is. It seems to clean up its use of exitLock after
itself.

I will assume you wanted to send this to the list, and I will also cross
post this onto gnustep-dev.

The curious part is "it works locally, but not on buildd" which you
mentioned earlier in the thread. Is the compiler different remotely? Does
it reproduce with the same compiler?

On Mon, 1 Aug 2016, 10:44 Nicolas Boulenguez, <nicolas at debian.org> wrote:

> On Sun, Jul 31, 2016 at 11:49:03PM +0000, Ivan Vučica wrote:
> > gdb: I meant, attach to it once it freezes and collect the backtrace.
> I did not know that gdb could attach a running process. Thanks.
>
> #0  0x00007fdd098ebe9c in __lll_lock_wait () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #1  0x00007fdd098e5b92 in pthread_mutex_lock () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #2  0x00007fdd0bd115d5 in -[NSRecursiveLock lock] (self=0x55ab20a1a8d0,
> _cmd=0x7fdd0c285d90 <_OBJC_SELECTOR_TABLE+144>) at NSLock.m:308
> #3  0x00007fdd0be20da9 in +[NSObject(GSCleanup) leakAt:] (self=<optimized
> out>, _cmd=<optimized out>, anAddress=<optimized out>) at
> NSObject+GNUstepBase.m:200
> #4  0x00007fdd0bd9731b in +[NSTimeZone initialize] (self=<optimized out>,
> _cmd=<optimized out>) at NSTimeZone.m:1357
> #5  0x00007fdd0a0230d6 in __objc_install_dtable_for_class
> (cls=0x7fdd0c22cd40 <_OBJC_MetaClass_NSTimeZone>) at
> /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:1030
> #6  0x00007fdd0a024d68 in get_implementation (sel=<optimized out>,
> class=<optimized out>, receiver=<optimized out>) at
> /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:260
> #7  objc_msg_lookup (receiver=receiver at entry=0x7fdd0c22ca00
> <_OBJC_Class_NSTimeZone>, op=op at entry=0x7fdd0c1a6ad0
> <_OBJC_SELECTOR_TABLE+80>) at
> /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:450
> #8  0x00007fdd0bc733af in +[NSCalendarDate initialize] (self=<optimized
> out>, _cmd=<optimized out>) at NSCalendarDate.m:372
> #9  0x00007fdd0a0230d6 in __objc_install_dtable_for_class
> (cls=0x7fdd0c1a7280 <_OBJC_MetaClass_NSCalendarDate>) at
> /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:1030
> #10 0x00007fdd0a024d68 in get_implementation (sel=<optimized out>,
> class=<optimized out>, receiver=<optimized out>) at
> /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:260
> #11 objc_msg_lookup (receiver=receiver at entry=0x7fdd0c1a6e60
> <_OBJC_Class_NSCalendarDate>, op=op at entry=0x7fdd0c1b9090
> <_OBJC_SELECTOR_TABLE+80>) at
> /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:450
> #12 0x00007fdd0bcadfe9 in +[NSDate initialize] (self=0x7fdd0c1b9460
> <_OBJC_Class_NSDate>, _cmd=<optimized out>) at NSDate.m:139
> #13 0x00007fdd0a0230d6 in __objc_install_dtable_for_class
> (cls=0x7fdd0c1b9780 <_OBJC_MetaClass_NSDate>) at
> /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:1030
> #14 0x00007fdd0a024d68 in get_implementation (sel=<optimized out>,
> class=<optimized out>, receiver=<optimized out>) at
> /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:260
> #15 objc_msg_lookup (receiver=0x7fdd0c1b9460 <_OBJC_Class_NSDate>,
> op=0x55ab1f408ff0 <_OBJC_SELECTOR_TABLE+400>) at
> /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:450
> #16 0x000055ab1eefc7ce in -[OOAsyncLogger startLogging]
> (self=0x55ab20a84ec0, _cmd=0x55ab1f408f90 <_OBJC_SELECTOR_TABLE+304>) at
> src/Core/OOLogOutputHandler.m:323
> #17 0x000055ab1eefc47b in -[OOAsyncLogger init] (self=0x55ab20a84ec0,
> _cmd=0x55ab1f408e70 <_OBJC_SELECTOR_TABLE+16>) at
> src/Core/OOLogOutputHandler.m:276
> #18 0x000055ab1eefbeca in OOLogOutputHandlerInit () at
> src/Core/OOLogOutputHandler.m:127
> #19 0x000055ab1eefa8b8 in OOLoggingInit () at src/Core/OOLogging.m:602
> #20 0x000055ab1ef1799a in main (argc=1, argv=0x7fff61e8a998) at
> src/SDL/main.m:81
>
> > strace: I see no attachment
> It was probably too big for the list. Here are the trailing lines.
>
> [...]
> stat("/home/sandbox/.Oolite", {st_mode=S_IFDIR|0755, st_size=4096, ...}) =
> 0
> stat("/home/sandbox/.Oolite/Logs", {st_mode=S_IFDIR|0755, st_size=4096,
> ...}) = 0
> stat("/home/sandbox/.Oolite/Logs/Latest.log", 0x7fffe1c96320) = -1 ENOENT
> (No such file or directory)
> brk(0x55f4083be000)                     = 0x55f4083be000
> mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fdd4eae2000
> mprotect(0x7fdd4eae2000, 4096, PROT_NONE) = 0
> clone(child_stack=0x7fdd4f2e1df0,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> parent_tidptr=0x7fdd4f2e29d0, tls=0x7fdd4f2e2700,
> child_tidptr=0x7fdd4f2e29d0) = 26374
> futex(0x55f40831b8d8, FUTEX_WAIT_PRIVATE, 2, NULL
>
> > -- but even if I did I would probably not go and debug oolite myself
> > anyway; this was mentioned for your information and to aid your
> > analysis :-)
> Thanks for your advices so far.
> At least I know where to start with a backtrace.
>
> Please send me a carbon copy of your answer to the list.
>


More information about the pkg-GNUstep-maintainers mailing list