Freeze with 100% CPU after opening documents via API

[urbanhusky]

Hi,

I’m using the C++ API/SDK to open documents in fullscreen on Ubuntu Desktop 14.04.02 LTS.
Libreoffice is version 4.4.3.2 (English)

I open the document via the XComponentLoader->loadComponentFromUrl with the “Hidden” property set.
Then I use the XLayoutManager to hide all controls before showing the corresponding XWindow.

After a few iterations the API hangs at the call

xContainerWindow->setVisible(sal_True);

In the terminal I see the message

(soffice:44857): GLib-CRITICAL **: g_hash_table_iter_next: assertion ‘ri->version == ri->hash_table->version’ failed

The soffice process is now blocked (and would also prevent the bootstrap from completing etc.)

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
44857 boss 20 0 2189916 210692 141440 R 169,1 10,3 59:20.48 soffice.bin

I tried killing the office process before opening a new document, but that causes the following issue on the same line of code:

(soffice:55244): GLib-CRITICAL **: g_variant_new_string: assertion ‘g_utf8_validate (string, -1, NULL)’ failed

(soffice:55244): GLib-CRITICAL **: g_hash_table_iter_next: assertion ‘ri->version == ri->hash_table->version’ failed

The soffice.bin process then also is stuck at 100% CPU and my application eats more and more memory until it freezes at that call.

What could be the cause of this?

Edit
It sometimes also fails when bootstrapping (using the new, simple bootstrap):

Warning: failed to launch javaldx - java may not function correctly
ERROR 4 forking process

[urbanhusky]

This is most likely related to the memory leak in headless office processes…

[AlexKemp]

I’ve found similar behaviour on a standard, brand-new, default desktop install. See https://ask.libreoffice.org/t/soffice-bin-at-44-cpu-under-debian-6-0-peaking-at-99/13294. Not good.

(extra added later):
And this recent q:
Libre Office 4.3 shows "not responding" windows7/64 (I’ve seen more than one like this recently)

[urbanhusky]

There is a known memory leak that hasn’t been fixed for years now, which is most likely the issue here. Happens when starting OO/LO in headless mode (which is also what the bootstrap does).