Re: [Opensync-devel] Breakthrough: all opensync library tests pass

[Chris F. <cd...@fo...>]

On Sat, Jul 23, 2011 at 12:05:19PM +0200, Daniel Gollub wrote:
> Run with G_SLICE=always-malloc
> 
> dgollub@marvin:~/projects/opensync-cdf/build/tests> valgrind /home/dgollub/projects/opensync-cdf/build/tests/engine-error 
> engine_error_get_changes_disconnect_error
> ==490== Memcheck, a memory error detector
> ==490== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
> ==490== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
> ==490== Command: /home/dgollub/projects/opensync-cdf/build/tests/engine-error engine_error_get_changes_disconnect_error
> ==490== 
> Running suite(s): "engine_error"
> ==491== Thread 4:
> ==491== Invalid write of size 4
> ==491==    at 0x4E7AF3D: osync_queue_disconnect (opensync_queue.c:1206)
> ==491==    by 0x4E4E5FD: osyncClientDisconnectCallback (opensync_client.c:1960)
> ==491==    by 0x50FBBD2: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.2800.0)
> ==491==    by 0x50FC3AF: ??? (in /lib64/libglib-2.0.so.0.2800.0)
> ==491==    by 0x50FCA34: g_main_loop_run (in /lib64/libglib-2.0.so.0.2800.0)
> ==491==    by 0x5123465: ??? (in /lib64/libglib-2.0.so.0.2800.0)
> ==491==    by 0x749CA3E: start_thread (pthread_create.c:297)
> ==491==  Address 0x7c9d228 is 232 bytes inside a block of size 240 free'd
> ==491==    at 0x4C2599C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==491==    by 0x4E7A287: osync_queue_unref (opensync_queue.c:953)
> ==491==    by 0x4E53D06: osync_client_proxy_shutdown (opensync_client_proxy.c:1239)
> ==491==    by 0x4E5C421: _osync_engine_finalize_member (opensync_engine.c:749)
> ==491==    by 0x4E5E3DD: osync_engine_finalize (opensync_engine.c:1807)
> ==491==    by 0x4063F6: engine_error_get_changes_disconnect_error (check_engine_error.c:2907)
> ==491==    by 0x6CEFE18: srunner_run_all (in /usr/lib64/libcheck.so.0.0.0)
> ==491==    by 0x412548: osync_testsuite (support.c:65)
> ==491==    by 0x6F11BFC: (below main) (libc-start.c:226)

Thanks!  That's a new one.

In osync_queue_new_threadcom(), connected_queue gets set to opposing
read/write queues, but is not ref'd.  I think it was written that way on
purpose, so I'll have to look at it more closely later.  For example,
osync_queue_unref() doesn't unref it, it just set it to NULL.

But osync_queue_disconnect() does this:

        if (queue->usethreadcom){
                queue->connected_queue->connection_closing = TRUE;
        }else{

so it either needs a ref, or just a check whether connected_queue is NULL.

Will have to check the others when I have more time.

Thanks,
- Chris