Jump to content

Photo

[Solved] Moksha Segfault


Best Answer Jeff, 27 January 2017 - 06:39 PM

Out of curiosity - does disabling the window geometry text in Window Display settings make the crashes stop for you?

oNKMVxs.png

I can't produce a lock on my system since disabling these. Going to look into fixing it, but for now this seems like a good work around.

Go to the full post


  • Please log in to reply
69 replies to this topic

#21 ylee

ylee

    King of the Software Page

  • Moderators
  • 1559 posts
  • LocationSouth Carolina, USA

Posted 15 December 2016 - 10:53 AM

Just a note that I added

[spoiler] [/spoiler]

tags to the long posts above to simplify reading.


"No technology can ever be too arcane or complicated for the black t-shirt crowd."




A big thank you to everyone who contributes to Bodhi Linux


#22 Astroboy

Astroboy

    Member

  • Members
  • 335 posts
  • LocationZacatecas, Mexico

Posted 16 December 2016 - 04:08 PM

Since I put in post # 20 the results of bt, it points the culprit to files included in EFL, so I would like to test EFL 1.18.3 packages in the testing branch, to see if that would solve the issue. However, I do not know the format of the line that I should add in sources.list to enable the testing repo. Tried some permutations adapting info that was given for previous versions, but that didn't work for me...



#23 Charles@Bodhi

Charles@Bodhi

    Old Faithful

  • Moderators
  • 4472 posts
  • LocationZeist, The Netherlands

Posted 16 December 2016 - 06:27 PM

Hola señor,

 

At the end of the line for Bodhi you can add " b4testing" (without the quotes), so it would read: 

deb http://packages.bodhilinux.com/bodhi xenial b4main b4testing

Your modified sources.list must be activated through the command apt-get update, but I guess you know that.  :rolleyes:

 

Enjoy,

Charles


Medion S4216 Ultrabook, 4GB RAM, 1TB HDD, WIN 10 & Bodhi 4.1.0-64 

Asus eeepc 901, 1GB RAM, 12 GB SSD, Bodhi 3.0.0-32-Legacy & Bodhi 4.1.0-32 Legacy


#24 Jeff

Jeff

    Lead Developer

  • Developer
  • 12416 posts
  • LocationBloomington, IL

Posted 16 December 2016 - 10:42 PM

Astroboy - can you please be sure to install the efl-dbg package as well and then run another back trace like you did before when you generate the crash?



#25 Astroboy

Astroboy

    Member

  • Members
  • 335 posts
  • LocationZacatecas, Mexico

Posted 16 December 2016 - 11:04 PM

I'm sad to report that using b4testing repo and updating the efl package to the latest version available in the testing repo didn't fix this issue. Moksha restarts as before.

 

In another test computer, this is the result of bt with efl-dbg package installed. In this computer there are no updates, only the Moksha packages as they came in Bodhi 4.0 iso.

(gdb) bt
#0  0x00007ffff3dc1428 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff3dc302a in __GI_abort () at abort.c:89
#2  0x00007ffff3e037ea in __libc_message (do_abort=do_abort@entry=2,
    fmt=fmt@entry=0x7ffff3f1c2e0 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff3e0df88 in malloc_printerr (ar_ptr=0x7ffff414fb20 <main_arena>,
    ptr=<optimized out>, str=0x7ffff3f19095 "corrupted double-linked list",
    action=3) at malloc.c:5004
#4  _int_malloc (av=av@entry=0x7ffff414fb20 <main_arena>,
    bytes=bytes@entry=544) at malloc.c:3725
#5  0x00007ffff3e1021a in __libc_calloc (n=<optimized out>,
    elem_size=<optimized out>) at malloc.c:3234
#6  0x00007ffff6402af0 in _evas_common_rgba_image_new ()
    at lib/evas/common/evas_image_main.c:382
#7  0x00007ffff6397d1a in _evas_cache_image_entry_new (
    cache=cache@entry=0x842930, hkey=hkey@entry=0x0, tstamp=tstamp@entry=0x0,
    f=f@entry=0x0, file=file@entry=0x0, key=key@entry=0x0, lo=0x0, error=0x0)
    at lib/evas/cache/evas_cache_image.c:253
#8  0x00007ffff6398e20 in evas_cache_image_data (cache=0x842930,
    w=w@entry=400, h=h@entry=50, image_data=image_data@entry=0x7fffe8e31000,
    alpha=alpha@entry=1, cspace=cspace@entry=EFL_GFX_COLORSPACE_ARGB8888)
    at lib/evas/cache/evas_cache_image.c:1097
---Type <return> to continue, or q <return> to quit---
#9  0x00007fffe9813f84 in evas_software_xlib_outbuf_new_region_for_update (
    buf=0xd35630, x=<optimized out>, y=<optimized out>, w=400, h=50,
    cx=<optimized out>, cy=0x7ffffff9fc54, cw=0x7ffffff9fc58,
    ch=0x7ffffff9fc5c)
    at modules/evas/engines/software_x11/evas_xlib_outbuf.c:640
#10 0x00007ffff6443c49 in eng_output_redraws_next_update_get (data=0xcc6f30,
    x=0x7ffffff9fc40, y=0x7ffffff9fc44, w=0x7ffffff9fc48, h=0x7ffffff9fc4c,
    cx=0x7ffffff9fc50, cy=0x7ffffff9fc54, cw=0x7ffffff9fc58, ch=0x7ffffff9fc5c)
    at modules/evas/engines/software_generic/evas_engine.c:3993
#11 0x00007ffff63778fa in evas_render_updates_internal (
    eo_e=eo_e@entry=0x4000002a000002a1,
    make_updates=make_updates@entry=1 '\001', do_draw=do_draw@entry=1 '\001',
    done_func=done_func@entry=0x7ffff636e410 <evas_render_pipe_wakeup>,
    done_data=done_data@entry=0x962490, do_async=do_async@entry=1 '\001')
    at lib/evas/canvas/evas_render.c:2723
#12 0x00007ffff6379c87 in _evas_canvas_render_async (eo_e=0x4000002a000002a1,
    e=0x962490) at lib/evas/canvas/evas_render.c:3134
#13 0x00007ffff62f01ad in evas_canvas_render_async (obj=0x4000002a000002a1)
    at ../src/lib/evas/canvas/evas_canvas.eo.c:140
#14 0x00007ffff62f3c75 in evas_render_async (obj=<optimized out>)
    at ../src/lib/evas/canvas/evas_canvas.eo.c:623
#15 0x00007fffe9a29357 in _ecore_evas_x_render (ee=0xc8b540)
    at modules/ecore_evas/engines/x/ecore_evas_x.c:813
---Type <return> to continue, or q <return> to quit---
#16 0x00007ffff5e43d86 in _ecore_evas_idle_enter (data=<optimized out>)
    at lib/ecore_evas/ecore_evas.c:177
#17 0x00007ffff606941f in _ecore_call_task_cb (data=<optimized out>,
    func=<optimized out>) at lib/ecore/ecore_private.h:283
#18 _ecore_factorized_idle_process (data=0x801cb0, event=<optimized out>)
    at lib/ecore/ecore_idler.c:35
#19 0x00007ffff175563b in _eo_base_event_callback_call (
    obj_id=<optimized out>, pd=0x760d30,
    desc=0x7ffff62825e0 <_EFL_LOOP_EVENT_IDLE_ENTER>,
    event_info=<optimized out>) at lib/eo/eo_base_class.c:1153
#20 0x00007ffff1754313 in eo_event_callback_call (obj=0x4000000010000002,
    desc=0x7ffff62825e0 <_EFL_LOOP_EVENT_IDLE_ENTER>,
    event_info=event_info@entry=0x0) at lib/eo/eo_base.eo.c:142
#21 0x00007ffff60692fe in _ecore_idle_enterer_call (loop=<optimized out>)
    at lib/ecore/ecore_idle_enterer.c:48
#22 0x00007ffff606bd9b in _ecore_main_loop_iterate_internal (
    once_only=once_only@entry=0) at lib/ecore/ecore_main.c:2266
#23 0x00007ffff606c387 in ecore_main_loop_begin ()
    at lib/ecore/ecore_main.c:1286
#24 0x0000000000434759 in main ()

 



#26 quamenzullo

quamenzullo

    Member

  • Members
  • 108 posts

Posted 05 January 2017 - 03:28 PM

Hello everyone,

 

I've read this thread with attention since I experience quite clearly the same problem. After the restart, all applications are fine, except LibreOffice, that does not look completely crashed, it just can't display anything but the title bar. I have to close and restart it. So far, the documents are always recovered, but that's annoying.

 

So I was wondering if anything new has been found since the last post?

 

Also, are these lines from Astroboy reports not relevant?

ERR<eo>lib/eo/eo.c:462 in lib/edje/edje_object.eo.c:338: func 'edje_obj_signal_e
mit' (719) could not be resolved for class 'Efl_Canvas_Group'

Doesn't they look like a bug in the edje library?



#27 Jeff

Jeff

    Lead Developer

  • Developer
  • 12416 posts
  • LocationBloomington, IL

Posted 06 January 2017 - 08:23 AM

It does indeed look like an EFL issue. I'm nudging the upstream folks again. Hopefully help them get things resolved.



#28 Astroboy

Astroboy

    Member

  • Members
  • 335 posts
  • LocationZacatecas, Mexico

Posted 08 January 2017 - 09:46 PM

Also, I'd like to point that upgrading EFL to 201612141.18 nukes Swami functionality. An error appears:

Traceback (most recent call last):
File "/usr/bin/swami", line 176, in <module>
app = MainWin(launchArg)
File "/usr/bin/swami", line 46, in __init__
self.icon_object_set(icon.object_get())
File "efl/elementary/image.pxi", line 453, in efl.elementary.__init__.Image.object_get (efl/elementary/__init__.c:159042)
File "efl/eo/efl.eo.pyx", line 137, in efl.eo.object_from_instance (efl/eo/efl.eo.c:1954)

		@page { margin: 2cm }
		p { margin-bottom: 0.25cm; direction: ltr; color: #000000; line-height: 120%; orphans: 2; widows: 2 }
		p.western { font-family: "Arial", sans-serif; font-size: 12pt; so-language: es-MX }
		p.cjk { font-family: "Tahoma"; font-size: 12pt; so-language: zh-CN }
		p.ctl { font-family: "Lucida Sans", sans-serif; font-size: 12pt; so-language: hi-IN }
ValueError: Eo object at 0x400000029000002a of type Edje_Object does not have a mapping!

Swami works fine in 64 bit with EFL 20161081.18 (the version included in Bodhi 4.0). In 32 bit it also works with that EFL version, although is needed to apply the fix described in http://forums.bodhil...-not-in-32-bit/



#29 Jeff

Jeff

    Lead Developer

  • Developer
  • 12416 posts
  • LocationBloomington, IL

Posted 08 January 2017 - 11:01 PM

Not seeing any issues with swami and EFL 1.18.4 on my first laptop here. Will try my other systems when I have a chance.



#30 Jeff

Jeff

    Lead Developer

  • Developer
  • 12416 posts
  • LocationBloomington, IL

Posted 13 January 2017 - 09:36 PM

OK - apparently we need run the crash through valgrind as described on this wiki page: https://phab.enlight...rg/w/debugging/



#31 Astroboy

Astroboy

    Member

  • Members
  • 335 posts
  • LocationZacatecas, Mexico

Posted 15 January 2017 - 12:12 AM

Got stuck in the very first line asked on the wiki page:

valgrind --tool=memcheck --db-attach=yes enlightenment

It returns:

valgrind: Unknown option: --db-attach=yes
valgrind: Use --help for more information or consult the user manual.

--db-attach is not mentioned on the --help of valgrind, and this site (http://valgrind.org/.../dist.news.html) states that:

 

 The command line options --db-attach and --db-command have been removed.
  They were deprecated in 3.10.0.

 

So I wonder if the enlightenment wiki is current...



#32 Jeff

Jeff

    Lead Developer

  • Developer
  • 12416 posts
  • LocationBloomington, IL

Posted 15 January 2017 - 12:16 AM

Astroboy - do you use the E mailing list at all? I have a few emails back and forth with the E devs there about this on their devel mailing list. 



#33 Astroboy

Astroboy

    Member

  • Members
  • 335 posts
  • LocationZacatecas, Mexico

Posted 15 January 2017 - 12:51 AM

Nope, I’m not in the E dev mailing list, (I’m a mere and unworthy non-E-developer mortal ;)).

 

However, I’m more than happy to follow your directions to solve this issue. I can even lend you via Teamviewer one of the troublesome computer models, to let you dissect it as you please.



#34 Jeff

Jeff

    Lead Developer

  • Developer
  • 12416 posts
  • LocationBloomington, IL

Posted 15 January 2017 - 07:50 PM

Try this:
 

Xephyr :2
 
A nested X session will display in a window.
 
in another terminal:
 
DISPLAY=:2
enlightenment_start -valgrind=all


#35 Astroboy

Astroboy

    Member

  • Members
  • 335 posts
  • LocationZacatecas, Mexico

Posted 16 January 2017 - 03:31 PM

Ok, done it.

 

I modified the last command to

 

enlightenment_start -valgrind=all > output.txt 2>&1

 

Because with valgrind there are thousands of output lines. I cannot register all of them by copying Terminology display buffer, so I redirected all to the output.txt file.

 

Curiously, I was not able to provoke the Moksha restart on the nested X session. However, valgrind generates a lot of memory leak errors, which seems to correspond to what would cause a Moksha segfault on a real display. What's more, when I moved a window in the real display caused immediately the Moksha restart, and that fact was also captured by Valgrind, even when is not supposed to, since it should only capture what is happening on the nested window. Anyway, the stuff detected by Valgrind on the main display was also recorded on the output.txt file, around the last lines.

 

However, output.txt contains thousands of lines, so is not viable to paste that text here. Could you PM an email account to send that file?

 

Best Regards.



#36 Jeff

Jeff

    Lead Developer

  • Developer
  • 12416 posts
  • LocationBloomington, IL

Posted 16 January 2017 - 06:55 PM

JeffHoogland at Linux dot com



#37 The waiter

The waiter

    Module Master

  • Developer
  • 1542 posts
  • LocationBanska Bystrica, Slovakia

Posted 16 January 2017 - 06:57 PM

I am also interested. Put the text in paste.debian.net and share the link with us.

#38 Astroboy

Astroboy

    Member

  • Members
  • 335 posts
  • LocationZacatecas, Mexico

Posted 16 January 2017 - 07:17 PM

Jeff: Sent to the email address requested.

 

Waiter: Sorry, couldn't do it on paste.debian.net. The size limit is 150KB, and the file, uncompressed, sizes more than 100MB. Compressed makes a size of 3.8MB.

 

The log file contains all the stuff that Valgrind found: the start of the nested X session, moving around the PCMan File Manager window inside that nested session, what it registered when I moved a Terminology window outside the nested session and caused the expected Moksha restart, and the closing of the nested session.



#39 Jeff

Jeff

    Lead Developer

  • Developer
  • 12416 posts
  • LocationBloomington, IL

Posted 23 January 2017 - 01:34 PM

Astroboy - 

 

Can you run valgrind again with the options:

--show-reachable=no --vgdb-error=0

This should cut some of the "noise" out of the file that is making it so large / hard to sort through.



#40 Astroboy

Astroboy

    Member

  • Members
  • 335 posts
  • LocationZacatecas, Mexico

Posted 23 January 2017 - 08:58 PM

Ok, sent to your linux email account the new results with the options requested.

 

Doing the same stuff as before I didn't notice any change, the uncompressed file still sized around 100 MB, so I did a bit less to make its size around 70 MB:

 

-Opened the nested session

-In the nested session I opened Terminology, and moved around its window. As expected, no Moksha segfault in the nested one, but Valgrind registered memory leaks.

-I moved a Terminology window in the main display (not the nested one). That immediately provoked the Moksha segfault in the main display, and Valgrind registered some stuff about that.

-I closed the nested session.

 

So, I didn't open PcMan File Manager nor move its window this time.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users