elm_code: 100% CPU/Memory on large files

[ApostolosB]

Tried ecrire file.txt from the command line. Not sure if this is because of the size of the files but here goes:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `ecrire fgdgda.txt'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb73dfe43 in eina_unicode_utf8_next_get (buf=0x23ce <error: Cannot access memory at address 0x23ce>, iindex=0xbfdbc50c) at ../src/lib/eina/eina_inline_unicode.x:43
43         if ((d = buf[ind++]) == 0) return 0;
[Current thread is 1 (Thread 0xb56fad00 (LWP 18306))]
(gdb) bt
#0  0xb73dfe43 in eina_unicode_utf8_next_get (buf=0x23ce <error: Cannot access memory at address 0x23ce>, iindex=0xbfdbc50c) at ../src/lib/eina/eina_inline_unicode.x:43
#1  0xb73e5c54 in _elm_code_widget_line_text_column_width_to_position (obj=0x80006e54, pd=0xa137ca0, line=0xa260c80, position=67) at lib/elementary/elm_code_widget_text.c:136
#2  0xb73e5cd6 in _elm_code_widget_line_text_column_width_get (obj=0x80006e54, pd=0xa137ca0, line=0xa260c80) at lib/elementary/elm_code_widget_text.c:155
#3  0xb73e968f in elm_obj_code_widget_line_text_column_width_get (obj=0x80006e54, line=0xa260c80) at lib/elementary/elm_code_widget.eo.c:154
#4  0xb73ea835 in elm_code_widget_line_text_column_width_get (obj=0x80006e54, line=0xa260c80) at lib/elementary/elm_code_widget.eo.c:491
#5  0xb73e042e in _elm_code_widget_fill_line_tokens (widget=0x80006e54, cells=0xa26ed28, count=129, line=0xa260c80) at lib/elementary/elm_code_widget.c:175
#6  0xb73e0b7b in _elm_code_widget_fill_line (widget=0x80006e54, line=0xa260c80) at lib/elementary/elm_code_widget.c:349
#7  0xb73e0e7d in _elm_code_widget_fill_range (widget=0x80006e54, pd=0xa137ca0, first_row=1, last_row=29, newline=0xa25ee90) at lib/elementary/elm_code_widget.c:411
#8  0xb73e0ee5 in _elm_code_widget_fill_update (widget=0x80006e54, first_row=1, last_row=29, newline=0xa25ee90) at lib/elementary/elm_code_widget.c:423
#9  0xb73e1065 in _elm_code_widget_refresh (widget=0x80006e54, line=0xa25ee90) at lib/elementary/elm_code_widget.c:459
#10 0xb73e1100 in _elm_code_widget_line_cb (data=0x80006e54, event=0xbfdbc7ac) at lib/elementary/elm_code_widget.c:481
#11 0xb77500ba in _event_callback_call (obj_id=0x80006e54, pd=0xa137a58, desc=0xb769f70c <ELM_CODE_EVENT_LINE_LOAD_DONE>, event_info=0xa25ee90, legacy_compare=1 '\001') at lib/eo/eo_base_class.c:1496
#12 0xb77503ee in _efl_object_event_callback_legacy_call (obj_id=0x80006e54, pd=0xa137a58, desc=0xb769f70c <ELM_CODE_EVENT_LINE_LOAD_DONE>, event_info=0xa25ee90) at lib/eo/eo_base_class.c:1569
#13 0xb77504be in efl_event_callback_legacy_call (obj=0x80006e54, desc=0xb769f70c <ELM_CODE_EVENT_LINE_LOAD_DONE>, event_info=0xa25ee90) at lib/eo/eo_base_class.c:1572
#14 0xb7008d0c in _efl_canvas_object_efl_object_event_callback_legacy_call (eo_obj=0x80006e54, obj=0xa137a80, desc=0xb769f70c <ELM_CODE_EVENT_LINE_LOAD_DONE>, event_info=0xa25ee90) at lib/evas/canvas/evas_object_main.c:993
#15 0xb77504be in efl_event_callback_legacy_call (obj=0x80006e54, desc=0xb769f70c <ELM_CODE_EVENT_LINE_LOAD_DONE>, event_info=0xa25ee90) at lib/eo/eo_base_class.c:1572
#16 0xb73eb1be in elm_code_callback_fire (code=0xa143ef8, signal=0xb769f70c <ELM_CODE_EVENT_LINE_LOAD_DONE>, data=0xa25ee90) at lib/elementary/elm_code.c:61
#17 0xb73dd27b in _elm_code_file_line_insert_data (file=0xa129f60, content=0xaa012809 <error: Cannot access memory at address 0xaa012809>, length=43, row=29, mapped=1 '\001', data=0x0) at lib/elementary/elm_code_file.c:69
#18 0xb73dd572 in elm_code_file_open (code=0xa143ef8, path=0x9c22b18 "fgdgda.txt") at lib/elementary/elm_code_file.c:153
#19 0x0804b7f0 in _start ()
(gdb)

[wltjr]

This maybe an elm code bug not sure.

[wltjr]

Opened task upstream T5497

[ApostolosB]

fgdgda.txt

the test file

[wltjr]

Not resolved with EFL 1.19.1 it does not crash, but never opens, seems to hang or something. Need to debug further.

[ApostolosB]

Just to update this. It stoped crashing on files. On huge ones it just hangs there being slow. At least on my slow system. Efl from git.

[wltjr]

Were you able to close it when it was slowly opening large files? For me I end up with a OOM and crash after a bit. It eats up CPU as well as RAM. I mentioned on the task T5497. Seems like some progress, but not 100% there yet.

[ApostolosB]

killall -9 ecrire did it. It hadn't been able to render anything on the screen though. And yes noticed the same. 100% CPU and eating ram.

[NuLogicSystems]

The CPU spike was fixed in EFL, but it does take a long time to load large files.
Maybe some sort of caching should be used here.

[wltjr]

Very likely, but all that is due to elm_code. Ecrire just passes the document to load to elm_code. Catching, performance, etc is all specific to elm_code. I may look into contributing and furthering elm_code, but not sure I fully understand it yet. If its even fully developed. I think elm_code is still considered experimental. I guess we can close this bug. Though I may wait till its fixed in a release version. I assume the fix is in git and not say 1.20.4 release.

Thanks for keeping me informed!

[wltjr]

Despite all related tasks being closed upstream. The issue still remains. I get 100% CPU when trying to open the document. EFL 1.20.5. Not sure about git, assuming that is the same.

[wltjr]

Adding upstream so they are aware of issues
@Enlightenment @ajwillia-ms @zmike

[andydotxyz]

The fact that it crashed was fixed. The high CPU usage appears to be a new issue. I have been working with ApBBB to resolve this new issue.

[andydotxyz]

I tried replicating that locally and I find:
It takes 15 seconds to open the file
The UI is a little sluggish when moving around
It takes 5 sec to close the file.

This is clearly not acceptable but I wanted to check that we are on the same page before I look into a fix.

[wltjr]

leafpad opens immediately, netbeans issues warning about size and maybe slow, but opens fine no delay. It may have something to do with processing, as in syntax. Given the issue reported in phab task 6209. Maybe totally unrelated, but maybe what ever is causing that lag could be causing lag on file load/close. Though that could be focus/select related. Much smaller file. This one never opens for me. Just freeze ecrire, maxes out a core, and memory starts increasing till OOM.

[NuLogicSystems]

I just tried opening fgdgda.txt in ecrire and ecrire never shows up (double click file), or just sits there frozen with the file-selector window open. All I can see it doing is slowly eat ram until I end up killing it's process in exterminator.

[wltjr]

Here is edi doing it as well, edi Desktop/fgdga.txt. No edi window, just what you see in htop

[ApostolosB]

Tried edi on my git system (a really slow one). Same behavior as with ecrire on it. 100%cpu, nothing on the screen and memory going up. At least the result is not as explosive as on my stable system.
Also tested l3afpad with the file and opened it without an issue.

[NuLogicSystems]

Same here, issue still present using efl-git.

[Peter2121]

Seriously improved in the last version of EFL (1.24.3).

[ApostolosB]

Seriously improved in the last version of EFL (1.24.3).

nahhh. still takes ages to open a 3.6MB file.

[wltjr]

It actually opened a couple times for me, but there were issues each time. It also crashed as I tried to navigate the document via scrollbars. It does seem to be a little better, or different, but remains an issue.