Ticket #1174 (new defect)

Opened 5 years ago

Last modified 4 years ago

segfault in destroy_file caused by osync_objformat_destroy in osync_converter_invoke

Reported by: henrik Owned by: dgollub
Priority: normal Milestone: OpenSync 0.40
Component: OpenSync: Format Conversion Version: 0.39
Severity: major Keywords:
Cc:

Description

I am getting segfault in destroy_file at file-sync/src/file.c:112 after "All changes got multiplied"

gdb output:

#2  0xb7fc9628 in destroy_file (input=0x3 <Address 0x3 out of bounds>, inpsize=28, user_data=0x0, error=0xb6d850f8)
    at /xxx/file-sync/src/file.c:112

full gdb trace:

Received an entry 3 (xmlformat-contact) from member 1 (mozilla-sync). Changetype ADDED
contact sink of member 1 of type mozilla-sync just sent all changes
Main sink of member 1 of type mozilla-sync just sent all changes
Received an entry 3 (xmlformat-contact) from member 2 (file-sync). Changetype ADDED
Received an entry 3~ (xmlformat-contact) from member 2 (file-sync). Changetype ADDED
contact sink of member 2 of type file-sync just sent all changes
Main sink of member 2 of type file-sync just sent all changes
All clients sent changes or error
All changes got mapped
All conflicts have been reported
All changes got multiplied

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6d85b90 (LWP 28477)]
0xb7d99572 in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7d99572 in free () from /lib/tls/i686/cmov/libc.so.6
#1  0xb7ece126 in g_free () from /usr/lib/libglib-2.0.so.0
#2  0xb7fc9628 in destroy_file (input=0x3 <Address 0x3 out of bounds>, inpsize=28, user_data=0x0, error=0xb6d850f8)
    at /xxx/file-sync/src/file.c:112
#3  0xb7f7e9c2 in osync_objformat_destroy (format=0x0, data=0xa00dcc8 "\001", size=28, error=0xb6d850f8)
    at /xxx/opensync/opensync/format/opensync_objformat.c:152
#4  0xb7f796d1 in osync_converter_invoke (converter=0x3, data=0xa00b8b8, config=0xa01f760 "", error=0xb6d850f8)
    at /xxx/opensync/opensync/format/opensync_converter.c:204
#5  0xb7f7b28a in osync_format_env_convert (env=0x9c05e20, path=0xa00dc78, data=0xa00b8b8, error=0xb6d850f8)
    at /xxx/opensync/opensync/format/opensync_format_env.c:1213
#6  0xb7f72fe3 in osync_entry_engine_convert (entry_engine=0xa01f1c8, formatenv=0x9c05e20, objtype_sink=0x9b1e7d8, cachedpath=0xb6d85008, 
    error=0xb6d850f8) at /xxx/opensync/opensync/engine/opensync_mapping_entry_engine.c:252
#7  0xb7f7778a in osync_sink_engine_convert_to_dest (engine=0x9ebc2a8, formatenv=0x9c05e20, error=0xb6d850f8)
    at /xxx/opensync/opensync/engine/opensync_sink_engine.c:196
#8  0xb7f73d01 in osync_obj_engine_prepare_write (engine=0x9ebcc08, error=0xb6d850f8)
    at /xxx/opensync/opensync/engine/opensync_obj_engine.c:1464
#9  0xb7f76bf2 in osync_obj_engine_command (engine=0x9ebcc08, cmd=OSYNC_ENGINE_COMMAND_PREPARE_WRITE, error=0xb6d850f8)
    at /xxx/opensync/opensync/engine/opensync_obj_engine.c:1213
#10 0xb7f6ebfc in osync_engine_event (engine=0x9bed278, event=OSYNC_ENGINE_EVENT_MULTIPLIED)
    at /xxx/opensync/opensync/engine/opensync_engine.c:1989
#11 0xb7f71130 in _osync_engine_event_callback (objengine=0x9ebcc08, event=OSYNC_ENGINE_EVENT_MULTIPLIED, error=0x0, userdata=0x9bed278)
    at /xxx/opensync/opensync/engine/opensync_engine.c:1153
#12 0xb7f741ef in osync_obj_engine_event (engine=0x9ebcc08, event=OSYNC_ENGINE_EVENT_MULTIPLIED, error=0x0)
    at /xxx/opensync/opensync/engine/opensync_obj_engine.c:1311
#13 0xb7f76cd8 in osync_obj_engine_command (engine=0x9ebcc08, cmd=OSYNC_ENGINE_COMMAND_MULTIPLY, error=0xb6d85238)
    at /xxx/opensync/opensync/engine/opensync_obj_engine.c:1208
#14 0xb7f6ff6c in osync_engine_command (engine=0x9bed278, command=0xa007a20) at /xxx/opensync/opensync/engine/opensync_engine.c:1828
#15 0xb7f703c9 in _command_dispatch (source=0x9bed5e0, callback=0, user_data=0x9bed278)
    at /xxx/opensync/opensync/engine/opensync_engine.c:365
#16 0xb7ec5b88 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#17 0xb7ec90eb in ?? () from /usr/lib/libglib-2.0.so.0
#18 0xb7ec95ba in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#19 0xb7ef07bf in ?? () from /usr/lib/libglib-2.0.so.0
#20 0xb7ac94ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#21 0xb7e0c49e in clone () from /lib/tls/i686/cmov/libc.so.6

OSYNC_TRACE is saying:

Starting to convert from objtype contact and format xmlformat-contact
>>>>>>>  osync_format_env_convert(0x4b7a490, 0x66160b8, 0x4a90d98, 0x62720f8)
	>>>>>>>  osync_converter_invoke(0x4bf35f0, 0x4a90d98, , 0x62720f8)
		Converter of type 3, from 0x4b859c0(file) to 0x4bd6c30(plain)
		Converting file to plain

and then it dies.

As far as I can see, the error comes from osync_converter_invoke in opensync_converter.c which has

osync_bool osync_converter_invoke(OSyncFormatConverter *converter, OSyncData *data, const char *config, OSyncError **error)
{
[...]
	if (converter->type != OSYNC_CONVERTER_DETECTOR) {
		
		osync_data_steal_data(data, &input_data, &input_size);
		if (input_data) {
			osync_assert(converter->convert_func);
		
			/* Invoke the converter */
			if (!converter->convert_func(input_data, input_size, &output_data, &output_size, &free_input, config, converter->userdata, error))
				goto error;

			[...]

			/* Good. We now have some new data. Now we have to see what to do with the old data */
			if (free_input) {
				if (!osync_objformat_destroy(converter->source_format, input_data, input_size, error))
				goto error;
			}
			osync_data_set_data(data, output_data, output_size);
		}
	}

So, converter->convert_func sets free_input=TRUE, and then osync_converter_invoke calls osync_objformat_destroy

But it would seem, that the objformat should *not* be destroyed.

The following for from osync_converter_invoke in opensync_converter.c is a (ditry) workaround;

			/* Good. We now have some new data. Now we have to see what to do with the old data */
			if (free_input) {
//				if (!osync_objformat_destroy(converter->source_format, input_data, input_size, error))
//					go

I am no expert on the inner workings of this code, so I cannot provide a real patch.

However, it seems to me that this is a real bug, that needs a real fix...

Change History

comment:1 Changed 4 years ago by dgollub

  • Component changed from OpenSync to OpenSync: Format Conversion
  • Severity changed from normal to major

This could be either a file-sync bug or an conversion path bug. Could you try to reproduce this in meantime with latest trunk?

comment:2 Changed 4 years ago by prahal

Starting to convert from objtype contact and format xmlformat-contact

osync_format_env_convert(0x4b7a490, 0x66160b8, 0x4a90d98, 0x62720f8) osync_converter_invoke(0x4bf35f0, 0x4a90d98, , 0x62720f8)

Converter of type 3, from 0x4b859c0(file) to 0x4bd6c30(plain) Converting file to plain

#2 0xb7fc9628 in destroy_file (input=0x3 <Address 0x3 out of bounds>, inpsize=28, user_data=0x0, error=0xb6d850f8)

at /xxx/file-sync/src/file.c:112

#3 0xb7f7e9c2 in osync_objformat_destroy (format=0x0, data=0xa00dcc8 "\001", size=28, error=0xb6d850f8)

at /xxx/opensync/opensync/format/opensync_objformat.c:152

the gdb output most likely induce the data is not in the file objformat . It segfault because it try to destry something inconsistent.

From the osync trace I would say this is a duplicate of http://www.opensync.org/ticket/1207 , probably more close to the testcase included than the issue I neoucntered myself. Ie : Starting to convert from objtype contact and format xmlformat-contact followed by: Converter of type 3, from 0x4b859c0(file) to 0x4bd6c30(plain) would mean that the change attached to the mapping entry engine is already converted or that the conversion path is cached and that a previous run had a shared change that filled this cached conversion path with "file" while it should have stayed at xmlformat-contact.

Henrik, could you try the patch attached to the above mentionned bug report ? If it does nto get included in the meantime.

Note: See TracTickets for help on using tickets.