Crash in libinfinity

[nirik]

I'm gettiing a crash with gobby here. It's fine for a while, then crashes (likely when someone edits a document that goes over 80 lines).

The backtrace is:
#0 0x00007ffff1b884e8 in raise () at /lib64/libc.so.6
#1 0x00007ffff1b8a0ea in abort () at /lib64/libc.so.6
#2 0x00007ffff36a4a15 in g_assertion_message () at /lib64/libglib-2.0.so.0
#3 0x00007ffff36a4aaa in g_assertion_message_expr () at /lib64/libglib-2.0.so.0
#4 0x00007ffff2fceb21 in inf_text_chunk_get_segment () at /lib64/libinftext-0.6.so.0
#5 0x00007ffff2fced68 in inf_text_chunk_substring () at /lib64/libinftext-0.6.so.0
#6 0x00007ffff2fd7822 in inf_text_remote_delete_operation_recon_feed ()

at /lib64/libinftext-0.6.so.0

#7 0x00007ffff2fd7efa in inf_text_remote_delete_operation_apply_transformed ()

at /lib64/libinftext-0.6.so.0

#8 0x00007ffff2d50748 in inf_adopted_algorithm_execute_request () at /lib64/libinfinity-0.6.so.0
#9 0x00007ffff2d55a8d in inf_adopted_session_process_request () at /lib64/libinfinity-0.6.so.0
#10 0x00007ffff2d56ee9 in inf_adopted_session_process_xml_run () at /lib64/libinfinity-0.6.so.0
#11 0x00007ffff2fdae62 in inf_text_session_process_xml_run () at /lib64/libinftext-0.6.so.0
#12 0x00007ffff2d71a7c in inf_session_communication_object_received ()

at /lib64/libinfinity-0.6.so.0

#13 0x00007ffff2d4d0cf in infc_session_proxy_communication_object_received ()

at /lib64/libinfinity-0.6.so.0

#14 0x00007ffff2d835ab in inf_communication_central_method_received ()

at /lib64/libinfinity-0.6.so.0

#15 0x00007ffff2d8829c in inf_communication_registry_received_cb () at /lib64/libinfinity-0.6.so.0
#16 0x00007ffff397d7b5 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#17 0x00007ffff398fb04 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#18 0x00007ffff3998540 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#19 0x00007ffff399890f in g_signal_emit () at /lib64/libgobject-2.0.so.0
#20 0x00007ffff2d80a77 in inf_xmpp_connection_sax_end_element () at /lib64/libinfinity-0.6.so.0
#21 0x00007ffff788428d in xmlParseEndTag1 () at /lib64/libxml2.so.2
#22 0x00007ffff788cac1 in xmlParseTryOrFinish () at /lib64/libxml2.so.2
#23 0x00007ffff788dd2b in xmlParseChunk () at /lib64/libxml2.so.2
#24 0x00007ffff2d7f0d6 in inf_xmpp_connection_received_cb () at /lib64/libinfinity-0.6.so.0
#25 0x00007ffff397d7b5 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#26 0x00007ffff398f861 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#27 0x00007ffff3998540 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#28 0x00007ffff399890f in g_signal_emit () at /lib64/libgobject-2.0.so.0
#29 0x00007ffff2d77977 in inf_tcp_connection_io_incoming () at /lib64/libinfinity-0.6.so.0
#30 0x00007ffff2d77d18 in inf_tcp_connection_io () at /lib64/libinfinity-0.6.so.0
#31 0x00007ffff342221f in inf_gtk_io_watch_func () at /lib64/libinfgtk3-0.6.so.0
#32 0x00007ffff367ee3a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#33 0x00007ffff367f1d0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#34 0x00007ffff367f4f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#35 0x00007ffff51f4625 in gtk_main () at /lib64/libgtk-3.so.0
#36 0x00005555555f8552 in main ()

Happy to try and gather more info. Thanks.

[nirik]

Sorry, that should be a document that goes over 80 characters in a line, not 80 lines in the document. Right margin is set to 80 in preferences. It also doesn't happen when I do that, only when other remote users do.

[nirik]

And the actual crashing assertion was:

ERROR:inf-text-chunk.c:256:inf_text_chunk_get_segment: assertion failed: (iter != g_sequence_get_begin_iter(self->segments)

[aburgm]

Interesting. It's unlikely that it has to do with the right margin set in the preferences, since that is only a visual guide but has nothing to do with what's going on in the text transformation. I assume this is libinfinity 0.6.6? Can you reproduce this consistently?

Gobby writes record files in ~/.infinote-records/XXX.xml, where XXX is the name of the document. This could be useful to reproduce this error. Can you check if you have such a file and provide it to me? Note that Gobby overwrites that file if you join a session with the same name again, so make sure to grab the file right after Gobby crashed, before potentially re-joining the session.

[aburgm]

(Disclaimer: that record file contains the whole content of the document.)

[nirik]

Ah yeah, we can duplicate it wthout the right margin... just seems to be remote activity.

I do have the record file:

http://www.scrye.com/~kevin/testdoc.record.xml

[aburgm]

Unfortunately this does not reproduce the problem for me. It seems like you built libinfinity from source? In that case, can you try to run ./inf-test-text-replay testdoc.record.xml from libinfinity's test/ directory, and see if that produces an error?

Also, is that file from the machine on which the crash happens or from the remote counterpart? It would be good to have it from the one on which it crashes.

[nirik]

Yeah, this is the Fedora rawhide package of libinfinity/gobby.

I can try the test replay tomorrow. :)

This is from the machine with the crash. It's just the gobby client that crashes, the server and the other clients are fine.

One thing which may be related here is that recently Fedora started compiling gtkmm with -std=c++11, which meant I had to rebuild gobby and libinfinity with that option as well.

The server is running rhel7 and using the epel7 package (no c++11)
The other client that doesn't crash is fedora 22 and (no c++11)
My client is Fedora rawhide and does have c++11

I'll try the replay tomorrow. Thanks for being so responsive!

[aburgm]

By the way, to correctly play the record to the end you might need to add a </infinote-adopted-session-record> at the end of the file. If Gobby crashes it doesn't get to close the XML properly.

If I see it correctly in the record, it's only one user actively editing the document, and no undo/redo involved. That's really the simplest thing that can happen, so I'm somewhat surprised by this. Also, it seems to happen only when text is being deleted (such as by pressing backspace) and not when text is inserted, correct?

I cannot imagine that this has anything to do with C++11, since the crash happens inside libinfinity, and libinfinity is written in C. But maybe it is affected by some other toolchain changes in rawhide? Which versions of glib are you using on these three machines? I'm still at 2.42 here...

One other thing you can try is to uncomment /*#define CHUNK_CHECK_INTEGRITY*/ in libinftext/inf-text-chunk.c. This enables some additional integrity checks that are not performed by default due to performance reasons. It will not fix anything, but might cause a crash closer to the point where internal consistency actually gets lost that would then lead to the crash later.

[nirik]

ok, I do get a crash also with inf-text-test-replay:

/home/fedora/kevin/testdoc.record.xml... **
ERROR:inf-text-chunk.c:256:inf_text_chunk_get_segment: assertion failed: (iter != g_sequence_get_begin_iter(self->segments))
Aborted (core dumped)

$ rpm -q glib2
glib2-2.46.0-1.fc24.x86_64

After rebuilding with #define CHUNK_CHECK_INTEGRITY in:

/home/fedora/kevin/testdoc.record.xml... **
ERROR:inf-text-chunk.c:93:inf_text_chunk_get_byte_index_utf8: assertion failed: (offset <= g_utf8_strlen(self, bytes))
Aborted (core dumped)

[aburgm]

Thanks, this gives us at least already some clue, in the sense that it is likely related to something new in the environment introduced in rawhide. Maybe it's the glib version -- I'll try if I can reproduce with glib 2.46 tonight.

Meanwhile if you want to dig deeper, you can try compiling libinfinity with ./configure CFLAGS="-O0 -g" (enabling debug symbols) and get a stacktrace for that second crash, and/or check if valgrind reports any errors when running inf-test-text-replay.

[aburgm]

I can reproduce this with glib 2.46. Will investigate.

[aburgm]

Looks like the issue is relying on undocumented behavior of g_sequence_search() when an item in the sequence compares equal to the one that is being searched for.

Can you try to either compile from the libinfinity-0.6 branch or apply 3fb2be4 and d447fc4, and tell me if it fixes the problem for you as well? I'll roll a libinfinity-0.6.7 tarball if it does.

[nirik]

Yes, that seems to solve the crash. ;) Thanks much!